android ndk Android.mk

Android.mk

On this page

1. Overview
2. Basics
3. Variables（变量） and Macros（指令集）
4. Module-Description Variables

This page describes the syntax(语法) of the Android.mk build file, which glues(黏合剂) your C and C++ source files to the Android NDK.

GNU Make系统变量

变量描述CLEAR_VARS指向一个编译脚本，几乎所有未定义的 LOCAL_XXX 变量都在"Module-description"节中列出。必须在开始一个新模块之前包含这个脚本：include$(CLEAR_VARS)，用于重置除LOCAL_PATH变量外的，所有LOCAL_XXX系列变量。BUILD_SHARED_LIBRARY指向编译脚本，根据所有的在 LOCAL_XXX 变量把列出的源代码文件编译成一个共享库。BUILD_STATIC_LIBRARY一个 BUILD_SHARED_LIBRARY 变量用于编译一个静态库。静态库不会复制到的APK包中，但是能够用于编译共享库。TARGET_ARCH目标 CPU平台的名字,  和 android 开放源码中指定的那样。如果是arm，表示要生成 ARM 兼容的指令，与 CPU架构的修订版无关。TARGET_PLATFORMAndroid.mk 解析的时候，目标 Android 平台的名字.详情可参考/development/ndk/docs/stable- apis.txt.TARGET_ARCH_ABI支持目标平台TARGET_ABI目标平台和 ABI 的组合，它事实上被定义成$(TARGET_PLATFORM)-$(TARGET_ARCH_ABI)  ，在想要在真实的设备中针对一个特别的目标系统进行测试时，会有用。在默认的情况下，它会是'android-3-arm'。  
模块描述变量

变量描述LOCAL_PATH这个变量用于给出当前文件的路径。必须在 Android.mk 的开头定义，可以这样使用：LOCAL_PATH := $(call my-dir)  这个变量不会被$(CLEAR_VARS)清除，因此每
个 Android.mk 只需要定义一次(即使在一个文件中定义了几个模块的情况下)。LOCAL_MODULE这是模块的名字，它必须是唯一的，而且不能包含空格。必须在包含任一的$(BUILD_XXXX)脚本之前定义它。模块的名字决定了生成文件的名字。例如，如果一个一个共享库模块的名字是，那么生成文件的名字就是 lib.so。但是，在的 NDK 生成文件中(或者 Android.mk 或者 Application.mk)，应该只涉及(引用)有正常名字的其他模块。LOCAL_SRC_FILES这是要编译的源代码文件列表。只要列出要传递给编译器的文件，因为编译系统自动计算依赖。注意源代码文件名称都是相对于 LOCAL_PATH的，你可以使用路径部分。LOCAL_CPP_EXTENSION这是一个可选变量， 用来指定C++代码文件的扩展名，默认是'.cpp',但是可以改变它。LOCAL_C_INCLUDES可选变量，表示头文件的搜索路径。LOCAL_CFLAGS可选的编译器选项，在编译 C 代码文件的时候使用。LOCAL_CXXFLAGS与 LOCAL_CFLAGS同理，针对 C++源文件。LOCAL_CPPFLAGS与 LOCAL_CFLAGS同理，但是对 C 和 C++ source files都适用。LOCAL_STATIC_LIBRARIES表示该模块需要使用哪些静态库，以便在编译时进行链接。LOCAL_SHARED_LIBRARIES表示模块在运行时要依赖的共享库（动态库），在链接时就需要，以便在生成文件时嵌入其相应的信息。注意：它不会附加列出的模块到编译图，也就是仍然需要在Application.mk 中把它们添加到程序要求的模块中。LOCAL_LDLIBS编译模块时要使用的附加的链接器选项。这对于使用‘-l’前缀传递指定库的名字是有用的。LOCAL_ALLOW_UNDEFINED_SYMBOLS默认情况下， 在试图编译一个共享库时，任何未定义的引用将导致一个“未定义的符号”错误。LOCAL_ARM_MODE默认情况下， arm目标二进制会以 thumb 的形式生成(16 位)，你可以通过设置这个变量为 arm如果你希望你的 module 是以 32 位指令的形式。LOCAL_MODULE_PATH 和 LOCAL_UNSTRIPPED_PATH在 Android.mk 文件中， 还可以用LOCAL_MODULE_PATH 和LOCAL_UNSTRIPPED_PATH指定最后的目标安装路径.
不同的文件系统路径用以下的宏进行选择：
  TARGET_ROOT_OUT：表示根文件系统。
   TARGET_OUT：表示 system文件系统。
   TARGET_OUT_DATA：表示 data文件系统。
