ANDROID.MK File Details

The Android.mk file is a small part of the GNU makefile that is used to compile the Android program. Because all the compiled files are executed in the same GNU make execution environment,all the variables in the android.mk are globalOf Therefore, you should declare as few variables as possible, and do not assume that certain variables are not defined during parsing.a android.mk file can compile multiple modules, each of which belongs to one of the following types:  1) APK program   General Android program, compile package build apk file   2) Java library   Java class Library, compile package build jar file   3) c\c++ application   executable c\ C + + Applications   4) c\c++ Static library   Compile build c\c++ static library and package as. A file   5) c\c++ Shared library compilation generates shared libraries (dynamic link libraries) and is packaged as. So, and only shared libraries can be installed/ Copy to your application (APK) package.    you can define one or more modules in each android.mk file, and you can use the same source code file in several modules. The   compilation system handles a number of details for you. For example, you do not need to include your android.mk in your files and dependent files. The compilation system will automatically handle these issues for you. This also means that after upgrading the NDK, you should get new Toolchain/platform support and do not need to change your android.mk file.    Note that The ANROID.MK syntax of the NDK is close to the ANROID.MK syntax of the open source code for Android platforms, but the way the compiler implements them is different, deliberately designed to make it easier for program developers to reuse the source code of external libraries.    before we describe the syntax details, let's look at a simple example of "Hello World", for example, the following file:  sources/helloworld/helloworld.c sources/ helloworld/android.mk  ' HELLOWORLD.C ' is a JNI shared library that implements the native method of returning the "Hello World" string. The corresponding android.mk file will look like this: 

Local_path: = $ (call my-dir) include $ (clear_vars) Local_module:= helloworldlocal_src_files:=  Helloworld.cinclude $ (build_shared_library)

One, explain a few lines of code: Local_path: = $ (call My-dir)A android.mk file must first define a good local_path variable. It represents the path to the current file. In this example, the macro function ' My-dir ', provided by the compilation system, is used to return the current path (that is, the directory containing the android.mk file). include $ (clear_vars)Clear_vars is provided by the build system (can see its definition in the Android installation directory/build/core/config.mk file for clear_vars:=$ (Build_system)/clear_vars.mk), Specifies that the GNU makefile this script clears many local_xxx variables for you (such as Local_module, Local_src_files, Local_static_libraries, and so on ...), except for Local_path. This is also necessary because all the compiled files are in the same GNU make execution environment, and all the variables are global. So we need to empty these variables first (except Local_path). And because Local_path always requires that it be set in every module, it doesn't need to be emptied.Note:The meaning of this statement is to include the script file that the Clear_vars variable points to. local_module: = HelloWorldThe local_module variable must be defined to identify each module that you describe in the Android.mk file. The name must be unique and does not contain any spaces. Note that the compilation system will automatically generate the appropriate prefix and suffix, in other words, a shared library module named ' foo ' will generate ' libfoo.so ' files.Note:If the library is named ' Libhelloworld ', the compiled system will not add any LIB prefixes and will generate libhelloworld.so. local_src_files: = HELLOWORLD.CThe local_src_files variable must contain a C or C + + source code file that will be compiled into a module. Instead of listing headers and include files here, the compiled system will automatically find the dependent files, and of course for the included files, you should specify the correct path when you include them.Note:The default C + + source file extension is '. cpp '. It is also possible to specify a different extension, as long as you define the local_default_cpp_extension variable, do not forget to start the small dot (that is, defined as '. Cxx ', not ' cxx ') include $ (build_shared_library)Build_shared_library is a compiler-supplied variable that points to a GNU Makefile script (which should be the SHARED_LIBRARY.MK in the Build/core directory) and will be based on the values in the LOCAL_XXX series variable toCompile build Shared library (dynamic link library)。 If you want to generate a static library, use Build_static_library, a more complex example under the NDK's Sources/samples directory, with annotated android.mk files. ii.. Custom VariablesThe following is a list of variables that are dependent or defined in android.mk, and you can define other variables for your own use, but the NDK compilation system retains the following variable names:--Names beginning with Local_ (for example, Local_module)--Starting with Private_, Ndk_, or App_ Name (internal use)--lowercase name (internal use, e.g. ' my-dir ') if you want to define your own variables in android.mk, it is recommended to use the My_ prefix, a small example:

My_sources: =+= + + $ (my_sources)

Note: ': = ' is the meaning of the assignment; ' + = ' is the appended meaning; ' $ ' indicates a value that refers to a variable.

third, GNU make system variablesThese GNU make variables are defined by the compilation system before your Android.mk file is parsed. Note In some cases, the NDK may analyze android.mk several times, and each time certain variables are defined differently. (1) Clear_vars:Point to a compilation script, and almost any undefined local_xxx variable is listed in the "Module-description" section.This script must be included before starting a new module: include$ (Clear_vars), which resets all LOCAL_XXX series variables except the Local_path variable. (2) Build_shared_library:Point to the compilation script to compile the listed source code files into a shared library based on all the local_xxx variables. Note that Local_module and local_src_files must be defined at least before the file is included. (3) Build_static_library:A build_shared_library variable is used to compile a static library. Static libraries are not copied to the APK package, but can be used to compile shared libraries. Example: Include $ (build_static_library) Note that this will generate a file named lib$ (Local_module). A (4) Target_arch:The name of the target CPU platform, as specified in Android open source. If it is arm, it indicates that an arm-compatible instruction is to be generated, regardless of the revision of the CPU schema. (5) Target_platform:ANDROID.MK the name of the target Android platform when parsing. For details, refer to/development/ndk/docs/stable-apis.txt. Android-3-Official Android 1.5 system images android-4 official Android 1.6 system images android-5-Offi cial Android 2.0 System Images (6) Target_arch_abi:Only two Value,armeabi and armeabi-v7a are supported for the time being. In the current version, these two values are generally defined as arm, which is redefined internally by the Android platform to get a better match. The other ABI will be introduced in later versions of the NDK, and they will have different names. Note that although all arm-based ABI will define ' target_arch ' as ' arm ', there will be a different ' target_arch_abi '. (7) Target_abi:The combination of the target platform and the ABI, which is actually defined as $ (target_platform)-$ (Target_arch_abi), is useful when you want to test against a particular target system in a real device. In the default case, it will be ' android-3-arm '. Five, module description variableThe following variables are used to describe your module to the compilation system. You should define between ' include $ (clear_vars) ' and ' include $ ' (build_xxxxx) '. As previously described, $ (clear_vars) is a script that clears all these variables. (1) Local_path:This variable is used to give the path to the current file. Must be defined at the beginning of the ANDROID.MK, which can be used: local_path: = $ (call My-dir) This variable is not cleared by $ (clear_vars), so each android.mk needs to be defined only once ( Even if several modules are defined in a file). (2) Local_module:This is the name of the module, it must be unique, and cannot contain spaces. It must be defined before the $ (build_xxxx) script that contains the any. The name of the module determines the name of the generated file. For example, if the name of a shared library module is xxx, then the name of the generated file is libxxx.so. However, in the NDK makefile (or android.mk or application.mk), it should only involve other modules (referencing) with a normal name. (3) Local_src_files:This is the list of source code files to compile. Simply list the files to be passed to the compiler because the compilation system automatically calculates the dependencies. Note that the source code file names are relative to Local_path, and you can use the path section, for example:

Local_src_files: = foo.c toto/bar.c                   hello.c

