toolsThis series of posts highlights a number of other languages and toolkits for developing Android applications, beyond the standard Java-based SDK. These are a preview of topics to be covered in CommonsWare’s upcoming book “Android Beyond Java”, to be released in 2010.

Android itself officially supported Java from the beginning. Every other environment has simply been layered atop of it by interested third parties. At least, that is how it was until the summer of 2009, when the core Android team released the Native Development Kit (NDK).

The NDK allows developers to create extension libraries for their Java applications using C/C++, connected via the Java Native Interface (JNI).

Hence, it is important to point out what the NDK is not:

  • The NDK is not designed to build full Android applications with GUIs and such
  • The NDK is not designed to create console mode applications
  • The NDK is not an on-board compiler that can be used to compile C/C++ source code on a device itself

The main purpose of the NDK is to provide opportunities for algorithm acceleration. If you are trying to do real-time image or audio processing, or fancy game physics for your OpenGL game, or things of that nature, the NDK is for you. The bulk of your application is still done in Java (or possibly other environments as outlined in these blog posts), but bits and pieces are moved to C/C++ as needed for acceleration.

Why all the limits? The goal is for NDK-based source code to remain as “write once, run anywhere” as the Java code. This means the NDK has to have eventual support for multiple editions of the compiled libraries (ARM vs. x86 vs. MIPS vs. …). And, this means the NDK needs to limit access to system APIs to only those Android is willing to support over the long term, to help minimize the chance that a library will work for some Android versions and not others.

Another potential use of the NDK, of relevance to these blog posts, is to offer other language interpreters reachable from Java. A language with a C/C++ implementation that can be packaged in the form of an extension library might be buildable with the NDK, to be used for user scripting of an otherwise Java-based application.

In summary, if you want to build applications for Android, you are not necessarily forced to use Java. If you want to make your application extensible, you are not necessarily forcing your users to use Java. While Java will remain the keystone of Android development for the foreseeable future, you have options today, and likely more options tomorrow.

Note: Select outbound links may include affiliate tracking codes and AndroidGuys may receive compensation for purchases. Read our policy. As an Amazon Associate we earn from qualifying purchases.


  1. Interesting, JNI is no longer in common use in the J2SE environment since the HotSpot VM was vastly optimized in the last few years.
    Maybe there's room for more optimizations in the Dalvik VM?

  2. there is room for more optimizations in the Dalvik VM… it is interpreter… should be JIT… it is too slow now… I think that Java stuff is few times faster on Java ME on Sony Ericsson phone than on Dalvik VM…

    Dalvik VM improvements should really improve Android and minimize need for JNI

Comments are closed.