用法如：LOCAL_MODULE_PATH :=$(TARGET_ROOT_OUT) 
至于LOCAL_MODULE_PATH 和LOCAL_UNSTRIPPED_PATH的区别，暂时还不清楚。

GNU Make 功能宏

变量描述my-dir返回当前 Android.mk 所在的目录的路径，相对于 NDK 编译系统的顶层。all-subdir-makefiles返回一个位于当前'my-dir'路径的子目录中的所有Android.mk的列表。this-makefile返回当前Makefile 的路径(即这个函数调用的地方)parent-makefile返回调用树中父 Makefile 路径。即包含当前Makefile的Makefile 路径。grand-parent-makefile返回调用树中父Makefile的父Makefile的路径

Overview 概述

---

The Android.mk file resides存在 in a subdirectory of your project's jni/directory, and describes your sources and shared libraries to the build system. It is really a tiny微小的 GNU makefile fragment that the build system parses once or more. The Android.mk file is useful for defining project-wide settings that Application.mk, the build system, and your environment variables leave undefined. It can also override project-wide settings for specific特定 modules.

The syntax语法 of the Android.mk allows you to group your sources into modules. A module is either a static library, a shared library, or a standalone独立的 executable可执行的 . You can define one or more modules in each Android.mk file, and you can use the same source file in multiple modules. The build system only places shared libraries into your application package. In addition, static libraries can generate shared libraries.

In addition to除了 packaging libraries, the build system handles a variety of other details for you. For example, you don't need to list header files or explicit明确的 dependencies依赖关系 between generated files in your Android.mk file. The NDK build system computes计算估计 these relationships automatically for you. As a result, you should be able to benefit from new toolchain/platform support in future NDK releases without having to touch your Android.mk file.

The syntax of this file is very close to that used in the Android.mk files distributed分布式 with the full Android Open Source Project. While the build system implementation that uses them is different, their similarity相似的 is an intentional有意的 design decision aimed at making it easier for application developers to reuse source code for external libraries.

Basics

---

Before exploring探索 the syntax in detail, it is useful to start by understanding the basics of what a Android.mk file contains. This section uses the Android.mk file in the Hello-JNI sample toward that end, explaining the role that each line in the file plays.

An Android.mk filemust beginby defining the LOCAL_PATH variable:

LOCAL_PATH := $(call my-dir)

This variable indicates the location of the source files in the development tree. Here, the macro function宏函数 my-dir, provided by the build system, returns the path of the current directory (the directory containing the Android.mkfile itself).

The next line declares the CLEAR_VARS variable, whose value the build system provides.

include $(CLEAR_VARS)

The CLEAR_VARS variable points to a special GNU Makefile that clears many LOCAL_XXX variables for you, such as LOCAL_MODULE, LOCAL_SRC_FILES, and LOCAL_STATIC_LIBRARIES. Note that it does not clear LOCAL_PATH. This variable语法 must retain保持 its value because the system parses all build control files in a single GNU Make execution context where all variables are global. You must (re-)declare this variable before describing each module.

Next, the LOCAL_MODULE variable stores the name of the module that you wish to build. Use this variable once per module in your application.

LOCAL_MODULE := hello-jni

Each module name must be unique唯一的 and not contain any spaces. The build system, when it generates the final shared-library file, automatically adds the proper prefix前缀 and suffix后缀 to the name that you assign to LOCAL_MODULE. For example, the example that appears above results in generation of a library called libhello-jni.so.

