Can I use native code in developing for android?

You can (especially if you're using openGL) basically write almost your whole app in C(or C++, but beware of no STL) fairly easily. Once you get it set up, it basically boils down to naming your C functions a certain way and also declaring them a certain way in your Java code so it can call them. (C calling Java is a bit more complicated though). You have Java get input and then just call a C function with the input, and let your C code handle all the game and drawing. The main thing to be aware of is that (unless they've changed it) you have to compile the C code on the command line, then go to Eclipse and refresh it so it sees the new dynamic library and then run your Java compile to test the C code, and debugging native code is also very complex. The only Android app I've made wasn't very processor intensive, so I can't speak as to the overhead involved, but I doubt it's that much.

Ive written a few little apps for android, but now I know that java is definitely not for me. I know that the best selling apps are usually 2D and all that, but Im mostly intrested in 3D or 2D physics, ...and to write that in java would be horror(for me at least).

Why? Because you don't like Java? As a programmer you should write for the best tool for the job; databases mean SQL, build scripts mean python and perl, and Android programming means Java.

I know there are tools for including native parts in the java code, but I dont know anything else about them. Is it hard to implement such tools or APIs? Do they produce more overhead than the speed I gain by writing in CPP? What parts of the application can I write in native?
Thanks very much!
[/quote]Java is JIT compiled to take best advantage of the hardware running it. It has been shown by quite a few major studies that Java is either on-par with C++ or better performing than C++. The only very rare exception is when you need to take advantage of some hardware-specific benefit that has no bytecode equivalent and the JIT compiler just cannot access. But Android doesn't have that problem since all the hardware out there runs java-accelerated chipsets.

Every device I'm aware of has chips that run Java bytecode directly. That means Java *IS* native code.

You can write whatever you want in whatever language you can find Android compilers for. There are quite a few languages to chose from. But don't expect to get better performance since Java *IS* the hardware native instruction set.

[quote name='Aliii' timestamp='1335024671' post='4933540']
Ive written a few little apps for android, but now I know that java is definitely not for me. I know that the best selling apps are usually 2D and all that, but Im mostly intrested in 3D or 2D physics, ...and to write that in java would be horror(for me at least).

Why? Because you don't like Java? As a programmer you should write for the best tool for the job; databases mean SQL, build scripts mean python and perl, and Android programming means Java.

I know there are tools for including native parts in the java code, but I dont know anything else about them. Is it hard to implement such tools or APIs? Do they produce more overhead than the speed I gain by writing in CPP? What parts of the application can I write in native?
Thanks very much!
[/quote]Java is JIT compiled to take best advantage of the hardware running it. It has been shown by quite a few major studies that Java is either on-par with C++ or better performing than C++. The only very rare exception is when you need to take advantage of some hardware-specific benefit that has no bytecode equivalent and the JIT compiler just cannot access. But Android doesn't have that problem since all the hardware out there runs java-accelerated chipsets.

Every device I'm aware of has chips that run Java bytecode directly. That means Java *IS* native code.

You can write whatever you want in whatever language you can find Android compilers for. There are quite a few languages to chose from. But don't expect to get better performance since Java *IS* the hardware native instruction set.
[/quote]

While Java performance on android is pretty rock solid its not necessarily native (as android runs on standard x86 hardware aswell), the JIT compiler however does make that distinction pretty irrelevant and Google does recommend against using the native SDK for performance reasons (usually it results in a slowdown due to JNI overhead unless you write very large chunks as native code).

