Preface
As we all know, the Android SDK is implemented based on Java, which means that third-party applications developed based on the Android SDK must use the Java language. But this is not the same as "third-party applications can only use Java." When the Android SDK was first released, Google announced that its virtual machine Dalvik supports JNI programming, that is, third-party applications can call their own C dynamic libraries through JNI, that is, on the Android platform, the "Java+C" programming method is It has always been possible. So the NDK came into being. On June 26, 2009, Google Android released the NDK, download link .
1 Basic concepts of NDK
1.1 Definition of NDK
NDK, or Native Development Kit, is a development kit in Android that enables you to use C and C++ code in Android applications, and provides many platform libraries . You can use these platform libraries to manage native Activity and access physical device components, such as Sensor and touch input. NDK is a way for us to realize the interaction between Java and Native.
1.2 The role of NDK
Can quickly develop C, C++ dynamic libraries, and automatically package so and applications into APKs. You can make Java and Native code (such as C, C++) interact through the NDK.
1.3 Advantages of NDK
(1) Allow program developers to directly use C/C++ source code, which greatly improves the flexibility of Android application development.
(2) Transplant and use third-party libraries for cross-platform applications. For example, many third-party libraries only have C/C++ language versions, while Android applications need to use existing third-party libraries, such as FFmpeg, OpenCV, etc., they must use NDK.
(3) C++ code is used to process high-performance operations, which improves the performance of Android APP.
(4) High security. Because the Java layer code of the apk is easy to be decompiled, and the C/C++ library is more difficult to disassemble.
1.4 The relationship between NDK and SDK
In Android development, SDK is the most commonly used, so what is the relationship between SDK and NDK?
- In SDK, we use Java for development, and in NDK, we use C++ for development.
- SDK supports most of the operations in Android development, such as UI display, user interaction with mobile phones, etc. It mainly supports the basic functions of Android APP development. NDK supports some complex and more advanced operations, such as audio and video parsing, a large amount of data calculation, and improving the running speed of Android games, mainly some advanced functions of Android APP.
Therefore: NDK and SDK are in a parallel relationship, and NDK is an effective supplement to SDK .
2 Components of NDK
2.1 JNI
2.1.1 Definition of JNI
JNI, or Java Native Interface, is a programming framework that enables Java programs in the Java virtual machine to call local applications or libraries, and can also be called by other programs. Native programs are generally written in other languages (C, C++ or assembly language, etc.) and are compiled into programs based on the native hardware and operating system. Of course, JNI is not a concept proposed in Android, but is originally provided in Java.
In the above, NDK also supports the interaction between Java code and Native code, so what is the difference between them?
In fact, JNI is a programming framework, an abstract thing, and NDK is a toolkit.
So: NDK is a way to implement JNI in Android .
2.1.2 Advantages of JNI
When some things cannot be handled by Java, JNI allows programmers to use other programming languages to solve them, for example, platform-related functions or libraries that are not supported by the Java standard library. It is also used to transform existing programs written in other languages for Java programs to call.
2.1.3 Steps to use JNI
(1) Use the native keyword to define the Java method (that is, the native method that needs to be called)
(2) Use javac to compile the above Java source file (ie. java file) and finally get the .class file
(3) Compile the .class file through the javah command Finally export the JNI header file (.h file)
(4) Use C/C++ to implement the native method declared in Java
(5) Compile the .so library file
(6) Load the dynamic library through the Java code, and then call the native method
In fact, the purpose of steps 2, 3, 4, and 5 is to generate .so files.
So the above steps can be summarized into three steps:
(1) Declare the native method
(2) Implement the native method, generate the .so file
(3) Load the .so file, call the native method
2.2 .so and .a files
As we have mentioned above, JNI supports the mutual calling of Java code and Native code.
But does JNI directly call Java code and Native code? In fact, JNI calls the compiled .so and .a files of Java code and Native code to realize the interaction between Java code and Native code.
So what are .so and .a files? Some definitions of .so and .a files are listed below:
- Dynamic link library (.so suffix): This library is dynamically loaded at runtime. Dynamic link library is also called shared library, because shared is used to mean dynamic library in NDK.
- Static link library (.a suffix): When compiling, the static library is packaged into the APK.
- Disadvantages: Use static library to compile, it takes longer to compile, and it also makes APK bigger.
- Advantages: Only export one library, you can hide the library you call.
- Both .so and .a are essentially binary files.
- Each CPU system can only use the corresponding binary files, that is, they are not like jar packages. All CPU systems can use a jar package. Each system of .so and .a must use its own, and cannot use others. For example, the .so file of armeabi cannot be applied to x86.
2.3 HELP
ABI stands for Application Binary Interface. As we said above, each CPU system can only use the corresponding binary file. Different Android devices use different CPUs, and different CPUs support different instruction sets. Each combination of CPU and instruction set has its own application binary interface (ABI). In short: ABI defines how the binary file runs on the corresponding CPU .
So, what are the CPU architectures?
The Android platform supports a wide range of device models. In terms of the core CPU of the device, there are three major categories: ARM, x86 and MIPS. After NDK r17, NDK no longer supports 32-bit and 64-bit MIPS and ARM v5 (armeabi). ARM and x86 are divided into 32-bit and 64-bit respectively, which are divided into 4 types.
We can simply think: ARM is mainly used in mobile phones, and x86 is mainly used in PCs. The main reason for using x86 in Android is that the emulator on the PC requires x86.
Now we have a general understanding of the CPU architecture commonly used in Android, and we know that the ABI defines how the binary file runs on the CPU, then we can know that every CPU architecture must have a corresponding ABI.
We already know that there are four kinds of ABI, so there are four kinds of ABI, they are: armeabi-v7a , armeabi-v8a , x86 , x86_64 .
| HELP | Corresponding CPU architecture | application |
|---|---|---|
| armeabi-v7a | ARM 32 bit | Cell phone |
| armeabi-v8a | ARM 64 bit | Cell phone |
| X86 | X86 32 bit | PC |
| X86_64 | X86 64 bit | PC |
NDK compilation actually compiles all system files by default, but sometimes we only need to use the specified system, we can specify which system to compile, reduce the binary files, and avoid the binary files that we will not use to be packaged into the apk. We can use the following code to specify what CPU architecture binary file we want to compile:
//在module的build.gradle中
android {
defaultConfig {
ndk {
abiFilters 'armeabi-v7a', 'x86'
}
}
}
2.4 Compilation tools
2.4.1 Native compilation tools
We already know that each system can only use the binary files of its own system, and the native compiler tool is to compile the binary files that can be used by the native system. There are two native compilation tools that can be used in Android: ndk-build and CMake . These two methods have nothing to do with Android code and c/c++ code, but different build scripts and build commands.
2.4.2 Cross compilation tool
Corresponding to native compilation, sometimes we need to compile binary files of other systems. For example, if we write Android files on the PC, then we need to compile binary files that can run in Android on our PC. The cross compilation tool is also called the cross compilation chain (toolchain). In the NDK, there are two main cross-compilation tools: clang and gcc . After NDK r17c, clang is used by default.