Android NDK Development Starter Example

ANDROIDNDK is a combination of a series of tools that enable Android app developers to embed native code compiled from c/s + + into an application package.

Note :

ANDROIDNDK can only be used Android1.5 and the above version.

I. Android NDK Target:

The Android virtual machine allows your app to implement methods in the source code via JNI calls to local codes (C + +). To sum up, this means:

--Your application's Java source code declares one or more methods, preceded by the ' native ' keyword, which indicates that they are implemented by local code. Such as:

[Java]View Plaincopy

1. Native byte[] loadFile (String filePath);

--You must provide a local shared library (. So) that contains the implementation of these methods in the library. This library will be packaged in your app's. apk. The name of this library must conform to the standard UNIX naming convention, which is: lib<something>.so this form. Also include a standard JNI entry. For example:

Libfileloader.so

-Your app must load the local library explicitly. For example, to load at app startup, simply add the following statement in your code:

[Java]View Plaincopy

1. static{
3. System.loadlibrary ("Fileloader");
5. }

Note that when you write the name of the library you don't need to use ' Lib ' prefix and the '. So ' suffix.

ANDROIDNDK is just a component of ANDROIDSDK that helps you:

-Creates a JNI-compatible shared library that can run on Android1.5 and above systems running on ARMCPU.

--Put the shared Cucaube in the right place in your app's project and eventually add them to your. APKs.

-In subsequent NDK releases, we intend to provide tools to debug local code through remote GDB and to provide as much source and symbolic information as possible.

The ANDROIDNDK also provides:

-A series of cross-platform compilation tools (compilers, linker, and so on) that generate binary code on arm in Linux,os X and Windows (using Cygwin).

-a series of header files containing the stable native APIs supported by the Android system, which ensures that the interface you use is still supported in all subsequent releases.

Key Note : Remember that most system libraries are not fixed and may be subject to significant changes in future releases, or even deleted, but "stable APIs " are unchanged.

--a build system that allows developers to write a small number of compiled files describing which source files need to be built. The build system handles all compiler Toolchain/platform/cpu/abi details. Also, subsequent NDK updates can be added to add more compile toolchain, platform, and system interfaces without the need for developer project build files to change.

Ii. The Android NDK does not want to do:

Using the NDK to write generic code that runs on Android devices is not good. Your app should still be written primarily in Java in order to properly handle the events of the Android system to avoid the appearance of the "App unresponsive" dialog box or to process the app's life cycle.

Note that in any case, you can write a small application with native code, and this application is just a little / close the app's Java wrapper .

A deep understanding of JNI is essential. Because many operations in this environment require developers to do some special processing, they are not required in typical general code (Java). These special places include:

--The contents of the VM object cannot be directly used by pointers. For example, you cannot safely get a pointer to a Java 16-bit character array string object and iterate over each of its items in a loop.

--When local code wants to save a handle to a VM object between different JNI calls, the handle needs to be explicitly managed for reference.

The NDK provides header files only for a small subset of the native APIs and libraries supported by Android systems. A typical Android system image, however, contains many local shared libraries, but these should be seen as implementation details that can change radically when the platform is updated or released.

If the library of an Android system is not explicitly supported by the NDK's header file, then the app should not depend on it. Otherwise, the cup will appear after the next system upgrade.

The selected system library will gradually be added to the stable version of Ndkapi.

Iii. NDK Development Practices:

Here is a rough overview of the process of developing native code using the NDK:

1/Place your local code source under path $project/jni/.

2/write a file: $PROJECT/jni/android.mk, to describe your source files.

3/(optional) Describe your project in more detail in file $project/jni/application.mk. Although you don't need to write from scratch, you can handle multi-CPU issues and rewrite the compile/link options. (see docs/application-mk.html for more details).

4/Run "$NDK/ndk-build" under your project path or any of its sub-paths to compile your local code.

The final step will be to copy your app's required shared library to your project's path when the compilation succeeds. Then you can generate the final. apk file in the same way as before.

Below, there are some more details:

III.1/Configuring the NDK:

The previous release requires you to run the ' build/host-setup.sh ' script to configure your NDK. But this step was removed from the 4th edition (NDK R4).

III.2/Place C and C + + source code:

Place your local source in the following path:

$PROJECT/jni/

$PROJECT the path that corresponds to your Android app project.

You can organize the content under JNI, and the path name and path structure will not affect the resulting application package. So you don't have to use a name like com.<mycompany>.<myproject>.

Note that both C and C + + sources are supported. The default C + + file name extension is '. cpp ', but other extensions can also be processed. (See document Docs/android-mk.html).

You can also store your source code in other paths by adjusting the contents of the file ANDROID.MK.

III.3/Write a android.mk build script:

A android.mk file is a very small build script. You write it to describe the source files that you give to the NDK builder. Its syntax is described in detail in the docs/android-mk.html.

The NDK simply organizes your original files into multiple "modules", each of which can be any of the following:

-A static library

-A shared library

You can define multiple modules in one android.mk, or write multiple android.mk files, one for each module.

Note that a android.mk file may be parsed multiple times by the build system, so don't assume that a variable is not defined. By default, the NDK looks for the following build script:

$PROJECT/jni/android.mk

If you want to define ANDROID.MK files under sub-paths, you should include them in the top-level android.mk. There is a function to do this:

include$ (call All-subdir-makefiles)

This will contain the ANDROID.MK files under all the sub-paths of the current build path.

III.4/Write a application.mk build file (optional):

Android.mk describes the modules you want to build, and the Application.mk file describes your app itself. Look at the document Docs/application-mk.html to see what this file allows you to do. This file mainly contains:

-An accurate list of modules required by your application.

-The CPU architecture of the generated machine code.

-optional information like whether you want to build release or debug, special C or C + + compilation parameters, and other build options that need to be applied to all modules.

This file is optional: By default, the NDK builds all the modules listed in Android.mk and is targeted to Cpuabi (Armeabi) by default.

There are two ways of using a application.mk:

-Put it in the $project/jni/application.mk position, then it will be used automatically by the ' Ndk-build ' script.

-Put it in $ndk/apps/<name>/application.mk, $NDK represents your NDK installation path. After that, run "make app=<name>" under the NDK path.

This is the way before the NDKR4. It is currently supported for compatibility reasons, but we strongly encourage you to use the first method. Because it is simple and does not change the path tree structure under the NDK installation path.

III.5/calls the NDK build system:

The best way to build machine code using the NDK is to use the ' ndk-build ' script. You can also use another old way-depending on how you create the ' $NDK/apps ' subdirectory.

Either way, after the compilation succeeds, those binaries that are compiled "naked" (without debugging information) will be copied to the path where your application is located (note that the binary modules that are not "naked" are retained to provide debugging power.) There is no need to copy the non-nude module to the device.

1: Use the ' ndk-build ' command:

The ' ndk-build ' script can be found in the top-level directory where the NDK is installed, and can be downgraded directly to your application's directory (that is, your androidmanifest.xml directory) or any subdirectory.

For example:

CD $PROJECT

$NDK/ndk-build

This launches the NDK build script, which automatically detects your development system and application project files to decide what to build.

For example:

Ndk-build

Ndk-build clean-and empty the compiled binaries.

Ndk-build-b V=1--Force a full recompile and show commands

By default, the script wants to see an optional $project/jni/application.mk and a required $project/jni/android.mk.

Once successful, the resulting binary module (that is, the shared library) is copied to the appropriate location in your project tree. You can then use the ' ant ' Command or the ADP plugin to rebuild the complete app package.

For a more complete description of this script and the available options, see docs/ndk-build.html.

2: Use $NDK/APPS/&LT;NAME&GT;/APPLICATION.MK:

This build is the only option for NDKR4 and the forward version, and is currently supported for compatibility reasons only. We strongly recommend that you use the ' ndk-build ' command as a way of sneaking away because we may soon abandon it.

Use it to do this:

1. Create a subdirectory in your NDK installation directory (not your application path), called: $NDK/apps/<name>/. <name> is an arbitrary name used to describe your application to the NDK build system (no spaces).

2. Write a $4ndk/apps/<name>/application.mk to define a app_project_path that points to your application directory.

3. At the command line, go to the NDK installation path and call the top-level gnumakefile, as follows:

Cd$ndk

Makeapp=<name>

The result is the same as the first method, except that some intermediate products are placed under $ndk/out/apps/<name>/.

Iv. Rebuild your App package:

After using the NDK to produce a binary file, you need to rebuild your app package file (. apk) in the usual way, using the ' ant ' Command or the Adteclipse plugin.

Your new. APK will be embedded in the shared library file and then automatically detached from the system when it is installed on the device.

V. Support for debugging:

The NDK provides a secondary script called ' Ndk-gdb ', which makes it very easy to start a debugging session for your app.

Local debugging can only be performed on devices that are running Android2.2 or higher systems. And no special user rights are required.

For more information, please contact docs/ndk-gdb.html. Briefly, local debugging is divided into the following steps:

1. Make sure your app is debugged (set android:debuggable to "true" in Androidmanifest.xml).

2. Use ' Ndk-build ' to build your shared library, then build your app and install it on your device or emulator.

3. Run your app.

4. Run ' Ndk-gdb ' in your app's directory.

You will see the GDB prompt appear. And then you get the GDB manual, stupid tune.

Original source: http://blog.csdn.net/redoffice/article/details/6654714

Android NDK Development Starter Example