There is however a few very good reason to use C++ for Android apps and those are:
iOS portability (iOS doesn't run Java bytecode) (Allthough using something like Unity is a better option for this)
Memory limitations on older Android devices, (Older android versions have a 16MB per process limit for the managed heap) (Allthough since memory used by the GPU isn't counted towards that limit its rarely an issue for games and devices running those old android versions usually don't have all that much ram to play with anyway)

Thanks for your answers!

"[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

[background=rgb(250, 251, 252)]You can (especially if you're using openGL) basically write almost your whole app in C(or C++, but beware of no STL) fairly easily.[/background]

[/font]"

...Its good to hear that. Yes Im just getting started with opengl ES2. Do you mean NDK? It seems like it doesnt really support ARMv6 processors, which my phone uses:S

"[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

[background=rgb(250, 251, 252)]Why? Because you don't like Java? As a programmer you should write for the best tool for the job; databases mean SQL, build scripts mean python and perl, and Android programming means Java[/background]

[/font]"

Im OK with Java, I know its much better when it comes to portability or when you have to write little apps fast, ...but to write complex games in Java it sounds like a joke.
Under the VM is C and CPP, ....as far as I know openGL functions also run native. ....there must be a reason for that.

[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

[background=rgb(250, 251, 252)]"Every device I'm aware of has chips that run Java bytecode directly. That means Java *IS* native code."[/background]

[/font]

I didnt know that. Im not an expert, I dont know much about the hardware, how the VM executes the native parts, how and when exactly the JIT compiling happens. I need to read a lot about that.

I want to learn some Java but I would prefer juggling with pointers:) My longterm goal is to develop games for PC but android seems like a really good starter.(Maybe if I find a job at an android-dev company this will change)

"[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

[background=rgb(250, 251, 252)]While Java performance on android is pretty rock solid its not necessarily native (as android runs on standard x86 hardware aswell), the JIT compiler however does make that distinction pretty irrelevant and Google does recommend against using the native SDK for performance reasons (usually it results in a slowdown due to JNI overhead unless you write very large chunks as native code).[/background]

[/font]"

Its hard to imagine that lets say a physics algorithm can have the same performance without using pointers and references. And what about the garbage collector? Wont it "pop up" every few seconds and noticeably affect the FPS?
Thanks!

Thanks for your answers!

"

[background=rgb(250, 251, 252)]You can (especially if you're using openGL) basically write almost your whole app in C(or C++, but beware of no STL) fairly easily.[/background]

"

...Its good to hear that. Yes Im just getting started with opengl ES2. Do you mean NDK? It seems like it doesnt really support ARMv6 processors, which my phone uses:S

"

[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

[background=rgb(250, 251, 252)]Why? Because you don't like Java? As a programmer you should write for the best tool for the job; databases mean SQL, build scripts mean python and perl, and Android programming means Java[/background][/font]

"

Im OK with Java, I know its much better when it comes to portability or when you have to write little apps fast, ...but to write complex games in Java it sounds like a joke.
Under the VM is C and CPP, ....as far as I know openGL functions also run native. ....there must be a reason for that.

[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

[background=rgb(250, 251, 252)]"Every device I'm aware of has chips that run Java bytecode directly. That means Java *IS* native code."[/background][/font]

I didnt know that. Im not an expert, I dont know much about the hardware, how the VM executes the native parts, how and when exactly the JIT compiling happens. I need to read a lot about that.

I want to learn some Java but I would prefer juggling with pointers:) My longterm goal is to develop games for PC but android seems like a really good starter.(Maybe if I find a job at an android-dev company this will change)

"

[color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif]

[background=rgb(250, 251, 252)]While Java performance on android is pretty rock solid its not necessarily native (as android runs on standard x86 hardware aswell), the JIT compiler however does make that distinction pretty irrelevant and Google does recommend against using the native SDK for performance reasons (usually it results in a slowdown due to JNI overhead unless you write very large chunks as native code).[/background][/font]

"

Its hard to imagine that lets say a physics algorithm can have the same performance without using pointers and references. And what about the garbage collector? Wont it "pop up" every few seconds and noticeably affect the FPS?
Thanks!

The GC only pops up if you drop references, keep them alive by reusing objects until you're ready to take the performance hit(Good times to do this is when loading a level for example) and then force the GC to run and you'll be fine. this really is no different from how you'd do things in C++ (if you allocate and delete memory constantly with C++ you won't trigger a expensive garbage collection but you will cause some severe memory fragmentation which can be just as bad for performance).

Thanks for your answers!

"

[background=rgb(250, 251, 252)]You can (especially if you're using openGL) basically write almost your whole app in C(or C++, but beware of no STL) fairly easily.[/background]

"

...Its good to hear that. Yes Im just getting started with opengl ES2. Do you mean NDK? It seems like it doesnt really support ARMv6 processors, which my phone uses:S

The NDK, yes. I don't know about processor support at all, sorry. I know my app has worked on some fairly old phones, but no real specs.

Look up the specs of your device specifically. If it uses an ARM-based processor look for a 'j' in the description. For example, it may use the ARM 1176JZFS, where 'J' means it executes Java directly, 'F" means it has floating point hardware, etc. Or it could be a named version of the hardware, like Tegra or Cortex, that are basically the same specs, including running Java directly on the chip.

ARM-based processors are by far the most common for devices, and all the devices I'm aware of support Java directly on the chip. While you can run Android on other processors I'm not aware of any major tablet or phone running Android that isn't ARM-based.

Thanks again!
It says:
-Processor: ARMv6-compatible processor rev5(v6l)
-Features: swp half thumb fastmult vfp edsp java

I have no clue what this means

-Features: swp half thumb fastmult vfp edsp java

It means it supports smaller instruction sets, has a fast hardware multiplier, and the last one means it runs java bytecode natively.

[quote name='Aliii' timestamp='1335024671' post='4933540']
Ive written a few little apps for android, but now I know that java is definitely not for me. I know that the best selling apps are usually 2D and all that, but Im mostly intrested in 3D or 2D physics, ...and to write that in java would be horror(for me at least).

Why? Because you don't like Java? As a programmer you should write for the best tool for the job; databases mean SQL, build scripts mean python and perl, and Android programming means Java.

I know there are tools for including native parts in the java code, but I dont know anything else about them. Is it hard to implement such tools or APIs? Do they produce more overhead than the speed I gain by writing in CPP? What parts of the application can I write in native?
Thanks very much!
[/quote]Java is JIT compiled to take best advantage of the hardware running it. It has been shown by quite a few major studies that Java is either on-par with C++ or better performing than C++. The only very rare exception is when you need to take advantage of some hardware-specific benefit that has no bytecode equivalent and the JIT compiler just cannot access. But Android doesn't have that problem since all the hardware out there runs java-accelerated chipsets.

Every device I'm aware of has chips that run Java bytecode directly. That means Java *IS* native code.

You can write whatever you want in whatever language you can find Android compilers for. There are quite a few languages to chose from. But don't expect to get better performance since Java *IS* the hardware native instruction set.
[/quote]

In regards to native execution of Java, I assume that you're referring to Jazelle? Two points:

1. Jazelle mode is no longer implemented fully on newer ARM processors, like those found on phones in the last 2 years. The only instructions it truly supports are to enter/exit Jazelle mode; no bytecode is executed natively any longer. They now rely on ThumbEE to make JIT faster.

2. Jazelle meant and continues to be absolutely useless for Android. Why? Because Android does not execute Java. It executes Dalvik bytecode: Dalvik bytecode is generated from JVM bytecode, but they are not equivalent, and Dalvik bytecode cannot be run by JVM or Jazelle.

There is no native hardware support for Java on any Android-powered device, because Android doesn't run Java, it runs Dalvik. The language it is written in is irrelevant, because it is converted later into an incompatible bytecode.

Past that, I used to work for one of the major Android device manufacturers. We preferred using native code for specific tasks, namely: graphics, physics, and other intensive operations. We had also started migrating a few major apps because of garbage collection calls; this is less of an issue post-Gingerbread, but on Froyo and before, the massive amount of boxing that Java required tripped the Dalvik GC all the time, causing stutters on the devices. Gingerbread alleviated this mostly but it still happens enough to be annoying. In regards to graphics, a HUGE reason you'd rather it be C or C++ is that OpenGL is implemented as a thin JNI wrapper. Every single GL call is a JNI call, which is slow regardless of the presence of the JIT. A single JNI call and then many native OpenGL calls is vastly faster than many JNI calls to native OpenGL calls.

In short, Java is not the native instruction set of any Android device, nor is even Dalvik. The native instruction set is ARM or ARM Thumb. The CPU nor any hardware on the device can natively execute either JVM Bytecode (which will not be present on the device anyways) or Dalvik bytecode. It is all executed via the Dalvik JIT on post-Froyo hardware, and the Dalvik interpreter on pre-Froyo hardware.

I heard you actually can get STL in the Android NDK with STLPort.

I heard you actually can get STL in the Android NDK with STLPort.

Of course you can; the STL is just the templated containers; they are generally implemented entirely in headers (being templates, after all). You could use STLPort, or roll your own, or whatnot. I'm not entirely sure why they don't include the containers by default.

I heard you actually can get STL in the Android NDK with STLPort.

To use STL or STLport in the NDK...

[QUOTE name='docs/CPLUSPLUS-SUPPORT.html']To select the runtime you want to use, define APP_STL inside your
Application.mk to one of the following values:

system -> Use the default minimal system C++ runtime library.
gabi++_static -> Use the GAbi++ runtime as a static library.
gabi++_shared -> Use the GAbi++ runtime as a shared library.
stlport_static -> Use the STLport runtime as a static library.
stlport_shared -> Use the STLport runtime as a shared library.
gnustl_static -> Use the GNU STL as a static library.
gnustl_shared -> Use the GNU STL as a shared library.[/QUOTE]