Android NDK Overview

Reprinted from Smoilbig final edit Smoilbig

Google's open Android NDK allows the Android platform to support the development of native C native code. The development kit for the Android NDK (native Developer Kit) is for the bottom developer (applause). ）。 However, it is necessary to understand that NDK does not support the Android Framework api,android system and does not allow a single program that uses C + + only to appear, but embeds it through Java code native C or a JNI way to invoke a static library to execute local (Native) code, which will eventually be packaged in a apk file or run in a Dalvik VM virtual machine. Nevertheless, NDK offers us a solution for high-performance applications.

All software running on the Android system runs in the Dalvik VM virtual machine, NDK can meet some developers to achieve the localization of code, use C + + development application of the core, efficient part, make Android running High-performance software is possible. It can also help developers make the most of their existing good C + + code, porting the code faster to Android.

what the NDK provides.
1. A tool that can be generated as a local run-time library by generating A/C + + source code.
2. A tool that embeds the local runtime into an application package (. APKs).
3. A set of local system header files (. h) and libraries (. lib) will support versions from Android 1.5 and beyond.
4. Of course, there are documentation, examples, and tutorials.

NDK supports the ARMv5TE machine instruction group and provides a stable header file:
* libc, the standard C library
* LIBM, the standard math library
* The JNI interface
* Libz, the common ZLib compression library
* Liblog, used to send logcat messages to the kernel

Using NDK for common functionality does not necessarily improve the performance of the application, but it does not necessarily increase the complexity of the development.
you can use NDK in the following situations:
1. Very sensitive to the performance of the algorithm
2. Do not need to allocate too much memory operation, such as signal processing, physical simulation, etc.
3. Reuse the existing mass of C + + good code



The Android developer site also warns that the application NDK will not be relevant to all Android programs. As a developer, it is important to weigh its many advantages and disadvantages, and the program will be more complex, less compatible, and inaccessible to the framework API and more difficult to debug. That is, some programs that are independent and do not allocate a lot of memory to a centralized CPU operation will improve performance and code reuse. such as signal processing, intensive physical simulations and certain types of data processing.

1. Preface
June 26, Google Android released a ndk, attracted a lot of people's interest. NDK Full Name: Native Development Kit. The download address is: http://developer.android.com/sdk/ndk/1.5_r1/index.html.

2. Misunderstanding
New Born things, in addition to surprises, will also bring us a certain confusion, misunderstanding.

2.1. Misunderstanding one: Android does not support C development until NDK is released
Google search for "NDK", a lot of "Android can finally use C + + development" title, which is a misunderstanding of the Android platform programming methods. In fact, the Android platform since its inception, has supported C, C + + development. As we all know, the Android SDK is based on Java implementation, which means that third-party applications that are developed based on the Android SDK must use the Java language. But this is not equivalent to "Third-party applications can only use Java." When the Android SDK was first released, Google claimed that its virtual machine Dalvik supported JNI programming, where third-party apps could invoke their own C-dynamic libraries through JNI, meaning that the "java+c" programming approach was always achievable on the Android platform.

Of course there is a source of this misconception: there is no JNI help in the Android SDK documentation. Even if a Third-party application developer uses JNI to complete its own C Dynamic link library (so) development, how so is packaged with the application as APK and released. There are also technical hurdles. I used to spend a lot of time installing the crossover compiler to create so, and through the asset (Resource) way, to implement the bundle so release. But this approach can only be in a tricky way, and unofficially supported. So, before ndk out, we call the "JAVA+C" development model the grey model, which means that the official does not declare "support" or "does not support this approach".

2.2, misunderstanding two: with NDK, we can use pure C to develop Android applications
The Android SDK is published in the Java language, excluding a number of C developers from Third-party application development (Note: All of our discussions are based on "Third-party application development", and the Android system is based on Linux, and system-level development must support C language.) ）。 NDK's release, many people will mistakenly think, similar to Symbian, WM, on the Android platform can finally use pure C, C + + development of third-party applications. In fact, the NDK document clearly indicates that it is not a good way. Because NDK does not provide various system event handling support, it does not provide application lifecycle maintenance. In addition, the API for the application UI is not available in the NDK of this release. At least for now, the use of pure C, C + + to develop a complete application of the conditions are not complete.

3. What is NDK
After a rough study of NDK, my understanding of what "NDK is" is as follows:

1. NDK is a collection of tools.

NDK provides a range of tools to help developers quickly develop a C (or C + +) dynamic library and automatically package so and Java applications as APK. The tools that help developers are huge.
NDK integrates the crossover compiler and provides the corresponding MK file isolation CPU, platform, ABI, and so on, the developer simply modifies the Mk file (indicating "which files need to compile", "Compile attribute Requirements", etc.) to create the so.
NDK can automatically package the so and Java applications, greatly reducing the developer's packaging work.
2, NDK provides a stable, limited function of the API header file statement.