Note: If your module's name already starts with lib, the build system does not prepend预先考虑 an additional libprefix; it takes the module name as-is, and adds the .so extension. So a source file originally最初的 called, for example, libfoo.c still produces a shared-object file called libfoo.so. This behavior is to support libraries that the Android platform sources generate from Android.mk files; the names of all such libraries start withlib.

The next line enumerates the source files, with spaces delimiting（划界；定界限） multiple files:

LOCAL_SRC_FILES := hello-jni.c

The LOCAL_SRC_FILES variable must contain a list of C and/or C++ source files to build into a module.

The last line helps the system tie everything together:

include $(BUILD_SHARED_LIBRARY)

The BUILD_SHARED_LIBRARY variable points to a GNU Makefile script that collects all the information you defined in LOCAL_XXX variables since the most recent include. This script determines what to build, and how to do it.

There are more complex examples in the samples directories, with commented Android.mk files that you can look at. In addition, Sample: native-activity provides a detailed explanation（解释 说明） of that sample's Android.mk file. Finally, Variables and Macros provides further information on the variables from this section.

Variables and Macros变量和宏

---

The build system provides many possible variables for use in the the Android.mk file. Many of these variables come with preassigned（预先分配的预先指定的） values. Others, you assign分配.

In addition to these variables, you can also define your own arbitrary任意的 ones. If you do so, keep in mind that the NDK build system reserves（储备；保留） the following variable names:

• Names that begin with LOCAL_, such as LOCAL_MODULE.
• Names that begin with PRIVATE_, NDK_, or APP. The build system uses these internally内部的.
• Lower-case names, such as my-dir. The build system uses these internally, as well.

If you need to define your own convenience便利的 variables in an Android.mk file, we recommend prepending（预先考虑） MY_ to their names.

NDK-defined variables

This section discusses the GNU Make variables that the build system defines before parsing your Android.mkfile. Under certain circumstances情景, the NDK might parse your Android.mk file several times, using a different definition for some of these variables each time.

CLEAR_VARS

This variable points to a build script that undefines nearly all LOCAL_XXX variables listed in the "Developer-defined variables" section below. Use this variable to include this script before describing a new module. The syntax for using it is:

include $(CLEAR_VARS)

BUILD_SHARED_LIBRARY

This variable points to a build script that collects all the information about the module you provided in yourLOCAL_XXX variables变量, and determines how to build a target shared library from the sources you listed. Note that using this script requires要求 that you have already assigned分配 values to LOCAL_MODULE and LOCAL_SRC_FILES, at a minimum (for more information about these variables, see Module-Description Variables).

The syntax语法 for using this variable is:

include $(BUILD_SHARED_LIBRARY)

A shared-library variable causes the build system to generate a library file with a .so extension.

BUILD_STATIC_LIBRARY

A variant变体 of BUILD_SHARED_LIBRARY that is used to build a static library. The build system does not copy static libraries into your project/packages, but it can use them to build shared libraries (see LOCAL_STATIC_LIBRARIESand LOCAL_WHOLE_STATIC_LIBRARIES, below). The syntax for using this variable is:

include $(BUILD_STATIC_LIBRARY)

A static-library variable causes the build system to generate a library with a .a extension.

PREBUILT_SHARED_LIBRARY

Points to a build script used to specify a prebuilt shared library. Unlike in the case of BUILD_SHARED_LIBRARY andBUILD_STATIC_LIBRARY, here the value of LOCAL_SRC_FILES cannot be a source file. Instead, it must be a single path to a prebuilt shared library, such as foo/libfoo.so. The syntax for using this variable is:

include $(PREBUILT_SHARED_LIBRARY)

You can also reference a prebuilt library in another module by using the LOCAL_PREBUILTS variable. For more information about using prebuilts, see Using Prebuilt Libraries.

PREBUILT_STATIC_LIBRARY

The same as PREBUILT_SHARED_LIBRARY, but for a prebuilt static library. For more information about using prebuilts, see Using Prebuilt Libraries.

TARGET_ARCH

The name of the target CPU architecture架构 as the Android Open Source Project specifies it. For any ARM-compatible兼容性 build, use arm, independent of the CPU architecture revision or ABI (see TARGET_ARCH_ABI, below).

The value of this variable is taken from the APP_ABI variable that you define in the Android.mk file, which the system reads ahead of parsing the Android.mk file.

TARGET_PLATFORM

The Android API level number for the build system to target. For example, the Android 5.1 system images correspond to Android API level 22: android-22. For a complete list of platform names and corresponding相应 Android system images, see Android NDK Native APIs. The following example shows the syntax for using this variable:

TARGET_PLATFORM := android-22

TARGET_ARCH_ABI

This variable stores the name of the CPU and architecture to target when the build system parses thisAndroid.mk file. You can specify one or more of the following values,using a space as a delimiter(定界符分隔)符 between multiple targets. Table 1 shows the ABI setting to use for each supported CPU and architecture.

Table 1. ABI settings for different CPUs and architectures.

CPU and architectureSettingARMv5TEarmeabiARMv7armeabi-v7aARMv8 AArch64arm64-v8ai686x86x86-64x86_64mips32 (r1)mipsmips64 (r6)mips64Allall

The following example shows how to set ARMv8 AArch64 as the target CPU-and-ABI combination:

TARGET_ARCH_ABI := arm64-v8a

Note: Up to Android NDK 1.6_r1, this variable is defined as arm.

For more details about architecture ABIs and associated compatibility issues, refer to ABI Management.

New target ABIs in the future will have different values.

TARGET_ABI

A concatenation(串联，连结) of target Android API level and ABI, it is especially useful when you want to test against a specific target system image for a real device. For example, to specify a 64-bit ARM device running on Android API level 22:

TARGET_ABI := android-22-arm64-v8a

Note: Up to Android NDK 1.6_r1, the default value was android-3-arm.

Module-Description Variables

---

The variables in this section describe your module to the build system. Each module description should follow this basic flow:

1. Initialize or undefine the variables associated相关的 with the module, using the CLEAR_VARS variable.
2. Assign分配 values to the variables used to describe the module.
3. Set the NDK build system to use the appropriate适当 build script for the module, using the BUILD_XXX variable.

LOCAL_PATH

This variable is used to give the path of the current file. You must define it at the start of your Android.mk file. The following example shows how to do so:

LOCAL_PATH := $(call my-dir)

The script to which CLEAR_VARS points does not clear this variable. Therefore,you only need to define it a single time, even if your Android.mk file describes multiple modules.

LOCAL_MODULE

This variable stores the name of your module. It must be unique among all module names, and must not contain any spaces. You must define it before including any scripts (other than the one for CLEAR_VARS). You need not add either the lib prefix or the .so or .a file extension; the build system makes these modifications变动 automatically. Throughout your Android.mk and Application.mk files, refer to your module by its unmodified name. For example, the following line results in the generation of a shared library module called libfoo.so:

LOCAL_MODULE := "foo"

If you want the generated module to have a name other than lib + the value of LOCAL_MODULE, you can use theLOCAL_MODULE_FILENAME variable to give the generated module a name of your own choosing, instead.

LOCAL_MODULE_FILENAME

This optional variable allows you to override the names that the build system uses by default for files that it generates. For example, if the name of your LOCAL_MODULE is foo, you can force the system to call the file it generates libnewfoo. The following example shows how to accomplish完成 this:

LOCAL_MODULE := fooLOCAL_MODULE_FILENAME := libnewfoo

For a shared library module, this example would generate a file called libnewfoo.so.

Note: You cannot override filepath or file extension.

LOCAL_SRC_FILES

This variable contains the list of source files that the build system uses to generate the module. Only list the files that the build system actually passes to the compiler, since the build system automatically computes计算 any associated相关的 depencies依赖.

Note that you can use both relative (to LOCAL_PATH) and absolute file paths.

We recommend avoiding absolute file paths; relative paths make your Android.mk file more portable轻便的.

Note: Always use Unix-style forward slashes (/) in build files. The build system does not handle Windows-style backslashes (\) properly.

LOCAL_CPP_EXTENSION

You can use this optional variable to indicate a file extension other than .cpp for your C++ source files. For example, the following line changes the extension to .cxx. (The setting must include the dot.)

LOCAL_CPP_EXTENSION := .cxx

From NDK r7, you can use this variable to specify multiple extensions. For instance:

LOCAL_CPP_EXTENSION := .cxx .cpp .cc

LOCAL_CPP_FEATURES

You can use this optional variable to indicate that your code relies on specific C++ features. It enables the right compiler and linker flags during the build process. For prebuilt binaries, this variable also declares which features the binary depends on, thus helping ensure the final linking works correctly. We recommend that you use this variable instead of enabling -frtti and -fexceptions directly in your LOCAL_CPPFLAGS definition.

Using this variable allows the build system to use the appropriate适当的 flags for each module. Using LOCAL_CPPFLAGScauses the compiler to use all specified flags for all modules, regardless of actual need.

For example, to indicate that your code uses RTTI (RunTime Type Information), write:

LOCAL_CPP_FEATURES := rtti

To indicate that your code uses C++ exceptions, write:

LOCAL_CPP_FEATURES := exceptions

You can also specify multiple values for this variable. For example:

LOCAL_CPP_FEATURES := rtti features

The order in which you describe the values does not matter.

LOCAL_C_INCLUDES

You can use this optional variable to specify a list of paths, relative to the NDK root directory, to add to the include search path when compiling all sources (C, C++ and Assembly). For example:

LOCAL_C_INCLUDES := sources/foo

Or even:

LOCAL_C_INCLUDES := $(LOCAL_PATH)//foo

Define this variable before setting any corresponding（相当的，相应的） inclusion flags via LOCAL_CFLAGS or LOCAL_CPPFLAGS.

The build system also uses LOCAL_C_INCLUDES paths automatically when launching native debugging with ndk-gdb.

LOCAL_CFLAGS

This optional variable sets compiler flags for the build system to pass when building C and C++ source files. The ability to do so can be useful for specifying additional macro definitions or compile options.

Try not to change the optimization（优化最优化最佳化）/debugging level in your Android.mk file. The build system can handle this setting automatically for you, using the relevant相关的 information in the Application.mk file. Doing it this way allows the build system to generate useful data files used during debugging.

Note: In android-ndk-1.5_r1, the corresponding相应的 flags only applied to C source files, not C++ ones. They now match the full Android build system behavior. (You can now use LOCAL_CPPFLAGS to specify flags for C++ sources only.)

It is possible to specify additional include paths by writing:

LOCAL_CFLAGS += -I<path>,

It is better, however, to use LOCAL_C_INCLUDES for this purpose, since doing so also makes it possible to use the paths available for native debugging with ndk-gdb.

LOCAL_CPPFLAGS

An optional set of compiler flags that will be passed when building C++ source files only. They will appear after the LOCAL_CFLAGS on the compiler's command-line.

Note: In android-ndk-1.5_r1, the corresponding flags applied to both C and C++ sources. This has been corrected to match the full Android build system. To specify flags for both C and C++ sources, useLOCAL_CFLAGS.

LOCAL_STATIC_LIBRARIES

This variable stores the list of static libraries modules on which the current module depends.

If the current module is a shared library or an executable, this variable will force these libraries to be linked into the resulting binary.

If the current module is a static library, this variable simply indicates指示表明 that other modules depending on the current one will also depend on the listed libraries.

LOCAL_SHARED_LIBRARIES

This variable is the list of shared libraries modules on which this module depends at runtime. This information is necessary at link time, and to embed嵌入 the corresponding information in the generated file.

LOCAL_WHOLE_STATIC_LIBRARIES

This variable is a variant（不同的；多样的） of LOCAL_STATIC_LIBRARIES, and expresses that the linker should treat对待 the associated相关的 library modules as whole archives档案. For more information on whole archives档案, see the GNU linker's documentation for the --whole-archive flag.

This variable is useful when there are circular dependencies among several static libraries. When you use this variable to build a shared library, it will force the build system to add all object files from your static libraries to the final binary. The same is not true, however, when generating executables.

LOCAL_LDLIBS

This variable contains the list of additional linker flags for use in building your shared library or executable. It enables you to use the -l prefix前缀 to pass the name of specific system libraries. For example, the following example tells the linker to generate a module that links to /system/lib/libz.so at load time:

