Jump to content

  • Log In with Google      Sign In   
  • Create Account


Feasibility of writing android apps purely through the NDK


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
18 replies to this topic

#1 6677   Members   -  Reputation: 1058

Like
0Likes
Like

Posted 01 December 2012 - 03:59 PM

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, 01 December 2012 - 04:00 PM.


Sponsor:

#2 gfxgangsta   Members   -  Reputation: 533

Like
1Likes
Like

Posted 01 December 2012 - 06:48 PM

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).

#3 L. Spiro   Crossbones+   -  Reputation: 12249

Like
3Likes
Like

Posted 02 December 2012 - 05:32 AM

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:
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
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#4 Ed Welch   Members   -  Reputation: 463

Like
0Likes
Like

Posted 02 December 2012 - 11:29 AM

I'd imagine his task would be even more difficult if he had to re-write the entire engine in java.

#5 sega16   Members   -  Reputation: 131

Like
1Likes
Like

Posted 02 December 2012 - 01:35 PM

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, 02 December 2012 - 01:37 PM.


#6 L. Spiro   Crossbones+   -  Reputation: 12249

Like
0Likes
Like

Posted 02 December 2012 - 02:21 PM

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
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#7 Martins Mozeiko   Crossbones+   -  Reputation: 1413

Like
0Likes
Like

Posted 02 December 2012 - 02:24 PM

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.

#8 L. Spiro   Crossbones+   -  Reputation: 12249

Like
0Likes
Like

Posted 02 December 2012 - 02:43 PM

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
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#9 Martins Mozeiko   Crossbones+   -  Reputation: 1413

Like
0Likes
Like

Posted 02 December 2012 - 02:48 PM

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, 02 December 2012 - 02:48 PM.


#10 6677   Members   -  Reputation: 1058

Like
0Likes
Like

Posted 02 December 2012 - 04:42 PM

Spoiler

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

#11 MrDaaark   Members   -  Reputation: 3539

Like
1Likes
Like

Posted 02 December 2012 - 05:35 PM

Do you really need to take time to learn Java? It's not far off from C# or C++. Just read some material that assumes you want to transition from C++ to Java. Than just start writing, and refine things as you go along.

It's Android that you will have to learn.

Or you can try Lib GDX. It's cross platform Windows + Android, and it has a lot sof stuff implemented in NDK for speed. It's like meeting your goal halfway.

Edited by Daaark, 02 December 2012 - 05:36 PM.


#12 L. Spiro   Crossbones+   -  Reputation: 12249

Like
0Likes
Like

Posted 05 December 2012 - 07:24 PM

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.

And this is for Native Activity or just Native?

IE: Purely C/C++ or a mix of C/C++ and Java?


L. Spiro
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums

#13 Cornstalks   Crossbones+   -  Reputation: 6966

Like
1Likes
Like

Posted 05 December 2012 - 08:58 PM

I was working on a native activity for a short while. I used this tutorial (you can go to the next or previous to see more) to do remote debugging, and it worked pretty ok. Certainly not as nice as when I debug with Visual Studio or gdb on my local machine, but still decent. One challenge is just the setup. The setup isn't super friendly, but once you finally set it up it's not overly horrible. Another issue is that the debugger has to attach itself, which takes some time, so you can't (or at least I couldn't) debug the first few seconds the app was running.

There can be a speed benefit, but it's not promised. Google says one good candidate for a native activity is a physics simulation, which is exactly what I was doing.

One issue with using the NDK is taking shortcuts. Normal Android apps (in Java) don't have a main loop (or even a main function), and the API is really built around activities (not applications). Long story short: if you use the NDK because you're used to having a main loop and C/C++, but don't properly understand how Android applications and activities work, you will suffer. I'd suggest you only use the NDK if you are already familiar with the Java API.

Some things in the Android API weren't readily available in the NDK, but I think most things are available. But then again, there are some things available in the NDK that aren't available in Java (like OpenSL (or any other low-level API that gives you fine control over things)).