Google explicitly declares that the API is stable and supports the current published API in all subsequent releases. As you can see from this version of NDK, these APIs support a very limited number of functions, including the C standard library (LIBC), the standard math Library (LIBM), the compression library (LIBZ), and the log library (Liblog).

4, NDK bring what
1, NDK release, so that "java+c" the development of the way to finally become a positive, the official support of the development of the way.

With NDK, we can use C to develop the application logic that requires high performance, thereby increasing the execution efficiency of the application.
Using NDK, we can use C to develop the application logic that needs to be kept secret. After all, Java packages can be decompile.
NDK the presence of professional so component vendors. (optimistic guesses, depending on the number of Android users)
2, NDK will be the Android platform to support the beginning of C development.

NDK provides a collection of development tools that enable developers to easily develop and publish C components. At the same time, Google is committed to the next version of NDK to improve the "adjustable" ability, that is, the provision of remote GDB tools, so that we can easily debug C source code. In support of Android platform C Development, we can feel that Google has spent a lot of effort, we have reason to think that "C component support" is just Google Android platform for the start of C development. After all, C programmers are still the absolute mainstay of the farming camp, excluding them from Android apps, apparently against the Android platform.

At present, the Android NDK can only compile the dynamic library. So file, not to generate the. apk file, here we briefly introduce the Hello Jni in NDK. The entire example is divided into Java and native C two sections. The first is our common Java-side invocation section.

Package com.example.hellojni;

Import android.app.Activity;
Import Android.widget.TextView;
Import Android.os.Bundle;

public class Hellojni extends activity
{
@Override
public void OnCreate (Bundle savedinstancestate)
{
Super.oncreate (savedinstancestate);

TextView TV = new TextView (this);
Tv.settext (Stringfromjni ()); If the call fails, the Java.lang.UnsatisfiedLinkError exception is thrown
Setcontentview (TV);
}// note the following native keyword

Public native String stringfromjni ();
Public native String unimplementedstringfromjni ();

static {
System.loadlibrary ("Hello-jni"); Load into Hello-jni library
}
}

It is important to note that the SDK version 1.5 or above must be set up to indicate the <USES-SDK android:minsdkversion= "3" in the Androidmanifest.xml file/> Here we see that JNI calls do not require special permissions.

The C/C + + native can be used directly in the library, but this includes the JNI header file.

#include <string.h>
#include <jni.h>

The following return type jstring is a VM String and is defined in the jni.h header file

jstring Java_com_example_hellojni_hellojni_stringfromjni ( jnienv* env, Jobject thiz)
{
Return (*ENV)->newstringutf (env, "Hello from JNI, Android123 test!");
}

In fact, it is very well understood, just to change the alias, and to define the following

typedef uint8_t Jboolean; /* Unsigned 8 bits * *
typedef int8_t Jbyte; /* Signed 8 bits * *
typedef uint16_t JCHAR; /* Unsigned bits * *
typedef int16_t Jshort; /* Signed BITS * *
typedef int32_t Jint; * Signed Bits * *
typedef int64_t Jlong; /* Signed BITS * *
typedef float JFLOAT; /* 32-bit IEEE 754 */
typedef double jdouble; /* 64-bit IEEE 754 */
#else
typedef unsigned char Jboolean; /* Unsigned 8 bits * *
typedef signed Char Jbyte; /* Signed 8 bits * *
typedef unsigned short Jchar; /* Unsigned bits * *
typedef short Jshort; /* Signed BITS * *
typedef int JINT; * Signed Bits * *
typedef long Long Jlong; /* Signed BITS * *
typedef float JFLOAT; /* 32-bit IEEE 754 */
typedef double jdouble; /* 64-bit IEEE 754 */
#endif

typedef jint Jsize;

There are also statements that invoke the usual attention

#define JNI_FALSE 0
#define JNI_TRUE 1

#define Jni_version_1_1 0x00010001
#define Jni_version_1_2 0x00010002
#define JNI_VERSION_1_4 0x00010004
#define JNI_VERSION_1_6 0x00010006

#define JNI_OK (0)/* No error * *
#define JNI_ERR ( -1)/* Generic Error * *
#define JNI_EDETACHED ( -2)/* thread detached from the VM * *
#define JNI_EVERSION ( -3)/* JNI version Error */

#define JNI_COMMIT 1/* Copy content, do not free buffer * *
#define JNI_ABORT 2/* Free buffer w/o copying back * *

#define Jniimport
#define Jniexport
#define Jnicall