Android NDK compilation option settings [Zhuan]

http://crash.163.com/#news/!newsid=24

In Android NDK development, there are two important files: Android.mk and application.mk, each of which instructs the compiler how to compile the program and decide what the compilation results are. This article will explain in detail the configuration of several common NDK options to help you understand the appropriate configuration options.

First, APPLICATION.MK

APPLICATION.MK is actually a lightweight makefile, which is typically used in the $PROJECT/JNI directory to configure all modules compiler variables, as shown in the following example:

App_abi: = Armeabi arm64-v8a x86_64 x86 armeabi-v7a
Ndk_toolchain_version: = clang3.5
App_stl: = stlport_static
app_optim:= Debuge

1. App_abi (target platform ABI type)

In NDK compilation, App_abi chooses the Armeabi Abi by default, setting one or more ABI settings App_abi, and table one is the instruction set for different App_abi.

Instrunction Set	Value
ARMv5TE based CPU	App_abi: = Armeabi
ARMV7 based CPU	App_abi: = armeabi-v7a
ARMV8 AArch64	App_abi: = arm64-v8a
IA-32	App_abi: = x86
Intel64	App_abi: = x86_64
MIPS32	App_abi: = MIPS
MIPS64 (R6)	App_abi: = Mips64
All supported instruction sets	App_abi: = All

Table I: Abi type

        App_abi can be selected on demand at development time, and the ABI selection takes into account efficiency and apk size. Because the armeabi-v7a instruction set is compatible with Armeabi, the x86 mobile phone in the market for compatibility, the basic use of Libhoudini module, compatible with ARM instruction set, 64-bit model by default supports the 32-bit ABI so, in the case of high size requirements, You can select only the Armeabi ABI that is basically compatible with the device on the market, and if you have a slight performance requirement, you can add the x86 ABI.

      2, ndk_toolchain_version (compiler type, version)

        The default is the GCC compiler, For the GCC version of the choice is related to the NDK version, I am using the NDK R12, the 64-bit ABI by default is GCC 4.9, the 32-bit ABI default is GCC 4.8, of course, you can also set the Clang compiler as shown in the example above.

      3, App_stl (runtime type)

       android NDK uses the smallest supported C + + runtime by default. If you need to use STL in your NDK program, you can set App_stl := stlport_static,app_stl to have several values in table two.

using statically linked methods with dynamic linking using statically linked methods with dynamic linking with dynamic linking

Name	explanation
System (default)	system default C + + Runtime library
stlport_static	sttport versions of STL
stlport_shared	sttport versions of STL
gnustl_static	gnustl versions of STL
gnustl_shared	gnustl versions of STL
gabi++_static	used statically linked gabi++
gabi++_shared	gabi++
c++_static	LLVM with static linking libc++
c++_shared	LLVM with dynamic linking libc++

Table II: NDK Runtime

If multiple so files are used in the APK, it is recommended to use the STL in a dynamic way to reduce the overall size of the APK file.
It is also important to note that the official NDK runtime supports RTTI and exceptions in addition to the default, but is disabled by default and is explained in the following android.mk how to turn on.

4. App_optim (compilation mode)

The "release" mode is the default, the generated is the optimized binary, or can be set to "Debug" mode, "Debug" mode generated is not optimized binary, provides a lot of bug information, easy to debug and analysis.
There are other configuration options that are interesting to view APPLICATION.MK official documentation.

Second, android.mk

       ANDROID.MK is also a lightweight makefile that organizes the C/+ + source into a module, which can be a static library, a shared library, or a standalone executable file. A android.mk file can have one, or it can be a dependency between multiple module,modules.

      1, Basic concepts

       ANDROID.MK includes macros, variables, and module description variables provided by the NDK, these macros, Variables and the assignment of variables together make up the Android.mk file, which is responsible for the NDK compilation and Guides the NDK's compilation.
      macros: Includes My-dir, all-subdir-makefiles, etc., called by ' $ (call <function>) ' to return text information.
      variables: include Clear_vars, build_shared_library, Target_arch, etc., provided by the NDK compilation system and exist before the Android.mk file is parsed. The android.mk file can be parsed several times, so the values of these variables may be different at each parse.
      Module description variables: module-description, including Local_ prefix variables such as Local_path, Local_module, Local_src_files, These variables are filled in between statements include $ (clear_vars) and include $ (build_xxx), except Local_path.
Other ANDROID.MK configurations can view ANDROID.MK official documentation.

      2, basic

      include some very basic variables in android.mk, the chestnuts below include the underlying variables, which I will explain in detail.

Local_path: = $ (call My-dir)
Include $ (clear_vars)
Local_module: = Hello-jni
Local_src_files: = Hello-jni.c
Include $ (build_shared_library)

Local_path (current directory)
Local_path describes a variable for a module, a android.mk must define Local_path, which is used to locate the source file, in this case the compiled system-supplied macro "My-dir" ("My-dir" returns the most recently included makefile file path, Usually the current android.mk directory), which is used to return the current directory.
This variable is not cleared by Clear_vars, so each android.mk file needs to be defined only once.