In short, yeah, it's possible, but don't start there. If you're new to Android, start with its Java API and make sure you properly wrap your head around applications, activities, services, etc. because despite Android being Linux, it doesn't really function like Linux. After that, then move to the NDK. Sure, you can skip the Java API and move straight on to the NDK, but it'll likely be painful and take you longer to get to any level of competence.
[ I was ninja'd 71 times before I stopped counting a long time ago ] [ f.k.a. MikeTacular ] [ My Blog ] [ SWFer: Gaplessly looped MP3s in your Flash games ]

#14 Sik_the_hedgehog   Crossbones+   -  Reputation: 1485

Like
1Likes
Like

Posted 05 December 2012 - 11:07 PM

Long story short: if you use the NDK because you're used to having a main loop and C/C++, but don't properly understand how Android applications and activities work, you will suffer.

Yeah, I think this is one of the main problems. One of the main reasons why you'd want to get as much as possible into the NDK is to port a program written in C or C++ to Android with as little effort as possible, but the environment is so different that the idea is just completely stupid most of the time (not to mention the user interface changes), more often than not it'd be better to just rewrite it from scratch (on that note, how does SDL for Android work?).

Also I heard that the speed difference between NDK and Java code really isn't very noticeable (if at all) because the Java code gets recompiled to native instructions anyway (it isn't interpreted), so I'm not sure if that could really be considered an advantage. I suppose NDK still wins if you really don't like Java, though =P
Don't pay much attention to "the hedgehog" in my nick, it's just because "Sik" was already taken =/ By the way, Sik is pronounced like seek, not like sick.

#15 EVIL_ENT   Members   -  Reputation: 212

Like
1Likes
Like

Posted 23 December 2012 - 02:53 AM

Also I heard that the speed difference between NDK and Java code really isn't very noticeable (if at all) because the Java code gets recompiled to native instructions anyway (it isn't interpreted), so I'm not sure if that could really be considered an advantage. I suppose NDK still wins if you really don't like Java, though =P

 

I wrote a very simple space shooter and got performance problems as soon as there were like 30 ships moving around at once, than I wrote the same again in native code and suddenly could manage 10 times more ships without doing any structural changes to the code.

That was on api 8 though and I have heared that dalvik became faster since then and that FloatBuffers have been fixed (there was a problem that wrapping a floatbuffer around a float array would call floatBuffer.put on every element instead of doing something smart).

There were also some functions missing so one could not write efficient code and had to use JNI wrappers anyway.

 

In my opinion the google guys are a little too fond of their dalvik vm. In practice native code is a lot faster and should be prefered if there are even remotely computationally expensive tasks to do.

Also will give you more battery life.

 

I have written a windows/linux framework for developing and debugging, so I don't have to mess with eclipse/android can just copy the files for final release.



#16 Katie   Members   -  Reputation: 1283

Like
2Likes
Like

Posted 23 December 2012 - 03:48 AM

I did some work in this area; I don't think there would be major problems. The annoyance is that it's not just a single line of Java you need to write -- basically any event you actually want to use (screen touches, rotations, anything like that) requires a thunk to pass it into your NDK. On the plus side, once done, done.

 

You'll also need to think about whether you'll need to leave C++ and go back to Java to do things (to access other features on the phone). If you want to write something that uses screen taps and draws things, the work is pretty simple. If you want to start talking to servers, do GPS or use the camera or things like that then it gets complicated fast.

 

You can do this transition into C++ at any layer BTW -- you could do game logic in Java and the rendering in C++. It's just a call into a shared object -- a DLL.

 

Why did I do it? Simply because I'm more productive in C++ because I'm more familiar with it. If you're starting from scratch, you may be better off choosing the path of lesser resistance and working in Java.



#17 6677   Members   -  Reputation: 1058

Like
0Likes
Like

Posted 23 December 2012 - 09:49 AM

In my opinion the google guys are a little too fond of their dalvik vm
Android was meant to run on several different architectures seamlessly. It may well be most popular on arm but then you get the issue of ARMv6 and ARMv7 and then on ARMv6 in particular issues about whether or not the CPU has a hardware FPU or not. Then there are a few devices that run on MIPS rather than arm (particularly in china) and a few x86. I think that is the perfect time to be using a VM rather than native code, although it does seem that they give options for compiling separate binaries for each platform.


Anyway, seems to be alot of useful insight on the subject in this thread.

Edited by 6677, 23 December 2012 - 09:50 AM.


#18 MrDaaark   Members   -  Reputation: 3539

Like
0Likes
Like

Posted 23 December 2012 - 02:41 PM

A decision made to support another bad decision is still a bad decision. Saying that 'they meant to do that' doesn't make it any less of a bad decision.

They decided on chaos instead of order. And chaos is what they got. To the point where you can't even write a simple example app and expect it to work across the board. That decision has hurt app developers, middleware developers, and even more so consumers who have to come home with their new devices and realize that their expensive apps either aren't compatible or don't work properly anymore.

And then now that are trying to reign in that chaos a bit with standards to follow, and a official android distro to work off of, the ones causing all the chaos are laughing at them and continuing on with their chaos.

Edited by Daaark, 23 December 2012 - 06:11 PM.


#19 6677   Members   -  Reputation: 1058

Like
0Likes
Like

Posted 24 December 2012 - 05:31 PM

They should have called android: entropy






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS