Android JNI/NDK allows developers to use native code like C/C++ code in Android applications. It does this through the Java Native Interface (JNI) which provides a way to create Java objects and call Java methods from native code. The Native Development Kit (NDK) includes tools to compile C/C++ code for the Android platform. JNI allows accessing native methods and data types from Java code. It provides functions for loading native libraries, registering native methods, and manipulating objects, strings, classes and fields between the Java and native environments. Exceptions must be handled when using JNI to ensure stable applications.

1. Android JNI/NDK

2. Android JNI
● Why JNI?
● What is NDK?
● Why NDK?
● Deep into JNI world.

3. Why JNI?
Android is put together of about equal part Java and C.
we need an easy way to bridge between these two totally different worlds
.Java offers Java Native Interface
(JNI) as a framework connecting the world of Java to the native code.

4. More About JNI
JNI is part of Dalvik VM, which allows native code to access java
environment. Like accessing java objects and its methods, members etc.
JNI also facilitates accessing and invoking of native methods from Java
code.
JNI Comes with Primitive and reference types.
Primitive types can be manipulated directly as these are equivalent to native
c.c++ data types
But you need special helper functions to manipulate JNI reference types.

5. What is NDK?
NDK is a toolchain
Cross-compiler, linker, what you need to build for ARM, x86, MIPS, etc.
NDK provides a way to bundle lib.so into your APK
The native library needs to be loadable in a secure way.
NDK "standardizes" various native platforms
It provides headers for libc, libm, libz, lliibblloogg, lliibbjjnniiggrraahhiiccss,
OpenGL/OpenSL ES,
JNI headers, minimal C++ support headers, and Android native app APIs

6. NDK in Action

7. Why NDK/JNI?
For performance
Sometimes, native code still runs faster.
For legacy support
You may have that C/C++ code you’d like to use in your app.
For access to low-level libraries
I n a rare case when there is no Java API to do something.
For cross-platform development
But Adding JNI to your app will make it more complex.

8. Build Process

9. Deep Into JNI world