The   file can be separated by a space or TAB key, using "\" for line wrapping. If you are appending the source code file, use Local_src_files + = Note: The Unix-style slash (/) is used in the build file. Windows-style backslashes are not handled correctly. Note: You can local_src_files: = $ (call all-subdir-java-files) in this form to include all Java files in the Local_path directory.   (4) Local_cpp_extension:   This is an optional variable that specifies the extension of the C + + code file, which is '. CPP ' by default, but can change it, such as: local_cpp_extension: =. cxx   (5) Local_c_includes:   Optional variable that represents the search path for the header file. The default header file search path is the Local_path directory.   Example: local_c_includes: = Sources/foo or Local_c_includes: = $ (local_path)/... /foo  Local_c_includes needs to be set before any of the Local_cflags/local_cppflags flags are included.   (6) Local_cflags:   Optional compiler option, used when compiling C code files. This may be useful to specify an additional include path (relative to the NDK's top-level directory), a macro definition, or a compilation option.   NOTE: Do not change the optimization/debugging level in android.mk, as long as you specify the appropriate information in the APPLICATION.MK, it will automatically handle this problem for you, during debugging, will let The NDK automatically generates useful data files.   (7) Local_cxxflags:   and Local_cflags, for C + + source files.   (8) Local_cppflags:   is the same as local_cflags, but it applies to both C and C + + source files.   (9) Local_static_libraries: Indicates which static libraries the module needs to use to link at compile time.   Local_shared_libraries:   Indicates that the module should be run in accordance with theThe shared library (dynamic library) that is required at the time of the link to embed its corresponding information when the file is generated. Note: It does not attach the listed modules to the compilation diagram, which means that they still need to be added to the module in the APPLICATION.MK for the program requirements.   (one) Local_ldlibs:   Additional linker options to use when compiling the module. This is useful for passing the name of the specified library using the '-l ' prefix. For example, local_ldlibs: =-lz indicates that the module generated by the linker is to be linked to/system/lib/libz.so  at load time to view Docs/stable-apis. TXT gets a list of open system libraries that can be linked to using the NDK release.   Local_allow_undefined_symbols:   By default, any undefined references will cause an "undefined symbol" error when attempting to compile a shared library. This can be a great help in capturing errors in the source code files. However, if for some reason you do not need to start this check, you can set this variable to ' true '. Note the corresponding shared library may fail to load at run time. (This generally tries not to set to true).   Local_arm_mode: By default, the arm target binary is generated as a thumb (16 bits), and you can set this variable to arm if you want your module to be in the form of a 32-bit instruction. ' Arm ' (32-bit instructions) mode. E.g.:local_arm_mode: = ARM Note: You can tell the system to compile a specific type of compilation for a source file for example, local_src_files: = foo.c bar.c.arm   This tells the system to always The BAR.C is compiled in arm mode. (14) Local_module_path and Local_unstripped_path in the Android.mk file, you can also use Local_module_path and Local_unstripped_ PATH Specifies the final target installation path. Different file system paths are selected with the following macro:  Target_root_out: Represents the root file system.    target_out: Represents the system filesystem.    target_out_data: Represents the DATA file system. Usage such as: LOCal_module_path: =$ (target_root_out)   As for the difference between Local_module_path and Local_unstripped_path, it is not clear for the time being. The GNU make ' function ' macro GNU do ' feature ' macros must be called by using ' $ (call  ) ' to invoke them to return textual information. (1) My-dir: Returns the path to the directory where the current android.mk resides, relative to the top level of the NDK compilation system. This is useful, as defined at the beginning of the Android.mk file: Local_path: = $ (call My-dir) (2) All-subdir-makefiles: Returns a location at the current ' My-dir ' A list of all android.mk in subdirectories of the path. For example, look at the following directory hierarchy:sources/foo/android.mksources/foo/lib1/android.mksources/foo/lib2/android.mk  if sources/foo/ ANDROID.MK contains one line: include $ (call all-subdir-makefiles) then it will automatically contain sources/foo/lib1/android.mk and sources/foo/lib2/ Android.mk. This feature is used to provide a deep nested code directory hierarchy to the compilation system. Note that by default, the NDK will only search for files in sources/*/android.mk. (3) This-makefile:   Returns the path to the current makefile (where this function is called) (4) Parent-makefile:   Returns the parent makefile path in the call tree. The makefile path that contains the current makefile. (5) Grand-parent-makefile: Returns the path to the parent makefile of the parent makefile in the call Tree Viii. android.mk using templates   in a android.mk can generate multiple apk applications, Java library, C \c++ executables, c\c++ dynamic libraries and c\c++ static libraries. (1) Compile APK application template. For a template to compile the APK application, refer to the ANDROID.MK compilation apk example (2) to compile the Java Library template   Local_path: = $ (Call my-DIR)   include $ (clear_vars)   # Build All Java files in the Java subdirectory  local_src_files: = $ -subdir-java-files)   # Any libraries the This library depends on  local_java_libraries: = android.test.runner& nbsp # The name of the jar file to create  local_module: = sample  # Build A static jar file.  include $ (build_s Tatic_java_library)   NOTE: local_java_libraries: = Android.test.runner indicates the jar file name of the generated JAVA library (3) the C + + application template is compiled as follows: Local_ PATH: = $ (call My-dir) #include $ (clear_vars) Local_src_files: = Main.clocal_module: = test_exe#local_c_includes: = #LOCAL _static_libraries: = #LOCAL_SHARED_LIBRARIES: =include $ (build_executable) Note: ': = ' is the meaning of assignment, ' + = ' is appended meaning, ' $ ' Represents the value that references a variable local_src_files the source file path, adding the required header file search path to the Local_c_includes local_static_libraries add the name of the static library (*.A) you want to link to, Local_ Shared_libraries adds the name of the dynamic library (*.so) you need to link to, Local_module represents the final name of the module, and build_executable the compilation as an executable program. (4) Compile c\c++ static library Local_path: = $ (call My-dir) include $ (clear_vars) Local_src_files: = \ helloworld.clocal_module:= libtest_static  #LOCAL_C_INCLUDES: = #LOCAL_STATIC_LIBRARIES: = #LOCAL_SHARED_ LIBRARIES: =include $ (build_static_library) similar to above, build_static_library means compiling a static library. (5) Compiling template for c\c++ dynamic library Local_path: = $ (call My-dir) include $ (clear_vars) Local_src_files: = Helloworld.clocal_module: = Libtest_sharedtarget_prelink_modules: = false#local_c_includes: = #LOCAL_STATIC_LIBRARIES: = #LOCAL_SHARED_LIBRARIES : =include $ (build_shared_library) similar to the above, build_shared_library means compiling a shared library. The results of the above three are in the following directory, generic depending on the target will change: Out/target/product/generic/obj/appsout/target/product/generic/obj/java_ librariesout/target/product/generic/obj/executableout/target/product/generic/obj/static_libraryout/target/ Product/generic/obj/shared_library the target folder for each module is: 1) apk program: XXX_INTERMEDIATES2) Java Library Program: Xxx_intermediates here XXX  3) c\c++ executable: xxx_intermediates 4) c\c++ Static Library: xxx_static_intermediates 5) c\c++ Dynamic Library: XXX_shared_ Intermediates

Android.mk file