LOCAL_LDLIBS := -lz

For the list of exposed system libraries against which you can link in this NDK release, see Android NDK Native APIs.

Note: If you define this variable for a static library, the build system ignores it, and ndk-build prints a warning.

LOCAL_LDFLAGS

The list of other linker flags for the build system to use when building your shared library or executable. For example, the following example uses the ld.bfd linker on ARM/X86 GCC 4.6+, on which ld.gold is the default

LOCAL_LDFLAGS += -fuse-ld=bfd

Note: If you define this variable for a static library, the build system ignores it, and ndk-build prints a warning.

LOCAL_ALLOW_UNDEFINED_SYMBOLS

By default, when the build system encounters遭遇 an undefined reference encountered while trying to build a shared, it will throw an undefined symbol error. This error can help you catch catch bugs in your source code.

To disable this check, set this variable to true. Note that this setting may cause the shared library to load at runtime.

Note: If you define this variable for a static library, the build system ignores it, and ndk-build prints a warning.

LOCAL_ARM_MODE

By default, the build system generates ARM target binaries in thumb mode, where each instruction is 16 bits wide and linked with the STL（标准模板库（Standard Template Library）） libraries in the thumb/ directory. Defining this variable as arm forces the build system to generate the module's object files in 32-bit arm mode. The following example shows how to do this:

LOCAL_ARM_MODE := arm

You can also instruct（指导；通知；命令） the build system to only build specific sources in arm mode by appending .arm suffix后缀 to the the source filenames. For example, the following example tells the build system to always compile bar.c in ARM mode, but to build foo.c according根据 to the value of LOCAL_ARM_MODE.

LOCAL_SRC_FILES := foo.c bar.c.arm

Note: You can also force the build system to generate ARM binaries by setting APP_OPTIM in yourApplication.mk file to debug. Specifying debug forces an ARM build because the toolchain debugger does not handle Thumb code properly.

LOCAL_ARM_NEON

This variable only matters when you are targeting the armeabi-v7a ABI. It allows the use of ARM Advanced SIMD (NEON) GCC intrinsics（固有的；本质的） in your C and C++ sources, as well as NEON instructions in Assembly（装配 集结号组装） files.

Note that not all ARMv7-based CPUs support the NEON instruction set extensions. For this reason, you must perform runtime detection（检测察觉侦测） to be able to safely use this code at runtime. For more information, see NEON Supportand The cpufeatures Library.

Alternatively, you can use the .neon suffix to specify that the build system only compile specific source files with NEON support. In the following example, the build system compiles foo.c with thumb and neon support, bar.cwith thumb support, and zoo.c with support for ARM and NEON:

LOCAL_SRC_FILES = foo.c.neon bar.c zoo.c.arm.neon

If you use both suffixes, .arm must precede .neon.

LOCAL_DISABLE_NO_EXECUTE

Android NDK r4 added support for the "NX bit" security feature. It is enabled by default, but you can disable it by setting this variable to true. We do not recommend doing so without a compelling reason.

This feature does not modify the ABI, and is only enabled on kernels targeting ARMv6+ CPU devices. Machine code with this feature enabled will run unmodified on devices running earlier CPU architectures.

For more information, see Wikipedia: NX bit and The GNU stack kickstart.

LOCAL_DISABLE_RELRO

By default, the NDK compiles code with read-only relocations重定位 and GOT protection. This variable instructs the runtime linker to mark certain regions of memory as read-only after relocation, making certain security exploits开发利用 (such as GOT overwrites) more difficult. Note that these protections are only effective起作用的 on Android API level 16 and higher. On lower API levels, the code will still run, but without memory protections.

This variable is turned on by default, but you can disable it by setting its value to true. We do not recommend doing so without a compelling reason.

For more information, see RELRO: RELocation Read-Only and Security enhancements in RedHat Enterprise Linux (section 6).

LOCAL_DISABLE_FORMAT_STRING_CHECKS

By default, the build system compiles code with format string protection. Doing so forces a compiler error if a non-constant不定的 format string is used in a printf-style function.