10. Loading Native Libraries and
Registering Native Methods
Native code is usually compiled into a shared library and loaded before the
native methods can be called.
All the Native methods are declared with native keyword in java.
static {
//use either of the two methods below
System.loadLibrary(“nativelib");
System.load("/data/data/cookbook.chapter2/lib/ libNative.so");
}

11. Registering Native Methods
 JNIEnv Interface Pointer:
Every native method defined in native code at JNI must accept two input
parameters, the first one being a pointer to JNIEnv. The JNIEnv interface pointer is
pointing to thread-local data, which in turn points to a JNI function table shared by
all threads. This can be illustrated using the following diagram:

12. JNIEnv
Gateway to access all predefined JNI functions.
Access Java Fields
Invoke Java Methods.
It points to the thread’s local data, so it cannot be shared.
It can be accessible only by java threads.
Native threads must call AttachCurrentThread to attach itself to VM and to
obtain the JNIEnv interface pointer.
RegisterNatives :
 Two ways:
 1. Using Javah tool.
 2. Using RegisterNative function.

13. Using RegisterNative Method
Prototype:
jint RegisterNatives(JNIEnv *env, jclass clazz, const JNINativeMethod
*methods, jint nMethods);
The clazz argument is a reference to the class in which the native method is
to be registered. The methods argument is an array of the JNINativeMethod
data structure.
JNINativeMethod is defined as follows:
typedef struct {
char *name;
char *signature;
void *fnPtr;
} JNINativeMethod;
name indicates the native method name, signature is the descriptor of the
method's input argument data type and return value data type, and fnPtr is the
function pointer pointing to the native method.
The last argument, nMethods of RegisterNatives, indicates the number of
methods to register. The function returns zero to indicate success, and a
negative value otherwise.

14. JNI_OnLoad
 Invoke when the native library is loaded.
 It is the right and safe place to register the native methods before their
execution.
 JNIEXPORT jint JNICALL JNI_OnLoad(JavaVM* pVm, void* reserved)
 {
 JNIEnv* env;
 if ((*pVm)->GetEnv(pVm, (void **)&env, JNI_VERSION_1_6)) {
 return -1;
 }
 // Get jclass with env->FindClass.
 // Register methods with env->RegisterNatives.
 return JNI_VERSION_1_6;
 }

15. JNI Datatypes

16. Manipulating strings in JNI
 Strings are somewhat complicated in JNI, mainly because Java strings and C strings are internally
different.
 Java programming language uses UTF-16 to represent strings. If a character cannot fit in a 16-bit code
value, a pair of code values named surrogate pair is used
 C strings are simply an array of bytes terminated by a null character
 The Unicode Standard is a character coding system designed to support the
worldwide interchange, processing, and display of the written texts of the
diverse languages and technical disciplines of the modern world. In addition, it
supports classical and historical texts of many written languages.
 Few JNI String Functions:
 jstring NewStringUTF(JNIEnv *env, const char *bytes);
 void GetStringUTFRegion(JNIEnv *env, jstring str, jsize start, jsize len, char
*buf);
 void ReleaseStringUTFChars(JNIEnv *env, jstring string, const char *utf);
 const jbyte * GetStringUTFChars(JNIEnv *env, jstring string, jboolean
*isCopy);

17. Manipulating Objects in JNI
jobject AllocObject(JNIEnv *env, jclass clazz);
jobject NewObject(JNIEnv *env, jclass clazz,jmethodID
methodID, ...);
jobject NewObjectA(JNIEnv *env, jclass clazz,jmethodID
methodID, jvalue *args);
jobject NewObjectV(JNIEnv *env, jclass clazz,jmethodID
methodID, va_list args);
 The clazz argument is a reference to the Java class of which we want to create
an instance object. It cannot be an array class, which has its own set of JNI
functions.
 methodID is the constructor method ID, which can be obtained using the
GetMethodID JNI function.

18. Manipulating Classes in JNI
jclass FindClass(JNIEnv *env, const char *name);
 Majorly used method when writing JNI code.
 Must pass full path of class.
 If you have to call this method for finding the most used class in JNI, it is
better to Cache it.

19. Accessing Java Static and Instance
fileds in Native code
 jfieldID data type: jfieldID is a regular C pointer pointing to a data structure
with details hidden from developers. We should not confuse it with jobject or
its subtypes. jobject is a reference type corresponding to Object in Java,
while jfieldID doesn't have such a corresponding type in Java. However, JNI
provides functions to convert the java.lang.reflect.Field instance to jfieldID
and vice versa.
 Field descriptor: It refers to the modified UTF-8 string used to represent the
field data type. The following table summarizes the Java field types and its
corresponding field descriptors:

21. Accessing static fields
 JNI provides three functions to access static fields of a Java class. They
have the following prototypes:
jfieldID GetStaticFieldID(JNIEnv *env, jclass clazz,
const char *name, const char *sig);
<NativeType> GetStatic<Type>Field(JNIEnv
*env,jclass clazz, jfieldID fieldID);
void SetStatic<Type>Field(JNIEnv *env, jclass clazz,
jfieldID fieldID,<NativeType> value);

22. Accessing instance field
 Accessing instance fields is similar to accessing static fields. JNI also
provides the following three functions for us:
jfieldID GetFieldID(JNIEnv *env, jclass clazz, const
char *name, const char *sig);
<NativeType> Get<Type>Field(JNIEnv *env,jobject
obj, jfieldID fieldID);
void Set<Type>Field(JNIEnv *env, jobject obj, jfieldID
fieldID, <NativeType> value);

23. Calling static and instance methods
from the native code
 jmethodID data type: Similar to jfieldID, jmethodID is a regular C pointer
pointing to a data structure with details hidden from the developers. JNI
provides functions to convert the java.lang.reflect.Method instance to
jmethodID and vice versa.
 Method descriptor: This is a modified UTF-8 string used to represent the
input (input arguments) data types and output (return type) data type of the
method. Method descriptors are formed by grouping all field descriptors of its
input arguments inside a "()", and appending the field descriptor of the return
type. If the return type is void, we should use "V". If there's no input
arguments, we should simply use "()", followed by the field descriptor of the
return type. For constructors, "V" should be used to represent the return
type. The following table lists a few Java methods and their corresponding
method descriptors:

25. Calling static methods:
 JNI provides four sets of functions for native code to call Java methods.
Their prototypes are as follows:
jmethodID GetStaticMethodID(JNIEnv *env, jclass
clazz, const char *name, const char *sig);
<NativeType> CallStatic<Type>Method(JNIEnv *env,
jclass clazz, jmethodID methodID, ...);
<NativeType> CallStatic<Type>MethodA(JNIEnv
*env, jclass clazz, jmethodID methodID, jvalue *args);
<NativeType> CallStatic<Type>MethodV(JNIEnv
*env, jclass clazz,jmethodID methodID, va_list args);

26. Calling instance methods:
 Calling instance methods from the native code is similar to calling static methods.
JNI also provides four sets of functions as follows:
jmethodID GetMethodID(JNIEnv *env, jclass clazz, const
char *name, const char *sig);
<NativeType> Call<Type>Method(JNIEnv *env, jobject obj,
jmethodID methodID, ...);
<NativeType> Call<Type>MethodA(JNIEnv *env,jobject
obj, jmethodID methodID, jvalue *args);
<NativeType> Call<Type>MethodV(JNIEnv *env, jobject
obj, jmethodID methodID, va_list args);

27. Checking errors and handling
exceptions in JNI
 JNI functions can fail because of system constraint (for example, lack of
memory) or invalid arguments (for example, passing a native UTF-8 string
when the function is expecting a UTF-16 string).
 Check for errors and exceptions: Many JNI functions return a special value
to indicate failure. For example, the FindClass function returns NULL to
indicate it failed to load the class. Many other functions do not use the return
value to signal failure; instead an exception is thrown.
 jboolean ExceptionCheck(JNIEnv *env);
 jthrowable ExceptionOccurred(JNIEnv *env);
 void ExceptionDescribe(JNIEnv *env);

28. Throw exceptions in the native
code:
 JNI provides two functions to throw an exception from native code. They
have the following prototypes:
jint Throw(JNIEnv *env, jthrowable obj);
jint ThrowNew(JNIEnv *env, jclass clazz, const char
*message);
 The first function accepts a reference to a jthrowable object and throws the
exception, while the second function accepts a reference to an exception
class. It will create an exception object of the clazz class with the message
argument and throw it.

29. Extended Error Check
 Using CheckJNI

Android also offers a mode called CheckJNI, where the JavaVM and JNIEnv
function table pointers are switched to tables of functions that perform an
extended series of checks before calling the standard implementation.
 List of Errors that CheckJNI tool can catch:
 Arrays: attempting to allocate a negative-sized array.
 Bad pointers: passing a bad jarray/jclass/jobject/jstring to a JNI call, or passing a NULL
pointer to a JNI call with a non-nullable argument.
 Class names: passing anything but the “java/lang/String” style of class name to a JNI call.
 Critical calls: making a JNI call between a “critical” get and its corresponding release.
 Direct ByteBuffers: passing bad arguments to NewDirectByteBuffer.
 Exceptions: making a JNI call while there’s an exception pending.
 JNIEnv*s: using a JNIEnv* from the wrong thread.
 jfieldIDs: using a NULL jfieldID, or using a jfieldID to set a field to a value of the wrong
type (trying to assign a StringBuilder to a String field, say), or using a jfieldID for a static
field to set an instance field or vice versa, or using a jfieldID from one class with instances
of another class.

30. Enabling CheckJNI
 Enable CheckJNI:
 For Production Builds
 adb shell setprop debug.checkjni 1
 For Engineering Builds:
 adb shell stop
 adb shell setprop dalvik.vm.checkjni true
 adb shell start

31. Memory Issues
 Using Libc Debug Mode
 adb shell setprop libc.debug.malloc 1
 adb shell stop
 adb shell start
 Supported libc debug mode values are
 1: Perform leak detection.
 5: Fill allocated memory to detect overruns.
 10: Fill memory and add sentinel to detect overruns.

32. Further Reading
 Native Threads usage
 More about references
 JNI Graphics using OpenGL
 Audio using OpenSL apis.
 http://developer.android.com/training/articles/perf-jni.html

33. Questions??