Jump to content
  • Advertisement
Sign in to follow this  
6677

Feasibility of writing android apps purely through the NDK

This topic is 2036 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

How feasible would it be to write an app written in as close to pure native code as possible?

Let me elaborate a bit. I fully understand that most ndk apps for android will still need a few lines of java to initialize your native code so we'll leave that part out of the equation. I have also read an article on the ndk from google stating that using the NDK simply because you are more familiar with C or C++ than java is not recommended.

I do actually have a fairly extensive language background so although I don't know java if I was serious about writing an android app I would probably find it easy enough to learn. This is purely from a theoretical point of view. I don't have any intentions on getting into android app development as I don't have access to a working android handset, I use a windows phone and my old android handset has a dodgy touchscreen and crashes alot. Its just I came across a reference to the NDK somewhere once and am learning C to use on a microcontroller and then started thinking about this question.

Do you think it is possible to write an entire android app with either C or C++ (with the exception of the lines required to initialise your native code.

What problems do you think someone would come across?

Are there any apps that somewhat bizarrely use this approach?

Is there really any speed benefit? (I would normally expect there to be but apparently there are some weird quirks with how "native" code runs on android)

Wouldn't you lose support for x86 and MIPS handsets? Edited by 6677

Share this post


Link to post
Share on other sites
Advertisement

Do you think it is possible to write an entire android app with either C or C++ (with the exception of the lines required to initialise your native code.


I'm not sure how mature the NDK is at this point (how many features it supports), but you can already implement your Activity class, access sensors and do rendering in native code.

Here's a blog post that shows how to implement a basic native Activity: http://www.altdevblogaday.com/2012/02/28/running-native-code-on-android-part-2/



What problems do you think someone would come across?


Unsupported features, losing access to a useful set of Java UI elements, possibility of getting into trouble with native memory management, etc


Are there any apps that somewhat bizarrely use this approach?


I bet there are a few utility/enterprise apps that use the NDK, but I've only seen games use it.


Is there really any speed benefit? (I would normally expect there to be but apparently there are some weird quirks with how "native" code runs on android)


I would love to measure this at some point. Some algorithms probably benefit more than others. I think there is a speed increase, but it may not be huge. A big reason why people use the NDK is ease of porting (not having to translate to Java from C/C++).


Wouldn't you lose support for x86 and MIPS handsets?


You would have to make separate builds for those architectures. The NDK documentation (http://developer.android.com/tools/sdk/ndk/index.html) mentions x86 and mips are supported (but for API level 9 and greater):

"Removed arch-x86 and arch-mips headers from platforms/android-[3,4,5,8]. Those headers were incomplete, since both X86 and MIPS ABIs are only supported at API 9 or higher."


Also, from http://stackoverflow.com/questions/5089783/producing-optimised-ndk-code-for-multiple-architectures :
It looks like if you specify "APP_ABI := all", it builds for all architectures (NDK7 or greater).

Share this post


Link to post
Share on other sites
Firstly it depends on both your experience and the task at hand. If your experience is good and you want to start from the ground up, you might have yourself on such a strict regime of coding practices that it will mitigate your necessity to debug.
This is important because debugging with the NDK can only be done with sprintf()—you don’t have breakpoints or any stack-tracing abilities.


I hate Java, but if you are not the absolute top of your game, don’t touch the NDK. Google hates people who use the NDK and you will only realize how far that goes once you start using it.
My coworker was tasked with porting this engine to Android: http://www.youtube.com/watch?feature=player_embedded&v=6cuXgRVMvZ0
During the 6 months that he has been working on it, I have watched his heart turn to black. He never smiles at lunch anymore. The only time he smiles is when I tell a joke about punching his fist into an Android screen and having it come out miles away and punch one of the Android creators in the face.

His soul is not lost because I am there to help him, but I won’t be there for you. Knowing that your soul will be lost, engage in Android NDK development at your own risk.
I may still be able to turn his heart back to its original green color…


L. Spiro

Share this post


Link to post
Share on other sites
I also HATE java. I refuse to even touch it. I have heard some people talk about the time it would save so I started reading about it and stopped when I heard that it was an interpreted language and there is no unsigned support. I myself was wondering the same thing how can I not write a line of java and instead use C a real programming language? Also @ L. Spiro why would google hate the NDK? I refuse to write an android app until I am able to use not a line of java. Edited by sega16

Share this post


Link to post
Share on other sites
As I said, no breakpoints, no debugging, no single-stepping, etc.
You debug with sprintf() and nothing else.
Many people have written many hundreds of paragraphs each about the pains of the Android NDK.

This is an obvious sign that Google hates NDK developers.

My coworker was successful in making the above engine work on Android. But it cost him most of his soul—emotional damage that will take years to heal.


L. Spiro

Share this post


Link to post
Share on other sites
This is important because debugging with the NDK can only be done with sprintf()—you don’t have breakpoints or any stack-tracing abilities.

This is false. NDK comes with gdb and instructions how to use it (see docs/NDK-GDB.html).
I am using GDB to debug my NDK applications just fine. You can put breakpoints, singl-step, view and modify variable values, and everything else you can do with GDB.

Share this post


Link to post
Share on other sites
Yep. One of our staff mentioned that we should do that.
The rest of the staff who are close to the NDK side of things gave several reasons why that is not plausible/helpful.
Unfortunately I would have to go to the office and the in-house newsgroups to remember the specifics. All I can remember now is, “It doesn’t help/is not practical/comes with too many restrictions or disadvantages.”
Perhaps it only works for one Android device etc.
I don’t remember the details since I just glossed over it, but it isn’t a viable option.


L. Spiro

Share this post


Link to post
Share on other sites
It is very viable option. I'm using it all the time. And as I said before, it works fine.
Maybe you did set up it wrongly. If it doesn't work for you, it doesn't mean it won't work for everyone. Edited by Martins Mozeiko

Share this post


Link to post
Share on other sites

[spoiler]
[quote name='6677' timestamp='1354399165' post='5006107']
Do you think it is possible to write an entire android app with either C or C++ (with the exception of the lines required to initialise your native code.


I'm not sure how mature the NDK is at this point (how many features it supports), but you can already implement your Activity class, access sensors and do rendering in native code.

Here's a blog post that shows how to implement a basic native Activity: http://www.altdevblo...android-part-2/



What problems do you think someone would come across?


Unsupported features, losing access to a useful set of Java UI elements, possibility of getting into trouble with native memory management, etc


Are there any apps that somewhat bizarrely use this approach?


I bet there are a few utility/enterprise apps that use the NDK, but I've only seen games use it.


Is there really any speed benefit? (I would normally expect there to be but apparently there are some weird quirks with how "native" code runs on android)


I would love to measure this at some point. Some algorithms probably benefit more than others. I think there is a speed increase, but it may not be huge. A big reason why people use the NDK is ease of porting (not having to translate to Java from C/C++).


Wouldn't you lose support for x86 and MIPS handsets?


You would have to make separate builds for those architectures. The NDK documentation (http://developer.and.../ndk/index.html) mentions x86 and mips are supported (but for API level 9 and greater):

"Removed arch-x86 and arch-mips headers from platforms/android-[3,4,5,8]. Those headers were incomplete, since both X86 and MIPS ABIs are only supported at API 9 or higher."


Also, from http://stackoverflow...e-architectures :
It looks like if you specify "APP_ABI := all", it builds for all architectures (NDK7 or greater).
[/spoiler]
[/quote]
That was certainly useful and interesting information.

Like I say this is theoretical, my handset is hardly in a working state (have to restart it 4 or 5 times after booting before the touchscreen works, then every 2 minutes the touchscreen freezes again and you have to hit the lock button a few times to undo that, it also randomly freezes, not to mention it being a generally slow handset: ZTE Blade, and its android 2.2 so no API level 9). If I was serious about android dev I would probably just take the time to learn java, I don't have anything against it normally its just I have no need for it.


Certainly looks doable though

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!