This protection is on by default, but you can disable it by setting the value of this variable to true. We do not recommend doing so without a compelling reason.

LOCAL_EXPORT_CFLAGS

This variable records a set of C/C++ compiler flags to add to the LOCAL_CFLAGS definition of any other module that uses this one via（渠道，通过；经由） the LOCAL_STATIC_LIBRARIES or LOCAL_SHARED_LIBRARIES variables.

For example, consider the following pair of modules: foo and bar, which depends on foo:

include $(CLEAR_VARS)LOCAL_MODULE := fooLOCAL_SRC_FILES := foo/foo.cLOCAL_EXPORT_CFLAGS := -DFOO=1include $(BUILD_STATIC_LIBRARY)include $(CLEAR_VARS)LOCAL_MODULE := barLOCAL_SRC_FILES := bar.cLOCAL_CFLAGS := -DBAR=2LOCAL_STATIC_LIBRARIES := fooinclude $(BUILD_SHARED_LIBRARY)

Here, the build system passes the flags -DFOO=1 and -DBAR=2 to the compiler when building bar.c. It also prepends预先考虑 exported输出 flags to your your module's LOCAL_CFLAGS so you can easily override them.

In addition, the relationship among modules is transitive: If zoo depends on bar, which in turn depends onfoo, then zoo also inherits继承 all flags exported from foo.

Finally, the build system does not use exported flags when building locally (i.e., building the module whose flags it is exporting). Thus, in the example above, it does not pass -DFOO=1 to the compiler when building foo/foo.c. To build locally, use LOCAL_CFLAGS instead.

LOCAL_EXPORT_CPPFLAGS

This variable is the same as LOCAL_EXPORT_CFLAGS, but for C++ flags only.

LOCAL_EXPORT_C_INCLUDES

This variable is the same as LOCAL_EXPORT_CFLAGS, but for C include paths. It is useful in cases where, for example, bar.c needs to include headers from module foo.

LOCAL_EXPORT_LDFLAGS

This variable is the same as LOCAL_EXPORT_CFLAGS, but for linker flags.

LOCAL_EXPORT_LDLIBS

This variable is the same as LOCAL_EXPORT_CFLAGS, telling the build system to pass names of specific system libraries to the compiler. Prepend -l to the name of each library you specify.

Note that the build system appends imported linker flags to the value of your module's LOCAL_LDLIBS variable. It does this due to the way Unix linkers work.

This variable is typically典型的 useful when module foo is a static library and has code that depends on a system library. You can then use LOCAL_EXPORT_LDLIBS to to export the dependency. For example:

include $(CLEAR_VARS)LOCAL_MODULE := fooLOCAL_SRC_FILES := foo/foo.cLOCAL_EXPORT_LDLIBS := -lloginclude $(BUILD_STATIC_LIBRARY)include $(CLEAR_VARS)LOCAL_MODULE := barLOCAL_SRC_FILES := bar.cLOCAL_STATIC_LIBRARIES := fooinclude $(BUILD_SHARED_LIBRARY)

In this example, the build system puts -llog at the end of the linker command when it builds libbar.so. Doing so tells the linker that, because libbar.so depends on foo, it also depends on the system logging library.

LOCAL_SHORT_COMMANDS

Set this variable to true when your module has a very high number of sources and/or dependent static or shared libraries. Doing so forces the build system to use @ syntax for archives（档案 文章归档） containing intermediate中间 object files or linking libraries.

This feature can be useful on Windows, where the command line accepts a maximum of only of 8191 characters, which can be too small for complex复杂的；合成的 projects. It also impacts影响 the compilation编译 of individual source files, placing nearly all compiler flags inside list files, too.

Note that any value other than true will revert（恢复回复复原） to the default behaviour. You can also defineAPP_SHORT_COMMANDS in your Application.mk file to force this behavior for all modules in your project.

We do not recommend enabling this feature by default, since it makes the build slower.

LOCAL_THIN_ARCHIVE

Set this variable to true when building static libraries. Doing so will generate a thin archive, a library file that does not contain object files, but instead just file paths to the actual objects that it would normally contain.

