What is…Android Native Development?
Basically, this is the means by which you can develop parts of your Android application using code other than Java – that you can drop down into using C or C++ in certain parts of functionality.
You would handle this through the Android NDK (Native Development Kit), which is available for three platforms: Windows, Mac OS X (intel) and Linux 32/64-bit (x86).
The Android NDK is a companion tool to the Android SDK that lets you build performance-critical portions of your apps in native code. It provides headers and libraries that allow you to build activities, handle user input, use hardware sensors, access application resources, and more, when programming in C or C++. If you write native code, your applications are still packaged into a
.apkfile and they still run inside of a virtual machine on the device. The fundamental Android application model does not change.
As well as (possibly) improving speed, it is also intended to support the reuse of existing code – it is a way to embed native libraries into an application package file (
.apk) that can be deployed on Android devices.
Note that use of the NDK will not always benefit applications or guarantee performance improvements. It will, though, increase application complexity. The phrase “enough rope…” comes to mind.
“In general, you should only use native code if it is essential to your application, not just because you prefer to program in C/C++, ” warns Google.
Within the Android framework, there are two ways to use native code.
First, write apps using the Android framework and then use the JNI (Java Native Interface) to access the APIs provided by the Android NDK. The JNI enables code running in a Java Virtual Machine to call libraries written in other languages, such as C. This technique allows you to take advantage of the convenience of the Android framework, but still allows you to write native code when necessary, says Google.
Second, within an application, handle activity lifecycle callbacks (such as
onResume()) in your own native code. Applications that use such native activities must be run on Android 2.3 (API Level 9) or later, says Google. Certain features of the Android framework will not be available.
“Typical good candidates for the NDK, writes Google, “are self-contained, CPU-intensive operations that don’t allocate much memory, such as signal processing, physics simulation, and so on.”
Another area to warrant such tweaks is support for gaming. See, for example, The Register – Android native code kit apes iPhone game 3D.
Back in March 2010, it wrote:
Google has opened the door to iPhone-like 3D games on certain Android handsets, offering support for the OpenGL ES 2.0 graphics standard with its latest Android Native Development Kit (NDK). Mountain View announced the third release of its Android NDK in a Monday blog post. The chief addition is Open GL for Embedded Systems 2.0 native libraries, bringing the platform in line with Apple’s iPhone 3GS and the Palm Pre.
Finally, according to Wikipedia:
Running native code is complicated by the fact that Android uses a non-standard C library (libc, known as Bionic). The underlying graphics device is available as a framebuffer at /dev/graphics/fb0. The graphics library that Android uses to arbitrate and control access to this device is called the Skia Graphics Library (SGL), and it has been released under an open source license. Skia has backends for both win32 and Unix, allowing the development of cross-platform applications, and it is the graphics engine underlying the Google Chrome web browser.
Discussing the NDK and “native” development also means recognising the role of ARM in powering Android handsets. Google writes:
The latest release of the NDK supports these ARM instruction sets:
- ARMv5TE (including Thumb-1 instructions)
- ARMv7-A (including Thumb-2 and VFPv3-D16 instructions, with optional support for NEON/VFPv3-D32 instructions)
- x86 instructions (see CPU-ARCH-ABIS.HTML for more information)
ARMv5TE machine code will run on all ARM-based Android devices. ARMv7-A will run only on devices such as the Verizon Droid or Google Nexus One that have a compatible CPU. The main difference between the two instruction sets is that ARMv7-A supports hardware FPU, Thumb-2, and NEON instructions. You can target either or both of the instruction sets – ARMv5TE is the default, but switching to ARMv7-A is as easy as adding a single line to the application’s
Application.mkfile, without needing to change anything else in the file.
See also: What is the NDK? (developer.android.com)