Android's native gamble puts developers on the spot
Google charts an official course for native third-party code, but stops short of fully native apps and clarity for coders
Follow @infoworldRudimentary 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.