Clear_vars (variable purge)
The Clear_vars variable is provided by the compilation system, as the name implies, to clear the module variable (local_xxx module variable in the include $ (clear_vars) and include $ (build_xxx), except Local_path, of course. Since all compilation control files are parsed in a single GNU make executable context, and all variables in this context are global, the corresponding variables need to be cleaned up before compiling the module.

Local_module (MODULE name)
Local_module is the unique identifier of the module in the Android.mk file, which must be unique and cannot have spaces in the middle. By default, it determines the generated file name, such as "Hello-jni" corresponding to the dynamic library name is libhello-jni.so, however to index it, you need to "Hello-jni", you can also pass the variable Local_module_ FileName to override this default name.

Local_src_files (source file)
The local_src_files variable includes a list of C + + source files that are compiled into a module, but do not have to list header files and include files, and the compilation system will automatically find all the dependencies you need. It is worth noting that the Linux down path uses a slash (/).

Build_shared_library (Dynamic Library compilation)
Build_shared_library is a compiler-supplied variable that is compiled into a dynamic library that points to a GNU makefile script that collects all the information defined in all LOCAL_XXX variables from the include $ (clear_vars). Decide what to compile and how to compile it.
There are also build_static_library, similar to Build_shared_library, that are compiled into static libraries, and that static libraries are not copied to the APK.

Prebuilt_shared_library (precompiled)
Points to a compilation script that specifies a precompiled dynamic library. When using this variable, unlike Build_shared_library and Build_static_library, local_src_ Files must have a value that only has a path to the precompiled dynamic library, such as foo/libfoo.so, rather than the source file. Chestnuts below.

Include $ (clear_vars)
Local_module: = Test
Local_src_files: = lib/$ (Target_arch_abi)/libtest.so
Include $ (prebuilt_shared_library)

Prebuild_static_library, like Prebuild_shared_library, is simply a reference to a static library.

Target_arch_abi (target ABI name)
The target ABI name, as shown in table one. If more than one ABI is defined, each time the android.mk is parsed, the values are different, and the main use scenario is to define separate files for the underlying different ABI.

3. Other module variable local_ldlibs (link library)

For additional link options, all libraries have a "-l" prefix. Multiple libraries can be listed at the same time, separated by spaces, for example:

Local_ldlibs: =-LLOG-LDL

The Android NDK is linked by default to multiple libraries and does not need to be displayed to add to Local_ldlibs, including the standard C libraries,the standard C + + Libraries,real-time extensions and Pthread Library. There are also a number of libraries that need to be shown to be added, which are related to the library versions, as shown in table Iii.

Android level	Lib	Explanation
Android-3	-llog	Android Log
	-lz	Zlib Compression Library
	-ldl	Dynamic Linker Library
Android-4	-lglesv1_cm	OpenGL ES 1.x Library
Android-5	-lglesv2	OpenGL ES 2.0 Library
Android-8	-ljnigraphics	The Jnigraphics Library
Android-9	-legl	The EGL Graphics library
	-lopensles	Open ES Native Audio Library
	-landroid	Natice Android API
Android-14	-lopenmaxal	OpenMAX AL Natice Multimedia Library
Android-18	-lglesv3	OpenGL ES 3.0 Library
Android-21	-lglesv3	OpenGL ES 3.1 Library

Table Three: Link libraries

Local_cflags, Local_cppflags, and local_ldflags (compile, link flag)

Local_cflags defines a collection of flags that are passed to the compiler when compiling C + +, Local_cppflags only supports C + +, and the role is passed to the compiler for some information, local_ldflags refers to some additional parameters passed to the connector.

These flags will inevitably be used in NDK development, especially when optimizing compilation, and the following are the compilation options that I have encountered in development.

①local_cppflags + =-fexceptions
Because the NDK compiler supports C + + exception control starting from R5, exception handling is disabled by default (-fno-exceptions) for versatility, so you need to add local_cppflags + = in the specified module: Fexceptions compile options to compile C + + code with exception handling. You can also configure App_cppflags + =-fexceptions directly in the application.mk.

②local_cppflags + =-frtti
Starting with the NDK R5, the NDK is also starting to support C + + Rtti, but for versatility, all C + + source files are built by default not supported by Rtti (-fno-rtti), which can be added by android.mk: local_cppflags + =- Frtti or application.mk add app_cppflags + =-frtti to turn on Rtti.

③local_cflags + =-fvisibility=hidden
In the NDK development, the function of the source file has a default visibility property is public, compiled generated so file almost all function names, global variable names are exported, in fact, only need to export the java_com at the beginning of the JNI function, the other functions do not need to be exposed, Set Local_cflags + =-fvisibility=hidden in android.mk to hide functions that do not need to be exported, or add Jniexport or __attribute__ if a function needs to be exported ( Visibility ("Default")).
In addition to being safe, you can reduce the so volume by not exporting unnecessary functions.

④local_cflags + =-ffunction-sections
When you do not add this parameter, the file is compiled. o in the Code section, only the. Text segment, using this parameter, causes each function to have a separate segment, a chestnut, and the function func1 () is compiled into a. TEXT.FUNC1 segment, although there are many segments, there is no effect on the size of the post-link code.

⑤local_cflags + =-fdata-sections
Ibid., each data has a separate segment.

⑥local_ldflags + =-wl--gc-sections
The-wl,<option> option is to tell the compiler that the following options <option> pass to the connector,-WL,--gc-sections means to remove unused segments when using the connector LD link. If you use Local_cflags + =-ffunction-sections-fdata-sections, the code and data are split into different segments, and if a function or data is not called by any function, the LD does not link the function that is not called, thereby reducing the so file volume To achieve the purpose of optimizing so.

⑦local_ldflags + =-fpic
The PIC (position independent code) is used to compile location-independent codes and to generate a separate location code that can be used for shared libraries. If you do not add-fpic, the code snippet for the. So file is loaded, and the data object referenced by the code snippet needs to be relocated, and relocation modifies the contents of the snippet, which results in a copy of this file being generated in the kernel by the process of the code snippet.

⑧local_ldflags + =-wall
This means that wring all means that all warning messages are displayed during compilation and linking.

⑨ Other
You can view the GCC Command Options document If you need to know about other compilation flags.

Android NDK compilation option settings [Zhuan]