Rudimentary tools for native user-level development popped up in the Android SDK this summer, but I've only just begun to experiment with them. Android is effectively open to unrestricted development by virtue of being open source, but Google needed a trusted path that allows native code -- code that executes directly on the device's microprocessor -- to run on vanilla system software.
The new Native Development Kit (NDK) provides that path, but it's a dark, narrow, and slippery road.
[ Is the party over for Google Android? Neil McAllister makes the case in InfoWorld's Fatal Exception blog. ]
Android developers can now rewrite some performance-sensitive portions of their applications in C, C++, or ARM assembly language and call that code from a running Java app through the Java Native Interface (JNI). The result? A manyfold increase in the performance of math and memory-intensive operations, along with a serious drop in battery drain. Some types of programs that are inefficient or impossible to create in interpreted Java, like real-time business intelligence and transcoding foreign video streams to a format supported by the device, can work as native code.
Short leash
This approach to native code doesn't let apps out of the secure sandbox created by the OS, and native applications can't be launched directly from the GUI. Apart from the old school C standard library and a corresponding set of math functions, there is no published native API for user-level apps. Native code can't access system services, draw on the display, make phone calls, or otherwise manipulate the hardware directly.
"Can't" isn't what developers want to hear. The Holy Grail for Android developers and users alike is gaming, and even though Android has built-in OpenGL ES 3-D acceleration, game physics are too complex for Java. Officially, it's not possible to draw to the screen inside native code, and the overhead of flipping between C and Java contexts with every frame will keep Android devices from taking much ground away from Apple's Christmas 2009 play for Nintendo DSi and Sony PSP customers. But unofficially, Android is open, and Google admits that the native shared libraries that supply some hardware services to the Dalvik Java engine are accessible. There's no telling what you'll find when you start exploring Android's NDK.
Mixed message
Google wants coders to experiment (as if it could stop them), but it points out the enormous risk for them, and for users, of using undocumented APIs. Google considers undocumented APIs -- practically all of Android's callable native libraries -- internal and subject to sudden change by either Google, a device manufacturer, or a wireless operator, all of which have their hands in each device's firmware.
The high ratio of early adopters among Google's user base means that compelling uses of native code, even if they break the rules, will generate a lot of excitement and attention. But it would be foolish for a developer to hang a price tag on, or for users to invest any trust in, an Android app that calls undocumented native APIs. The NDK brings Android a step closer to competing against native platforms in potential performance. But the developers who would use it need both more freedom and more guidance.