(Yet Another) Android NDK Blog Posting

The Android NDK (Native Developers Kit) augments the Android SDK and enables one to create portions of a Android application using C or C++ (you knew that or you would not be reading this).

This blog post provides an introduction to NDK along w/some anecdotes and a working Android application.

Note that I am writing this in March of 2012. The current SDK is version "r16" and the current ndk is version "r7b". My examples should be valid for the current versions. As always, these examples might not age well so YMMV.

Some of you might be surprised to discover that Java existed before Android (relax, it's a joke). Java has always provided a mechanism to integrate with C/C++ applications called JNI (Java Native Interface). Wikipedia provides a decent overview of JNI and Sun (now Oracle) provides a comprehensive introduction to JNI here. Serious developers will want to read the "JNI Specification" (also available of the Oracle web site.

At runtime, your C/C++ objects will be linked and executed using the JVM. There is a cost to transition the Java/C barrier, make sure you do enough work on the C side to make the transition worth while. Of course, if you include JNI then you have excluded portability (because the C/C++ files must be compiled for every target platform). Portability is not much of a concern for Android since most targets are ARM platforms.

In the early days of Java, JNI was a frequent requirement because many vendors had not yet created Java friendly libraries. The usual steps were:

1. Create "native" Java methods to wrap around C functions. I usually collect these in a common class called "JniWrapper" (or "NdkWrapper" for Android).
   
2. Use the "javah" utility to generate a C header file based upon the contents of "JniWrapper" (i.e. "javah -jni java.class")
   
3. Write a C wrapper to act as a bridge between C and Java, the contents of the wrapper correspond to the generated header file (from step 2). Variable conversion, etc. between C/Java is typically performed here.

The above looks rather straight forward (and it is) but in practice some projects were quite difficult to complete and make stable (different threading models, etc). As Java came to dominate, there was better support for Java and less of a reason to employ JNI. Thanks to Android, this issue is receiving much more attention.

When I design a JNI application, I break the functionality down into three use cases:

1. Java invokes C (most common example)
   
2. C invokes Java (frequently asynchronous callbacks)
3. Shared variables (visible to both C and Java)

I have created a sample Android NDK application to illustrate these use cases which can be found on GitHub (more about the example later).

Another design issue relates to using objects as arguments. In general, I try to avoid using complicated containers as arguments. Instead I favor primitive types such as int (not Integer). Strings are the exceptions and JNI provides convenience mechanisms for handling String.

Now create a Java class to act as the interface between Java and C. Your C methods will be invoked by Java methods marked as "native" (these look like "abstract" methods). This class should also contain a call to "System.loadLibrary()" which will cause your C/C++ objects to be loaded within the JVM.

The "javah" utility will generate a C header based upon "native" declarations within a Java class file. The resulting file looks something like this:

/* DO NOT EDIT THIS FILE - it is machine generated */
#include <jni.h>
/* Header for class com_digiburo_example_native_demo_NdkWrapper */

#ifndef _Included_com_digiburo_example_native_demo_NdkWrapper
#define _Included_com_digiburo_example_native_demo_NdkWrapper
#ifdef __cplusplus
extern "C" {
#endif
/*
* Class: com_digiburo_example_native_demo_NdkWrapper
* Method: nativeSetup
* Signature: ()V
*/
JNIEXPORT void JNICALL Java_com_digiburo_example_native_1demo_NdkWrapper_nativeSetup(JNIEnv *, jobject);
#ifdef __cplusplus
}
#endif
#endif


Note these important features:

1. The "jni.h" file which is distributed w/the JDK and provides Java data type definitions, etc.
2. JNIEXPORT and JNICALL are macros defined within jni.h
   
3. The C method name looks like a Java signature (i.e. package name, method name).
   
4. The C function will always have at least two arguments: the "JNIEnv" pointer and the "jobject" reference. "JNIEnv" points to the virtual machine and "jobject" points to the Java class which invoked the native method (frequently described as similar to "this").
   
5. Remember the JVM cares about method signatures. Item #2 and item #3 come directly from the "native" declarations in Java and must match exactly or your method will not be invoked.

Android NDK relies upon JNI and also provides Android toolchains, i.e. cross compilers for ARM/Intel targets and related libraries along w/a build environment that easily integrates your compiled C/C++ code into an Android APK. There are also a variety of sample applications which are worth your review.

While designing your NDK application note that only a small collection of libraries are distributed w/the NDK (library population varies w/NDK version). For example, I recently needed JPEG support but libjpeg.so is not part of the NDK. In this case you might have to build the libraries you need (be sure to build them using the appropriate cross compiler, etc). In my case I simply used the libjpeg headers and library from the Android platform sources. The point is: until you are a NDK master be sure to pad the schedule in case there is a surprise.

To integrate JNI w/your Android application is simple enough with recent versions of the NDK. Simply create an Android application in eclipse, then create a "jni" directory. The "jni" directory should be a peer to "src", "res", etc. and acts as the root directory for your C/C++ sources.

Eclipse also provides a C/C++ environment which will be handy for flipping between XML, Java and C/C++. My own preference is to do heavy lifting in emacs and my compiles on the command line.

To continue w/implementation, copy the "javah" generated header file to the "jni" directory and craft a source file to support it.

The Android NDK provides a build system which greatly simplifies integrating w/a Android application. Build directives are contained within the "Android.mk" and an optional "Application.mk" files.


#example Android.mk
LOCAL_PATH := $(call my-dir)
#
include $(CLEAR_VARS)
#
LOCAL_CFLAGS := -fexceptions
#
LOCAL_MODULE := digiburo-bridge
LOCAL_SRC_FILES := NdkWrapper.cpp
#
LOCAL_LDLIBS += -llog
#
include $(BUILD_SHARED_LIBRARY)

Note these import features:

1. LOCAL_MODULE defines the name of your C/C++ library. This must match the name specified in System.loadLibrary().
2. LOCAL_SRC_FILES define source files
   
3. LOCAL_LDLIBS specifies link path (in this case to Android logging).

Compile within the "jni" directory by typing "ndk-build" which is a utility supplied w/the NDK.

Assuming a successful compile, you should see the results within your Android project in the "libs" and "obj" directories.

At this point you should be able to deploy and run your Android application using both Java and C.

I have created a sample Android NDK application called "NativeDemo" which is available from my GitHub repository. NativeDemo provides examples for:

1. Java calls C (NdkWrapper.nativeSetup(), NdkWrapper.nativeString(), NdkWrapper.nativeAdder())
2. C invokes Java (NdkWrapper.nativeVectorDemo() and NdkWrapper.callBack())
3. Shared variables (NdkWrapper._nativeBuffer)
4. Exception handling (NdkWrapper.exceptionDemo())
5. Demonstration of JNI_OnLoad() and JNI_OnUnload()
   

To compile and run NativeDemo:

1. You need all the usual Android development tools such as eclipse, Android SDK, ADT plugin and of course the Android NDK.
2. Import my git repository into your eclipse workspace.
3. From the command line, enter the "jni" directory and type "ndk-build" assuming you have the NDK, etc this should compile NdkWrapper.cpp and place the results in the "libs" and "objs" directories.
4. Now run the application from eclipse, it should deploy like any other application.
5. To see the results, use "adb logcat" - note that log messages are generated both from Java and from NdkWrapper.cpp
   

Hope this saves you some time. Good luck!