Android NDK development Quick Start

Introduction:

 

AndroidNDK is a combination of a series of tools that allow Android app developers to embed locally compiled code from c/c ++ into the application package.

 

Note:

AndroidNDK can only be used in Android1.5 and later versions.

 

I. Android NDK goals:
The Android virtual machine allows your application to call the methods implemented in local code through JNI in the source code. In summary, this indicates:

-One or more methods must be declared in the source of your application. These methods must be preceded by the 'native 'keyword, which indicates that they are implemented by local code. For example:

Nativebyte [] loadFile (String filePath );

-You must provide a local shared library that contains the implementation of these methods. This database will pack your application. APK. The Library name must comply with the standard Unix naming rules, that is, lib <something>. so. It also contains a standard JNI entry. For example:

LibFileLoader. so

-Your application must load the local database explicitly. For example, to load an application at startup, simply add the following statement to the Code:

Static {

System. loadLibrary ("FileLoader ");

}

Note that you do not need to use the 'lib' prefix and the '. so' suffix when writing the library name.

AndroidNDK is only a component of AndroidSDK. It helps you:

-A Shared Library compatible with JNI is generated. This library can run on Android1.5 and above systems running on ARMCPU.

-Store shared databases to the desired location of your application project, and finally upload them to your .apk s.

-In subsequent NDK versions, we plan to provide tools for remote gdb debugging of Local Code and provide as much source code and symbolic information as possible.

 

AndroidNDK also provides:

-A series of cross-platform compilation tools (compiler, linker, and so on) that can generate binary code on ARM on Linux, OS X, and Windows (using Cygwin.

-A series of header files correspond to the stable local APIs supported by the Android system. This ensures that your interfaces are still supported in all subsequent versions.

 

Important:

Remember that most system libraries are not fixed and may change or even be deleted in future versions, but "stable APIs" remain unchanged.

 

-A build system allows developers to write only a small number of compiled files to describe which source files need to be built. The build system can process all compilation toolchain/platform/CPU/ABI details. In addition, you can add more compilation tool chains, platforms, and system interfaces in subsequent NDK updates without changing the developer's project build files.

 

II. What Android NDK does not want to do:
Using NDK to write general local code running on android devices is not good. Your application should still be written in Java to correctly handle Android system events to avoid the emergence of the "Application No response" dialog box or process the application lifecycle.

 

Note: In any case, you can write exquisite applications using local code. This application only contains a small package for starting/disabling applications.

 

It is necessary to have a deep understanding of JNI. Because many operations in this environment require special processing by developers, they are not required in typical General Code (java. These include:

-You cannot directly use VM object content through pointers. For example, you cannot safely obtain a pointer to a 16-character array of a java String object and enumerate each of its items in a loop.

-When the local code wants to save the VM object handle between different JNI calls, it needs to explicitly reference and manage the handle.

 

NDK only provides header files for a few local APIs and libraries supported by android. However, a typical Android system image contains a lot of Local Shared libraries, but these should be seen as implementation details. These implementations may be completely changed when the platform is updated or released.

If the library of an Android system is not explicitly supported by the NDK header file, the application should not rely on it. Otherwise, the cup may appear after the next system upgrade.

The selected system library is gradually added to the stable version of NDKAPI.

 

III. NDK development practices:
The following is a rough overview of the local code development process using NDK:

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

2. Write a file $ PROJECT/jni/Android. mk to describe your source files.

3/Optional: describe more details about your PROJECT in the file $ PROJECT/jni/Application. mk. Although you do not need to write from the beginning, you can handle multiple CPU problems and rewrite the compilation/link options. (For more details, see docs/APPLICATION-MK.html ).

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

 

The last step is to copy the shared library required by your application to the path of your project when compilation is successful. Then you can follow the previous example to find the final. APK file.

 

Below are some more details:

 

III.1/configure NDK:
Previous releases require you to run the 'build/host-setup.sh 'script to configure your NDK. However, this step was removed from version 4th (NDK r4.

 

III.2/place C and C ++ source code:
Put your local source code in the following path:

$ PROJECT/jni/

$ PROJECT corresponds to the path of your android Application PROJECT.

You can organize the content under jni at will. The path name and path structure will not affect the final application package. Therefore, you do not need to use a name similar to com. <mycompany>. <myproject>.

Note that both C and C ++ source code are supported. The default C ++ file extension is '. cpp', but other extensions can also be processed. (See docs/ANDROID-MK.html ).

You can also save your source code to other paths by adjusting the content of the Android. mk file.

 

III.3/write an Android. mk build script:
An Android. mk file is a small build script. You write it to describe the source code files you provide to the NDK builder. Its syntax is described in detail in the docs/ANDROID-MK.html.

 

NDK simply organizes your original file into multiple "modules". Each module can be any of the following:

-A static library

-A Shared Library

 

You can define multiple modules in an Android. mk file or write multiple Android. mk files. Each file corresponds to only one module.

Note that an Android. mk file may be used to analyze the system multiple times, so do not assume that a variable is not defined. By default, NDK looks for the following build script:

$ PROJECT/jni/Android. mk

If you want to define the Android. mk file in the sub-path, you should include them in the top-level Android. mk. There is a function that can do this:

Include $ (call all-subdir-makefiles)

This will contain the Android. mk files under all sub-paths of the current build path.

 

III.4/write an Application. mk Build File (optional ):

Android. mk describes the modules you want to build, and the Application. mk file describes your Application. Read the documentation docs/APPLICATION-MK.html to learn what this file allows you to do. This file mainly includes:

-Accurate list of modules required by your application.

-The CPU architecture corresponding to the generated machine code.

-Optional information, such as whether to build release or debug, special C or C ++ compilation parameters, and other building options that need to be applied to all modules.

 

This file is optional: by default, NDK builds all modules listed in Android. mk and is oriented to CPUABI (armeabi) by default ).

There are two ways to use an Application. mk:

-Place it in the $ PROJECT/jni/Application. mk location, and it will be automatically used by the 'ndk-build' script.

-Place it in $ NDK/apps/<name>/Application. mk. $ NDK indicates your NDK installation path. Then, Run "make APP = <name>" in the NDK path ".

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

 

III.5/call NDK to build the system:

The best way to build machine code with NDK is to use the 'ndk-build' script. You can also use another old method-depending on the method of creating the '$ NDK/apps' subdirectory.

Either way, after compilation is successful, the compiled "naked" (without debugging information) binary modules will be copied to the path where your application project is located (note that non-"naked" binary modules will be retained to provide debugging capabilities. There is no need to copy the non-"naked" module to the device ).

 

1: run the 'ndk-built' command:

 

The 'ndk-built' script can be found in the top-level directory where the ndk is installed. You can directly find the directory of your application project (that is, your AndroidManifest. xml directory) or any subdirectory.

For example:

Cd $ PROJECT

$ NDK/ndk-build

 

This will start the NDK build script, which will automatically detect your Development System and Application project files to decide what to build.

For example:

Ndk-build

Ndk-build clean --> clear compiled binary files.

Ndk-build-B V = 1 --> force full re-compilation and display the command

 

By default, the script displays an optional $ PROJECT/jni/Application. mk and a required $ PROJECT/jni/Android. mk.

After successful copying, the generated binary module (that is, the shared library) will be copied to an appropriate location in your project tree. You can use the 'ant' command or the ADP plug-in later to recreate the complete application package.

For a more complete description of this script and available options, see docs/NDK-BUILD.html.

 

2: use $ NDK/apps/<name>/Application. mk:

 

This build method is the only choice for NDKr4 and earlier versions. It is currently supported only for compatibility reasons. We strongly recommend that you use the 'ndk-build' command because we may soon discard this method.

Use it to do this:

1. Create a sub-directory under 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 space is allowed ).

2. Write $ 4NDK/apps/<name>/Application. mk, and define an APP_PROJECT_PATH in it to point to your Application project directory.

3. In the command line, enter the NDK installation path, and then call the GNUMakefile at the top level, as shown below:

Cd $ NDK

MakeAPP = <name>

The results are the same as those in the first method, except for some intermediate products under $ NDK/out/apps/<name>.

 

IV. Recreate your application package:

After using the ndk1_2 file, you need to create your application package (.apk) in the common format, that is, using the 'ant' command or the ADTEclipse plug-in.

Your new .apk will be embedded in the shared library file, and then automatically separated by the system when installed to the device.

 

V. debugging support:

NDK provides an auxiliary script called 'ndk-gdb 'to easily start a debugging session for your application.

 

Local debugging can only be performed on devices running Android2.2 or higher systems. Special user permissions are not required.

For more information, see docs/NDK-GDB.html. Local debugging involves the following steps:

1. Make sure your application is debuggable (set android: debuggable to "true" in AndroidManifest. xml ").

2. Use 'ndk-build' to build your shared library, build your application, and install it on the device or simulator.

3. Run your application.

4. Run 'ndk-gdb 'in your application project directory '.

 

You will see the gdb prompt. Then you can use the GDB manual for Dummies.

 

From the column of nkmnkm