Overview of Android-NDK-r4b Learning

Two days ago, I was asked if I knew about ndk development in Android. At that time, I was told that I had heard of such a toolset. But I knew nothing about what to do, how to use it, and why to use it. So I decided to study hard. Ndk is the latest version of r4b, I learn the information is mainly NDK-r4b built-in docs/directory. txt file.

Android ndk is a tool set. Using ndk, You can embed the compiled binary code of local code written in C/C ++ in Java applications, binary codes exist as dynamic libraries. However, ndk can only be used for versions 1.5 and later.

There are three goals for developing ndk:
: First, call local programs implemented through JNI in the application (written in C and C ++); second, play an auxiliary role in the SDK; and third, provide some tools and platform description files.

There are several things to do to achieve the first ndk goal:

1. In an application, the class is usually written in Java. The "Native" keyword is used to declare the local program to be called. The program written in C and C ++ is called a local program, which is relative to an application running on a virtual machine (VM. For example, native byte [] LoadFile (string filepath );

2. Upload the dynamic library of the program containing 1 voice, and package it into the .apk of the application. The dynamic library name must follow the Unix conventions and adopt lib <something>. So, which contains the JNI entry point. For example, libfileloader. So

3. Load the dynamic library provided by 2 displayed in the application. The following code is usually added at the beginning of an application:

Static {

System. loadlibrary ("fileloader ");

}

Note: When a dynamic library is referenced here, the Lib prefix and. So suffix are not required.

The auxiliary functions of ndk on SDK are as follows:

1. Generate a dynamic library compatible with the JNI standard and run it on arm cpu + 1.5 and later platforms.

2. compile and generate a dynamic database to fit the application project, and then automatically copy it to .apk. Running ndk-build automatically completes compilation and packaging.

3. Currently, no local code debugging tool is provided. In future versions, we will consider adding a tool for remote GDB connection debugging.

Ndk provides a set of tools and files:

1. A set of cross-compilation tools, including compilers and connectors, can be used to generate arm binary files on Linux, OS X and windows (through cygwin) platforms.

2. A set of system header files corresponding to the stable local API list supported by the Android platform are described in the file docs/STABLE-APIS.TXT. The stable API here refers to the APIs that can be supported by the current and later versions, because most local system libraries are not static in Android system images, it may change a lot or even be deleted from a later version of the current system.

3. A system build tool allows developers to write short build files (Android. mk/application. mk) to describe which source files need to be compiled and how to compile them. In subsequent versions, ndk will continue to update the system build tool set and platform system interface without the need for developers to modify their build files.

In addition, ndk also provides a set of samples, you can read the code above to feel the essence of ndk development more intuitively.

As a ndk user, in addition to understanding what ndk can do, there are also notes that ndk as a tool and auxiliary means, there must be limitations, as the top of the sword of the De cikus
Therefore, developers also need to master the following rules:

1. Do not use ndk to develop general programs running on Android devices. In particular, applications and System Event Handlers should be written in Java. Although complex applications can be written using local ndk encoding, This is not recommended. Based on my development experience, the cost is too high. I may use several lines of Java code and several hundred lines of local code with ndk. This is related to the JNI mechanism, java code must be called back in C/C ++ code through a series of methods.

2. Have a good understanding of the JNI interface standard, because the standard requires developers to adopt some special practices, and these practices are not typical common operations of local code, such:

1}. The local code cannot directly access the object content on the VM (Virtual Machine.

2} when the local code wants to process objects on the VM in the JNI call, it must display it for reference management. The JNI standard supports three types of references: localref, globalref, and weakglobalref. Local Code must properly handle these references. Otherwise, memory leakage or program crash may occur.

3. ndk provides system header files and library files for a very limited number of local APIs supported by the Android platform. A typical Android system image contains a large number of other local dynamic libraries, this approach aims to consider that libraries not included in the ndk may be greatly modified in later Android versions. Therefore, in actual applications, applications should not rely on those non-ndk libraries.

 

The steps for developing ndk are summarized as follows:

1. Place the local code in the path $ Project/JNI/... where $ project refers to the top-level directory of the current Java application project.

2. Compile the Android. mk file for the local code and place it in the $ Project/JNI/... directory. This file is the build description file of the local code.