This is useful to reduce减少 the size of your build output. The drawback（缺点退税弊端） is that such libraries cannot be moved to a different location (all paths inside them are relative).

Valid有效的 正当的 values are true, false or empty. A default value can be set in your Application.mk file through theAPP_THIN_ARCHIVE variable.

Note: This is ignored for non-static library modules, or prebuilt static library ones.

LOCAL_FILTER_ASM

Define this variable as a shell command that the build system will use to filter the assembly（装配集结号组装） files extracted片 or generated from the files you specified for LOCAL_SRC_FILES.

Defining this variable causes the following things to occur:

1. The build system generates a temporary临时的 assembly file from any C or C++ source file, instead of compiling them into an object file.
2. The build system executes the shell command in LOCAL_FILTER_ASM on any temporary assembly file and on any assembly file listed in LOCAL_SRC_FILES, thus generating another temporary assembly file.
3. The build system compiles these filtered assembly files into an object file.

For example:

LOCAL_SRC_FILES  := foo.c bar.SLOCAL_FILTER_ASM :=foo.c --1--> $OBJS_DIR/foo.S.original --2--> $OBJS_DIR/foo.S --3--> $OBJS_DIR/foo.obar.S                                 --2--> $OBJS_DIR/bar.S --3--> $OBJS_DIR/bar.o

"1" corresponds to the compiler, "2" to the filter, and "3" to the assembler. The filter must be a standalone shell command that takes the name of the input file as its first argument, and the name of the output file as the second one. For example:

myasmfilter $OBJS_DIR/foo.S.original $OBJS_DIR/foo.Smyasmfilter bar.S $OBJS_DIR/bar.S

NDK-provided function macros

This section explains GNU Make function macros that the NDK provides. Use $(call <function>) to evaluate them; they return textual本文的 information.

my-dir

This macro returns the path of the last included makefile, which typically is the current Android.mk's directory.my-dir is useful for defining LOCAL_PATH at the start of your Android.mk file. For example:

LOCAL_PATH := $(call my-dir)

Due to the way GNU Make works, what this macro really returns is the path of the last makefile that the build system included when parsing the build scripts. For this reason, you should not call my-dir after including another file.

For example, consider the following example:

LOCAL_PATH := $(call my-dir)# ... declare one moduleinclude $(LOCAL_PATH)/foo/`Android.mk`LOCAL_PATH := $(call my-dir)# ... declare another module

The problem here is that the second call to my-dir defines LOCAL_PATH as $PATH/foo instead of $PATH, because that was where its most recent include pointed.

You can avoid避免 this problem by putting additional includes after everything else in the Android.mk file. For example:

LOCAL_PATH := $(call my-dir)# ... declare one moduleLOCAL_PATH := $(call my-dir)# ... declare another module# extra includes at the end of the Android.mk fileinclude $(LOCAL_PATH)/foo/Android.mk

If it is not feasible可行的 to structure the file in this way, save the value of the first my-dir call into another variable. For example:

MY_LOCAL_PATH := $(call my-dir)LOCAL_PATH := $(MY_LOCAL_PATH)# ... declare one moduleinclude $(LOCAL_PATH)/foo/`Android.mk`LOCAL_PATH := $(MY_LOCAL_PATH)# ... declare another module

all-subdir-makefiles

Returns the list of Android.mk files located in all subdirectories of the current my-dir path.

You can use this function to provide deep-nested source directory hierarchies层次 to the build system. By default, the NDK only looks for files in the directory containing the Android.mk file.

this-makefile

Returns the path of the current makefile (from which the build system called the function).

parent-makefile

Returns the path of the parent makefile in the inclusion tree (the path of the makefile that included the current one).

grand-parent-makefile

Returns the path of the grandparent makefile in the inclusion tree (the path of the makefile that included the current one).

import-module

A function that allows you to find and include a module's Android.mk file by the name of the module. A typical example is as follows:

$(call import-module,<name>)

In this example, the build system looks for the module tagged <name> in the list of directories referenced参考  that your NDK_MODULE_PATH environment variable references, and includes its Android.mk file automatically for you.