ANDROID.MK file Syntax explanation

0. android.mk Introduction:
The Android.mk file is used to inform the NDK Build system about source information. ANDROID.MK will be part of the GNU makefile and will be parsed one or more times by the build system. So, make as few declarations as possible in android.mk, and don't assume that anything will not be defined in the parsing process.

The android.mk file syntax allows us to package source as a "modules". Modules can be:
Static Library
Dynamic Libraries.

only dynamic libraries can be install/copy to the application package (APK). The static library can be chained to the dynamic library.
you can define one or more modules in one android.mk. You can also add the same source to multiple modules.

the Build system helps us deal with a lot of details without needing to be cared for. For example: You do not need to list the files and external dependent files in the android.mk. The NDK Build system automatically provides this information for us. This also means that when the user upgrades the NDK, you will be able to benefit from the new toolchain/platform without having to modify the android.mk.


1. ANDROID.MK Syntax:
first look at one of the simplest examples of android.mk:

Local_path: = $ (call My-dir)   include $ (clear_vars)   local_module: = Hello-jni local_src_files: = Hello-jni.c   include $ (build_shared_library)

The explanations are as follows:
Local_path: = $ (call My-dir)
each android.mk file must start with a definition of local_path . It is used to find source files in the development tree.
macro My-dir is provided by the build system. Returns the directory path that contains the ANDROID.MK.

include $ (clear_vars)
The Clear_vars variable is provided by the build system. and points to a specified GNU Makefile, which is responsible for cleaning up many local_xxx.
For example: Local_module, Local_src_files, local_static_libraries and so on. But do not clean local_path. This cleanup action is necessary because all compiled control files are parsed and executed by the same GNU make, and their variables are global. So we can avoid the mutual influence after cleaning.


Local_module: = Hello-jni
The local_module module must be defined to represent each module in the ANDROID.MK. Names must be unique and contain no spaces. The Build system automatically adds the appropriate prefixes and suffixes. For example, Foo, to produce a dynamic library, generates libfoo.so.
note, however, that if the module name is set to: Libfoo. Generates libfoo.so. No prefix is added.

local_src_files: = Hello-jni.c
The Local_src_files variable must contain a/C + + source code that will be packaged as a module. Instead of listing header files, the build System automatically helps us identify dependent files.
The default C + + source extension is. cpp. can also be modified by local_cpp_extension.


include $ (build_shared_library)
build_shared_library: is a variable provided by the BUILD system that points to a GNU Makefile Script. It is responsible for collecting all local_xxx information since the last call to include $ (clear_vars) . and decide what to compile.

   build_static_library   : Compiles to a static library.  
   build_shared_library    : Compiled to Dynamic library  
   build_ Executable  : compiled to native C executable  
 
 
 
 

2. NDK Build System Variables:
The NDK Build System retains the following variable names:
To start with Local_.
A name that begins with Private_, Ndk_, or App_.
Lowercase letter name: such as My-dir

If you want to define a variable name that you use in android.mk, we recommend that you add a my_ prefix.

Variables provided by 2.1:NDK:
Such GNU make variables are defined by the NDK Build system before parsing android.mk.

2.1.1:clear_vars: Point to a compilation script. Must be included in front of the new module.

Include $ (clear_vars)

2.1.2:build_shared_library: Points to a compilation script that collects all local_xxx information since the last call to include $ (clear_vars)   . and decide how to compile the source you listed into a dynamic library.
Note that before including this file, it should contain at least: Local_module and Local_src_files

For example:

Include $ (build_shared_library)

2.1.3: build_static_library: Similar to the previous one, it also points to a compilation script that collects all Local_ since the last call to include $ (clear_vars) XXX information. and decide how to compile the source you listed into a static library.
Static libraries cannot be added to project or APK. But it can be used to generate dynamic libraries.

Local_static_libraries and Local_whole_static_libraries will describe it.

Include $ (build_static_library)

2.1.4:build_executable: Similar to the previous one, it also points to a compilation script that collects all local_xxx information since the last call to include $ (clear_vars)   . and decide how to compile the source you listed into an executable native program.

Include $ (build_executable)

2.1.5: prebuilt_shared_library: Declare this shared library as "a" standalone module.

point to a build script that specifies a pre-compilation of many dynamic libraries.
Unlike Build_shared_library and Build_static_library, the module's local_src_files should be designated as a pre-compiled dynamic library instead of the source file.
Local_path: = $ (call My-dir)
    
include $ (clear_vars)
Local_module: = foo-prebuilt # module Name
local_src_files: = libfoo.so # module's file path (relative to Local_path)
    
include $ (prebuilt_shared_library) # Note This is not build_shared_library .

This shared library will be copied to the $PROJECT/obj/local and $PROJECT/libs/(stripped)
It is primarily used in this Android project to use a third-party library that has already been compiled. Why not copy it directly to the Libs/armabi directory? Because it's a lot of flaws. The next section explains in more detail.




2.1.6: prebuilt_static_library: pre-compiled static library.
Ibid.


2.1.7: target_arch:
The Target CPU schema name. If "arm" is claimed arm-compatible instructions. Independent of the CPU schema version.


2.1.8: target_platform:
the name of the target platform.


2.1.9:target_arch_abi

Name of the target Cpu+abi

Armeabi for ARMv5TE
armeabi-v7a

2.1.10: Target_abi



2.2:NDK provides a feature macro:
GNU make provides a feature macro that is only passed by a similar: $ (call function)
The way to get its value, it returns textual information.

2.2.1: My-dir:
$ (call My-dir): Returns the path to the makefile of the most recent include. Typically returns the path where the android.mk is located. It is used as the beginning of android.mk to define Local_path.

Local_path: = $ (call My-dir)