3. Optional: Write application. mk, which is also placed in the $ Project/JNI/... directory. This file describes the construction process of the project in more detail. Although this is not necessary, developers can specify multiple CPU platforms to modify the compilation and connection flags. For more information, see Docs/APPLICATION-MK.TXT

4. Run the $ ndk/ndk-build command in the $ Project/JNI directory to build the local code. If you have added the ndk installation path $ ndk to the system standard path, you can directly run ndk-build. If the build is successful, the generated dynamic database will be automatically stored in the libfolder under the current project directory and merged to .apk.

The detailed description of ndk development steps is as follows:

1. Before ndk development, you must configure the ndk. The configuration of a previous version of the NDK-r4b is done directly by running build/host-setup.sh. This process has been removed in this version, so there is no host-setup.sh script in the build project. You really need to extract the downloaded ndk Development Kit directly. However, to facilitate use, it is best to add the decompressed directory to the standard path of the system, in this way, you can directly use the ndk command in any path in the system.

2. Place the C/C ++ source file: directly go to the $ Project/JNI/directory. If the JNI directory does not exist, create it. The file organization in JNI is very free. The directory name and structure do not affect the packages generated by the application. Therefore, developers do not need to execute file commands like in the application package. The default extension for C ++ files is. cpp, and other types of extensions can also be processed. For details, see Docs/ANDROID-MK.TXT. Of course, you can also place the C/C ++ source file elsewhere by adjusting the Android. mk file.

3. Android. mk Script: this is a small script for ndk development. It describes the construction of local code in ndk. Ndk compiles local code into one or more modules, which may be a dynamic library or a static library. It is worth noting that an android. mk can define the construction of multiple modules, or you can write an android. mk for each module separately. If a single Android. mk corresponds to multiple modules, Android. mk may be read multiple times by the build system. Therefore, do not make assumptions that some variables are not defined in Android. mk. Android. MK is placed in the $ Project/JNI directory. If you want to put MK in a subdirectory, you must go to the android directory in the top-level directory. include $ (call all-subdir-makefiles) indicates that the build system traverses all Android devices in the subdirectory of the current build file. mk.

4. Application. MK writing (optional): relative to the android. MK is used to describe the construction of the application. The description usually includes: the list of all modules required by the application, the target CPU architecture, the compiled version (debug or release), the C/C ++ compilation mark, and other optional compilation options for all modules. This file is optional. ndk provides a simple Android. mk file by default, which only lists all modules to be built. The default CPU architecture is Abi (armeabi ). Application. mk can be used in two ways:

1} directly put it in the $ Project/JNI directory, and the ndk-build script will automatically read

2) set the application. MK is placed in the $ ndk/apps/<Name>/directory. $ ndk is the installation directory of ndk. In this directory, run the command: Make APP = <Name> to execute this script. This method is commonly used by ndk versions earlier than r4b. To maintain compatibility, r4b also supports this method. However, this method is not recommended. It is a recommended method, which is relatively simple, you do not need to care about the ndk installation path.

5. Start ndk to build the system. There are two methods:

1) run the ndk-build command: The ndk-build script is located under $ ndk.

2) use $ ndk/apps/<Name>/application. mk. This method is used in versions earlier than r4b. Although it can also be used in r4b, it is not recommended. Therefore, using this method is cumbersome and requires the following steps:

First, create a subdirectory $ ndk/apps/<Name>/Under the ndk installation directory to describe the application to the ndk system. spaces are not allowed.

Second, write application. mk and place it under $ ndk/apps/<Name>/. In application. mk, You need to define app_project_path to point to the project directory $ project.

Finally, switch to $ ndk and execute the command: Make APP = <Name>

 

Ndk debugging support: the ndk-GDB script is provided in the ndk to start local debugging sessions in the application. Local debugging is only applicable to android2.2 and later versions. You only need to enable debuggable for the application without the root permission or other special access permissions. For more details, see Docs/NDK-GDB.TXT. However, the startup of local debugging can be summarized into the following steps:

1. Make sure that the debuggable of the application has been started. Set Android: debuggable to true in androidmanifest. xml;

2. Use ndk-build to build an application and install it on the device/simulator;

3. Start the application on the device/simulator;

4. Run ndk-GDB under the application project directory $ Project

In this case, the gdb command line will appear. You can refer to the commands in the gdb user manual for debugging.