Android. mk syntax

Source: Internet
Author: User


Android. mk is used to describe your C and C ++ source code files to androidndk. This document describes its syntax. Before reading the following content, let's assume that you have read the docs/Overview. txt file and understood their roles and purposes.

I. Overview

An android. mkfile is used to describe your source code to the compilation system. Specifically:

(1) This file is a small part of gnumakefile and will be parsed by the compilation system once or more times.

Therefore, you should minimize your declared variables and do not consider that some variables will not be defined during the parsing process.

(2) the syntax of this file allows you to organize your source code into modules. A module belongs to one of the following types:

1) static library 2) shared library, and only the shared library will be installed/copied to your application software package, although the static library can be used to generate a shared library.

You can define one or more modules in each android. mkfile. You can also use the same source code file in several modules.

(1) The compilation system handles many details for you. For example, you do not need to list header files and dependent files in your android. mk file. The ndk compilation system automatically handles these problems for you. This also means that after you upgrade the ndk, you should get the new toolchain/platform support and do not need to change your android. mk file.

Note: This syntax is very similar to the open source code of the publicly released Android platform. However, the method for implementing the compilation system is different. This is designed on purpose, it makes it easier for program developers to reuse the source code of external libraries.

Before describing the syntax details, let's look at a simple "hellojni" example, for example, the following file:

JNI/hellojni. c

JNI/Android. mk

'Hellojni. c' is a JNI shared library that provides native methods to return the "hellojni" string. The corresponding Android. mk file will look like the following:

Local_path: = $ (call my-DIR)

Include $ (clear_vars)

Local_module: = hellojni
Local_src_files: = hellojni. c

Include $ (build_shared_library)


Okay. Let's explain these lines of code:

Local_path: = $ (call my-DIR)

An android. mkfile must first define the local_path variable. It is used to search for source files in the Development tree. In this example, the macro function 'my-dir' is provided by the compilation system and used to return the current path (that is, the directory containing the Android. mk file ).

Include $ (clear_vars)

Clear_vars is provided by the compilation system, specifying that gnumakefile clears many local_xxx variables for you (such as local_module, local_src_files, local_static_libraries, and so on...), except local_path. This is necessary because all the compilation control files are in the same GNU make execution environment, and all the variables are global.

Local_module: = hellojni

The local_module variable must be defined to identify each module you describe in the Android. mk file. The name must be unique and contain no spaces. Note that the compilation system automatically generates the appropriate prefix and suffix. In other words, a shared library module named 'hellojni' will generate the 'libhellojni. so' file.

Important: If you name the library 'libthelljni ', the compiling system will not add any lib prefix or generate libhellojni. so, this is to support Android from the source code of the Android platform. MK file, if you do need to do so.


Local_src_files: = hellojni. c

The local_src_files variable must contain the C or C ++ source code files to be compiled and packaged into the module. Note that you do not need to list header files and contained files here, because the compilation system will automatically find the dependent files for you; just list the source code files directly transmitted to the compiler. [Note: The default C ++ source code 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 the starting dot (that is, defined '. cxx', rather than 'cxx') (of course we will not change this step )]

Include $ (build_shared_library)

Build_shared_library is a variable provided by the compilation system. It points to a GNU makefile script (which should be In the build/Core directory) and is responsible for collecting information from the previous call to 'include $ (clear_vars, define all the information in the local_xxx variable and decide what to compile and how to perform it correctly. And generate a static library based on its rules. Similarly, for static databases.

There are more complex examples in the sources/Samples Directory. You can see the Android. mk file with annotations.

Ii. References

This is a list of variables that you should depend on or define in Android. mk. You can define other variables for your own use, but the ndk compilation system retains the following variable names:

-Name starting with local _ (for example, local_module)

-Name starting with private _, ndk _ orapp _ (used internally)

-Lowercase name (for internal use, for example, 'My-dir ')

If you want to define your own variables in Android. mk for convenience, we recommend that you use the my _ prefix. A small example:

My_sources: = Foo. c

Ifneq ($ (my_config_bar ),)

My_sources + = bar. c



Local_src_files + = $ (my_sources)

1. GNU make variable

These GNU make variables are defined by the compilation system before parsing your android. mk file. Note that in some cases, ndk may analyze Android. mk several times, and the definitions of some variables may vary.

(1) clear_vars: points to a compilation script. Almost all undefined local_xxx variables are listed in "module-description. You must include this script before starting a new module. Include $ (clear_vars)

(2) build_shared_library: points to the compiling script, collects all the information you provide in the local_xxx variable, and decides how to compile the source code file you listed into a shared library. Note that you must define local_module and local_src_files at least before including the file. Example:

Include $ (build_shared_library) (note that this will generate a file named Lib $ (local_module). So)

(3) build_static_library: A build_shared_library variable is used to compile a static library. Static libraries will not be copied to your project/packages, but can be used to compile shared libraries (see the local_static_libraries and local_static_whole_libraries described below)

Example: include $ (build_static_library) (note that this will generate a file named Lib $ (local_module). ).

(4) target_arch: name of the target CPU platform, as specified in the android open source code. If it is arm, it indicates that the command compatible with arm is to be generated, which is irrelevant to the CPU architecture revision.

(5) target_platform: Android. mk parsing, the name of the target Android platform. For details, see/development/ndk/docs/stable-apis.txt.

Android-3-> official Android 1.5 systemimages

Android-4-> official Android 1.6 systemimages

Android-5-> official Android 2.0 systemimages


(6) target_arch_abi: currently only two values are supported, armeabi and armeabi-v7a. In the current version, these two values are generally simply defined as arm, which can be better matched through redefinition within the Android platform. Other Abi files will be described in later ndk versions. They will have different names. Note that all ARM-based Abi will define 'target _ arch 'As 'arm', but there will be different 'target _ arch_abi'

(7) target_abi: A combination of the Target Platform and Abi, which is actually defined as $ (target_platform)-$ (target_arch_abi) it is useful when you want to test a particular target system on a real device. By default, it will be 'android-3-arm '.

2. Module description Variables

The following variables are used to describe your module to the compilation system. You should define it between 'include $ (clear_vars) 'and 'include $ (build_xxxxx. As described above, $ (clear_vars is a script that clears all these variables unless explicitly stated in the description.

(1) local_path: Specifies the path of the current file. You must define it at the beginning of Android. mk, which can be used as follows:

Local_path: = $ (call my-DIR)

This variable will not be cleared by $ (clear_vars), so each android. mk only needs to be defined once (even if several modules are defined in a file ).

(2) local_module: This is the name of your module. It must be unique and cannot contain spaces. You must define it before it contains any $ (build_xxxx) script. The module name determines the name of the generated file. For example, if the name of a shared library module is, the name of the generated file is Lib. So. However, in your ndk generated file (or android. mk or application. mk), you should only involve (reference) other modules with normal names.

(3) local_src_files: list of source code files to be compiled. You only need to list the files to be passed to the compiler, because the compilation system automatically calculates dependencies for you. Note that the source code file names are relative to local_path. You can use the path section, for example:

Local_src_files: = Foo. c

Toto/bar. c

Note: Unix-style slashes (/) must be used in the generated files. The windows-style backslash will not be correctly processed.


(4) local_cpp_extension: This is an optional variable used to specify the extension of the C ++ code file. The default value is '. cpp', but you can change it, for example:

Local_cpp_extension: =. cxx

(5) local_c_includes: Optional path configuration, starting from the root directory,

All sources (C, C ++ and assembly). Forexample:

Local_c_includes: = sources/foo

Or even:

Local_c_includes: = $ (local_path)/../foo

It must be before any flag containing local_cflags/local_cppflags.

(6) local_cflags: Optional compiler options, used when compiling C code files. This may be useful, specifying an additional include path (relative to the top-level directory of the ndk), macro definition, or compilation options.

Important information: do not go to Android. in MK, you only need to change the optimization/debugging level in application. if you specify the appropriate information in MK, the problem will be automatically handled for you. During debugging, The ndk will automatically generate useful data files.

(7) local_cxxflags: Same aslocal_cflags for C ++ source files

(8) local_cppflags: Same as local_cflags, but applicable to both C and C ++ sourcefiles.

(9) local_static_libraries: it should be linked to the static library list of this module (generated using build_static_library), which is only meaningful to the shared library module.

(10) local_shared_libraries. Note: This will not append the listed modules to the compilation graph, that is, you still need to add them to the modules required by the program in application. mk.

(11) local_ldlibs: Additional Linker Options to be used to compile your module. This is useful for passing the name of the specified database using the "-l" prefix. For example, the following will tell the module generated by the linker to link to/system/lib/libz. So at the time of loading.


Local_ldlibs: =-LZ

Look at the docs/STABLE-APIS.TXT to get a list of open system libraries that you can link to using the ndk release.

(13) local_allow_undefined_symbols: by default, when attempting to compile a shared library, any undefined reference will cause an "undefined symbol" error. This will be of great help for capturing errors in your source code files. However, if you do not need to start this check for some reason, set this variable to 'true '. Note that the corresponding shared library may fail to be loaded at runtime. (Do not set this parameter to true)

(14) local_arm_mode: by default, the arm target binary is generated in the form of thumb (16 bits ), you can set this variable to arm if you want your module to be in the form of a 32-bit command.

'Arm '(32-bit instructions) mode. E. g .:

(15) local_arm_mode: = arm note that you can also tell the system to compile a specific type during compilation, such

(16) local_src_files: = Foo. cbar. c. in this way, arm tells the system that bar is always used. C is compiled in arm mode. The following is the GNU make 'function' macro, which must be evaluated by using '$ (CALL)'. They return regionalized information.

(17) My-Dir: return the directory path of the current Android. mk, relative to the top layer of the ndk compilation system. This is useful. It is defined at the beginning of the android. mk file:

Local_path: = $ (call my-DIR)

(18) All-subdir-makefiles: returns a list of subdirectories in the current 'my-dir' path. For example, you can view the following directory levels:

Sources/Foo/Android. mk

Sources/Foo/lib1/Android. mk

Sources/Foo/lib2/Android. mk

If sources/Foo/Android. mk contains one line:

Include $ (call all-subdir-makefiles)


Then it automatically contains sources/Foo/lib1/Android. mk and sources/Foo/lib2/Android. mk. This function provides the compilation system with a deep nested code directory hierarchy. Note that by default, ndk will only search for files in sources/*/Android. mk.

(19) This-makefile: returns the path of the current makefile (where this function is called)

(20) parent-makefile: return the path of the parent makefile in the call tree. That is, the makefile path that contains the current makefile.

(21) Grand-parent-makefile guess...

3. Use templates for Android. mk

Multiple executable programs, dynamic libraries, and static libraries can be generated in an android. mk file.

(1) Compile the Application Template:

# Test exe

Local_path: = $ (call my-DIR)

# Include $ (clear_vars)

Local_src_files: = Main. c

Local_module: = test_exe

# Local_c_includes: =

# Local_static_libraries: =

# Local_shared_libraries: =

Include $ (build_executable)

(Cainiao-level explanation: = is the meaning of the value assignment, $ is to reference the value of a variable.) Add the source file path to local_src_files and add the header file path to local_c_pair des, local_static_libraries is added to the static library to be linked (*. a) Name. Add the dynamic library (*. so) name. local_module indicates the final name of the module, and build_executable indicates compiling in an executable program.

(2) Compile static library templates:

# Test static lib

Local_path: = $ (call my-DIR)

Include $ (clear_vars)

Local_src_files: =

Helloworld. c

Local_module: = libtest_static

# Local_c_includes: =

# Local_static_libraries: =

# Local_shared_libraries: =

Include $ (build_static_library)

In general, it is similar to the above. build_static_library indicates compiling a static library.

(3) Compile the dynamic library template:

# Test shared lib

Local_path: = $ (call my-DIR)

Include $ (clear_vars)

Local_src_files: = helloworld. c

Local_module: = libtest_shared

Target_prelink_modules: = false

# Local_c_includes: =

# Local_static_libraries: =

# Local_shared_libraries: =

Include $ (build_shared_library)

In general, it is similar to the above. build_shared_library indicates compiling a shared library.

The above three generation results are as follows, and the generic changes according to the specific target:




The target folders of each module are:

Executable program: xxx_intermediates

Static Library: xxx_static_intermediates

Dynamic library: xxx_shared_intermediates

In addition, in the Android. mk file, you can specify the final target installation path, which is specified using local_module_path and local_unstripped_path. Use the following macro to select different file system paths:

Target_root_out: indicates the root file system.

Target_out: indicates the system file system.

Target_out_data: indicates the data file system.

Usage example:

Local_module_path: = $ (target_root_out)


Related Article

Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.