Note: The path to the makefile of the most recent include is returned. Therefore, after the include other makefile, the call My-dir will return the path where the other android.mk are located.

For example:

Local_path: = $ (call My-dir)
... declare one module
Include $ (local_path)/foo/android.mk
Local_path: = $ (call My-dir)
... declare another module

The second return Local_path is: $PATH/foo. Rather than $path.

2.2.2: all-subdir-makefiles:
Returns a list that contains android.mk from all subdirectories in ' My-dir '.

For example:
The structure is as follows:

Sources/foo/android.mk
Sources/foo/lib1/android.mk
Sources/foo/lib2/android.mk

In the If sources/foo/android.mk,
Include $ (call All-subdir-makefiles)

That automatically include the Sources/foo/lib1/android.mk and Sources/foo/lib2/android.mk.



2.2.3: this-makefile:
The path of the current makefile.


2.2.4: parent-makefile:
Returns the parent makefile path in the include tree. This is the makefile Path that include the current makefile.


2.2.5: import-module:
Allow to find and inport other modules into this android.mk.
It will look for the specified module name from Ndk_module_path.

$ (call Import-module,)

2.3: module Description Variable:
This class of variables is used to describe the module information to the build system. Between ' include $ (clear_vars) ' and ' include $ (build_xxxxx) '. This class of variables must be defined.

The include $ (clear_vars) script is used to empty these variables.

Include $ (build_xxxxx) to collect and use these variables.


2.3.1: Local_path:
This value is used for the given current directory. Must be defined in the position of the android.mk.
For example:

Local_path: = $ (call My-dir)

Local_path will not be cleaned by the include $ (clear_vars).


2.3.2: local_module:
Modules name. You must define this variable before include $ (build_xxxxx). This variable must be unique and cannot have spaces.

Typically, this variable name determines the target file name that is ultimately generated.


2.3.3: local_module_filename:
Optional. Used to override Local_module. That allows the user to redefine the final generated target file name.

Local_module: = foo-version-1
Local_module_filename: = Libfoo

2.3.4: local_src_files:
A list of source files provided for build modules. You do not need to list dependent files.
Note: The file is stored relative to Local_path and can provide a relative path.
For example:

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

2.3.5: local_cpp_extension:
Indicates the C + + extension. (optional)

Local_cpp_extension: =. cxx
After R7 from NDK, you can write multiple:

Local_cpp_extension: =. cxx. CPP. cc


2.3.6: local_cpp_features:
Optional. Used to specify C + + features.

Local_cpp_features: = Rtti

Local_cpp_features: = Exceptions

2.3.7: local_c_includes:
An optional path list. Relative to the NDK root directory. At compile time, these directories will be attached.

Local_c_includes: = Sources/foo
Local_c_includes: = $ (Local_path)/. /foo

2.3.8: local_cflags:
An optional setting to add, such as flags, when compiling C + + source. Used to attach compilation options.
Note: Do not attempt to modify the compilation tuning options and the debug level here. It is automatically specified by the information in your application.mk.

You can also specify the Include directory by: Local_cflags + =-I. This method is better than using local_c_includes . Because this can also be used by Ndk-debug.


2.3.9: local_cxxflags:

The alias of the local_cppflags .

 2.3.10:  local_cppflags:
c Flags added to C + + Source compilation. These flags will appear at the back of the local_cflags flags . 


 2.3.11:  local_static_libraries:
to link to the static library list for this module. (built with Build_static_library)


 2.3.12:  local_shared_libraries:
The dynamic Library to link to this module. 


 2.3.13:local_whole_static_libraries:
Static library full link. Unlike Local_static_libraries, similar to the use of--whole-archive


 2.3.14:local_ldlibs:
linker flags. You can use it to add a system library. such as-lz:

Local_ldlibs: =-lz


2.3.15: local_allow_undefined_symbols:


2.3.16: Local_arm_mode:
In the default mode, the arm target code is compiled into thumb mode. 16 bits per instruction. If this variable is specified as: arm. The instruction is 32 bits.

Local_arm_mode: = ARM

In fact, you can specify an arm instruction pattern for one or several files.

2.3.17: Local_arm_neon:
When set to true, the floating point is compiled into a neon instruction. This can greatly speed up floating-point operations (provided that the hardware supports them)
Only targeting is ' armeabi-v7a '.


2.3.18: Local_disable_no_execute:


2.3.19: local_export_cflags:
Define this variable to record a collection of C + + compiler flags and be added to any other local_cflags definitions of modules in Local_static_libraries and local_shared_libraries

Local_src_files: = foo.c bar.c.arm

Attached 1:android.mk to the JNI directory:

In a directory, such as/src/modules1/under ANDROID.MK and application.mk, call Ndk-build attempt to compile, you will encounter the following error:

Android ndk:could not find application project directory!

Android ndk:please define the Ndk_project_path variable to the it.

/opt/android-ndk-r9d/build/core/build-local.mk:148: * * * Android ndk:aborting. Stop.

This is because the current android.mk is not placed within the JNI directory. So Ndk-build can't find android.mk. (Ndk-build will find the JNI directory up from this directory and android.mk from the JNI directory) and ndk_project_ PATH, App_build_script, NDK_APPLICATION_MK is an empty value.

How to solve this problem. First of all, of course, create the JNI directory and add android.mk and application.mk to it.

But on the other hand, it is also possible to explicitly indicate these three values:

The directory structure is as follows:

/src/modules1/android.mk

Under this directory:

/opt/android-ndk-r9d/ndk-build-b v=1 ndk_project_path=. App_build_script=./android.mk ndk_application_mk=./application.mk

can also be compiled normally.


Note: The NDK version here is NDK r7c. (Different NDK versions, the makefile generated by Ndk-build are not identical)

ANDROID.MK file Syntax explanation