The Native Development Kit (NDK) is a collection of tools designed to help developers efficiently create C or C++ dynamic libraries and automatically package the .so files and Java applications into an APK. There are several reasons why developers might choose to use the NDK:
1. Code protection: Java code in APKs can be easily decompiled, making it vulnerable to reverse engineering. In contrast, C/C++ libraries are more difficult to reverse compile, offering better protection.
2. Utilization of existing open-source libraries: A vast majority of open-source libraries are written in C/C++ code, making it convenient for developers to incorporate them into their projects.
3. Enhanced execution efficiency: Developing high-performance application logic using C can significantly improve the execution efficiency of an application, resulting in a better user experience.
4. Portability: Libraries written in C/C++ can be easily reused on other embedded platforms, making it simpler for developers to port their applications to different devices.
For the NDK package download link, please refer to this post: http://www.cnblogs.com/yaotong/archive/2011/01/25/1943615.html
I selected: http://dl.google.com/android/ndk/android-ndk32-r10-windows-x86_64.zip
After downloading the NDK zip package, I extracted it to the D:\Android directory:
With this package, there is no need to install Cygwin, as the NDK package already includes integrated Linux compilation functionality. This makes the process more convenient and straightforward for developers.
This article will not go into detail on how to do this. In my example, I added a new Android library-type module to an existing project, named cloudNDKTest.
2. Environment configuration
Click on the menu bar File --> Project Structure, or use the shortcut key Ctrl+Alt+Shift+S. Then, follow the steps shown in the image:
After completing this, a configuration will be generated in the local.properties file:
Create a new Java file and declare a static native method. Don't worry if the method name appears in red:
Execute "Make Project" to compile the corresponding class files, which will be needed later when generating the .h files.
Switch the view from Android to Project, and create a JNI directory under the src/main directory, at the same level as the Java directory.
Click on the menu bar View --> Tool Windows --> Terminal, or use the shortcut key Alt+F12 to bring up the terminal window:
Then, execute the following command in the Terminal window:
cd cloudndktest/src/main
javah -d jni -classpath D:/Android/android-sdk/platforms/android-22/android.jar;../../build/intermediates/classes/debug com.tencent.XXX.XXX.cloudndktest.CloudNdkTest
Here, javah is the tool needed to generate header files, -d specifies the directory location for file creation, and -classpath specifies the file location of android.jar in the SDK folder. After the semicolon, it specifies the class file generated in step 4.
Finally, it will generate:
Create a CPP file in the JNI directory, and do not check the part marked in red below, as the .h file already exists.
Write the CPP file, include the previously created .h file, and implement the specific function.
a. First, add the following content to the module's build.gradle:
The above configuration code specifies the .so library name as CloudNdkTest; the library used during linking, corresponding to the LOCAL_LDLIBS in the Android.mk file; and the final output specifies the .so library under three ABI architectures.
b. Configure the gradle.properties file and add:
android.uesDeprecatedDNK=true
c. Add a reference to the static library in the Java class written in step 3:
d. If you encounter the following error, please create an empty util.c file in the JNI directory. This is said to be a bug in the NDK.
e. Execute "Make Project" to compile the project.
If the CPP implementation uses the STL library, you need to add the following in step 8.a:
Currently, several compilation and linking methods are supported:
stlport_static --> Use the stlport version of STL with static linking
stlport_shared --> Use the stlport version of STL with dynamic linking
gnustl_static --> Use the GNU version of STL with static linking
It is important to note that it is better to compile through static libraries, as this will not cause conflicts between .so files in multiple modules and will also reduce the final package file size.