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

The last line of the help system connects everything together:

include $ (BUILD_SHARED_LIBRARY)
  

BUILD_SHARED_LIBRARY The variable points to a GNU Makefile script, which will collect your most recent include all the information defined in the LOCAL_XXX variable. This script determines what to compile and how to compile.

There are more complex examples in the example directory, including the annotated Android.mk file for your reference. In addition, example: native-activity details the Android.mk file of this example. Finally, variables and macros provide more information about the variables in this section.

Variables and macros

The compilation system provides many variables that can be used in the Android.mk file. Many of these variables are pre-assigned. Other variables are assigned by you.

In addition to these variables, you can also define any variables yourself. When defining variables, please note that the NDK compilation system reserves the following variable names:

• Names beginning with LOCAL_, such as LOCAL_MODULE.
• Names beginning with PRIVATE_, NDK_ or APP. The compilation system uses these variable names internally.
• Lower case name, such as my-dir. The compilation system also uses these variable names internally.

If you need to define your own variables in the Android.mk file for convenience, it is recommended to add MY_ before the name.

NDK-defined include variables

This section discusses the GNU Make variables defined by the compilation system before parsing the Android.mk file. In some cases, the NDK may parse the Android.mk file multiple times, each time using different definitions of some of the variables.

CLEAR_VARS

The compiled script pointed to by this variable is used to undefine almost all LOCAL_XXX variables listed in the “Variables Defined by Developers” section below. Before describing the new module, use this variable to include this script. The syntax for using it is:

include $(CLEAR_VARS)
 

BUILD_SHARED_LIBRARY

The compilation script pointed to by this variable is used to collect all the relevant information of the module you provided in the LOCAL_XXX variable, and to determine how to compile the target based on the source file you listed Shared library. Please note that using this script requires that you have at least assigned values ​​for LOCAL_MODULE and LOCAL_SRC_FILES (for details about these variables, please refer to the module description variables).

The syntax for using this variable is:

include $(BUILD_SHARED_LIBRARY)
 

Shared library variables will cause the compilation system to generate library files with the extension .so.

BUILD_STATIC_LIBRARY

The variant of BUILD_SHARED_LIBRARY used to compile static libraries. The build system will not copy static libraries into your project/package, but you can use static libraries to compile shared libraries (see LOCAL_STATIC_LIBRARIES and LOCAL_WHOLE_STATIC_LIBRARIES below). The syntax for using this variable is:

include $(BUILD_STATIC_LIBRARY< span class="pun">)
 

Static library variables will cause the compilation system to generate a library with the extension .a.

PREBUILT_SHARED_LIBRARY

Point to the compilation script used to specify the pre-compiled shared library. Unlike the cases of BUILD_SHARED_LIBRARY and BUILD_STATIC_LIBRARY, the value of LOCAL_SRC_FILES here cannot be a source file, but must be a path to a precompiled shared library. For example, foo/libfoo.so. The syntax for using this variable is:

include $(PREBUILT_SHARED_LIBRARY< span class="pun">)
 

You can also use the LOCAL_PREBUILTS variable to refer to a pre-compiled library in another module. To learn more about how to use precompiled libraries, see Using precompiled libraries.

PREBUILT_STATIC_LIBRARY

Same as PREBUILT_SHARED_LIBRARY, but used to precompile static libraries. To learn more about how to use precompiled libraries, see Using precompiled libraries.

Target information variable h3>

The compilation system will parse each ABI specified by the APP_ABI variable once Android.mk. The variable is usually in the Defined in the >Application.mk file. If APP_ABI is all, the compilation system will parse Android.mk once according to each ABI supported by the NDK. This section introduces the variables defined every time the compilation system parses Android.mk.

TARGET_ARCH

The CPU series for which the compilation system parses this Android.mk file. This variable is one of arm, arm64, x86 or x86_64.

TARGET_PLATFORM

The Android API level number for which the compilation system parses this Android.mk file. For example, the Android 5.1 system image corresponds to Android API level 22: android-22. For a complete list of platform names and corresponding Android system images, please refer to Android NDK Native API. The following example demonstrates the syntax for using this variable:

ifeq ( $(TARGET_PLATFORM),android-22)
 # ... do something ...
 endif
  span>

TARGET_ARCH_ABI

The compilation system parses this Android.mk The ABI for the file. Table 1 shows the ABI settings for each supported CPU and architecture.

ifeq ($(TARGET_ARCH_ABI),arm64- v8a)
 # ... do something ...
 endif
 

ifeq ($(TARGET_ABI),android-22-arm64-v8a)
 # ... do something ...
 endif
  /span>

LOCAL_PATH := $(call my-dir)
  span>

LOCAL_MODULE := "foo"
 < /span>

If you want the generated module to use "lib + < For names other than the value of code>LOCAL_MODULE, you can use the LOCAL_MODULE_FILENAME variable to specify the name of your choice for the generated module.

LOCAL_MODULE_FILENAME

This optional variable allows you to replace the default name used by the compilation system for the files it generates. For example, if the name of LOCAL_MODULE is foo, you can force the system to name the file it generates as libnewfoo. The following example demonstrates how to accomplish this:

LOCAL_MODULE := foo
 LOCAL_MODULE_FILENAME := libnewfoo
 

For shared library modules, this example will generate a file named libnewfoo.so.

Note: You cannot substitute file paths or file extensions.

LOCAL_SRC_FILES

This variable contains a list of source files used by the compilation system to generate the module. Only the files actually passed by the compilation system to the compiler are listed, because the compilation system automatically calculates all related dependencies. Please note that you can use relative (relative to LOCAL_PATH) and absolute file paths.

It is recommended to avoid using absolute file paths; relative paths can improve the portability of Android.mk files.

Note: Be sure to use Unix-style forward slashes (/) in the compiled file. The compilation system cannot handle Windows-style backslashes (\) correctly.

LOCAL_CPP_EXTENSION

You can use this optional variable to specify a file extension other than .cpp for the C++ source file. For example, the following line changes the extension to .cxx. (The setting must contain dots.)

LOCAL_CPP_EXTENSION := .cxx
 

You can use this variable to specify multiple extensions. For example:

LOCAL_CPP_EXTENSION := .cxx .cpp .cc
 

LOCAL_CPP_FEATURES

You can use this optional variable to indicate that your code depends on specific C++ features. It will enable the correct compiler flags and linker flags during the compilation process. For pre-compiled binary files, this variable also declares which functions the binary file depends on to ensure that the final link runs normally. It is recommended that you use this variable instead of directly enabling -frtti and -fexceptions in the definition of LOCAL_CPPFLAGS.

Using this variable allows the compilation system to use the appropriate tags for each module. Using LOCAL_CPPFLAGS will cause the compiler to use all specified tags for all modules, regardless of actual requirements.

For example, to indicate that your code uses RTTI (Runtime Type Information), enter:

LOCAL_CPP_FEATURES < span class="pun">:= rtti
 

To indicate that your code uses C++ exceptions, please enter:

LOCAL_CPP_FEATURES := exceptions
 

< p>You can also specify multiple values ​​for this variable. For example:

LOCAL_CPP_FEATURES := rtti features
 

The order in which the values ​​are described does not matter.

LOCAL_C_INCLUDES

You can use this optional variable to specify a path list relative to the NDK root directory, so that it can be added to the include search path when compiling all source files (C, C++, and Assembly). For example:

LOCAL_C_INCLUDES := sources/foo
 

Or even:

LOCAL_C_INCLUDES := $(LOCAL_PATH)/<subdirectory>/foo
 

Please set any corresponding Define this variable before including the tag.

When using ndk-gdb to start native debugging, the compilation system will also automatically use the LOCAL_C_INCLUDES path.

LOCAL_CFLAGS

This optional variable is used to set the compiler flags to be passed by the compilation system when compiling C and C++ source files. In this way, you can specify additional macro definitions or compilation options. You can use LOCAL_CPPFLAGS to specify tags only for C++.

Don’t try to change the optimization/debugging level in the Android.mk file. The compilation system can use the relevant information in the [pplication.mk] file to automatically handle this setting. In this way, the compilation system can generate useful data files for use during debugging.

You can specify additional include paths by entering the following code:

LOCAL_CFLAGS  += -I,
 

However, it is better to use LOCAL_C_INCLUDES, because this can also use the path that can be used for ndk-gdb native debugging.

LOCAL_CPPFLAGS

A set of optional compiler flags that will be passed when compiling only C++ source files. They will appear after LOCAL_CFLAGS in the compiler command line. Use LOCAL_CFLAGS to specify tags for C and C++.

LOCAL_STATIC_LIBRARIES

This variable is used to store the list of static library modules that the current module depends on.

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

If the current module is a static library, this variable just indicates that other modules that depend on the current module will also depend on the listed libraries.

LOCAL_SHARED_LIBRARIES

This variable will list the shared library modules that this module depends on at runtime. This information is necessary for linking and is used to embed the corresponding information in the generated file.

LOCAL_WHOLE_STATIC_LIBRARIES

This variable is a variant of LOCAL_STATIC_LIBRARIES, which means that the linker should treat the related library module as a complete archive. To learn more about the complete archive, please refer to the --whole-archive tag section of the GNU ld documentation.

This variable is useful when there are circular dependencies between multiple static libraries. When using this variable to compile a shared library, it will force the compilation system to add all object files in the static library to the final binary file. However, this does not happen when generating executable files.

LOCAL_LDLIBS

This variable lists additional linker tags used when compiling shared libraries or executable files. With this variable, you can use the -l prefix to pass the name of a specific system library. For example, the following example instructs the linker to generate a module that links to /system/lib/libz.so at load time:

LOCAL_LDLIBS := -lz
 

If you need to understand the public systems that can be linked in this NDK version For the list of libraries, please refer to Android NDK Native API.

Note: If you define this variable for a static library, the compilation system will ignore this variable, and ndk-build will display a warning.

LOCAL_LDFLAGS

This variable lists other linker tags used by the build system when compiling shared libraries or executable files. For example, to use the ld.bfd linker on ARM/X86:

LOCAL_LDFLAGS += -fuse-ld< span class="pun">=bfd
  span>

Note: If this variable is defined for a static library, the compilation system This variable will be ignored, and ndk-build will display a warning.

LOCAL_ALLOW_UNDEFINED_SYMBOLS

By default, if the compilation system encounters an undefined reference when trying to compile a shared library, it will throw an “undefined symbol” error. This error can help you catch errors in the source code.

To disable this check, set this variable to true. Please note that this setting may cause shared libraries to be loaded at runtime.

Note: If you define this variable for a static library, the build system will ignore this variable, and ndk-build will display a warning.

LOCAL_ARM_MODE

By default, the compilation system will generate an ARM target binary file in thumb mode, where each instruction is 16 bits wide and is associated with the STL library in the thumb/ directory. Defining this variable as arm will force the compilation system to generate the object file of the module in 32-bit arm mode. The following example demonstrates how to do this:

LOCAL_ARM_MODE := arm
 

You can also append the source file name< The code>.arm suffix indicates that the compilation system only compiles specific source files in arm mode. For example, the following example instructs the compilation system to always compile bar.c in ARM mode, but compile foo.c according to the value of LOCAL_ARM_MODE.

LOCAL_SRC_FILES := foo.c bar.c.arm
    

注意：您也可以在 Application.mk 文件中将 APP_OPTIM 设置为 debug，以强制编译系统生成 ARM 二进制文件。指定 debug会强制执行 ARM 编译，因为工具链调试程序无法正确处理 Thumb 代码。

LOCAL_ARM_NEON

此变量仅在以 armeabi-v7a ABI 为目标时才有意义。它允许在 C 和 C++ 源代码中使用 ARM Advanced SIMD (NEON) 编译器内建函数，以及在 Assembly 文件中使用 NEON 指令。

请注意，并非所有基于 ARMv7 的 CPU 都支持 NEON 扩展指令集。因此，必须执行运行时检测，以便在运行时安全地使用此代码。详情请参阅 NEON 支持和 cpufeatures 库。

此外，您也可以使用 .neon 后缀，指定编译系统仅以 NEON 支持编译特定源文件。在以下示例中，编译系统以 Thumb 和 NEON 支持编译 foo.c，以 Thumb 支持编译 bar.c，并以 ARM 和 NEON 支持编译 zoo.c：

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

如果同时使用这两个后缀，则 .arm 必须在 .neon 前面。

LOCAL_DISABLE_FORMAT_STRING_CHECKS

默认情况下，编译系统会在编译代码时保护格式字符串。这样的话，如果 printf 样式的函数中使用了非常量格式的字符串，就会强制引发编译器错误。此保护默认启用，但您也可通过将此变量的值设置为 true 将其停用。如果没有必要的原因，我们不建议停用。

LOCAL_EXPORT_CFLAGS

此变量用于记录一组 C/C++ 编译器标记，这些标记将添加到通过 LOCAL_STATIC_LIBRARIES 或 LOCAL_SHARED_LIBRARIES 变量使用此模块的任何其他模块的 LOCAL_CFLAGS 定义中。

例如，假设有下面这一对模块：foo 和 bar，bar 依赖于 foo：

include $(CLEAR_VARS)
    LOCAL_MODULE := foo
    LOCAL_SRC_FILES := foo/foo.c
    LOCAL_EXPORT_CFLAGS := -DFOO=1
    include $(BUILD_STATIC_LIBRARY)

    include $(CLEAR_VARS)
    LOCAL_MODULE := bar
    LOCAL_SRC_FILES := bar.c
    LOCAL_CFLAGS := -DBAR=2
    LOCAL_STATIC_LIBRARIES := foo
    include $(BUILD_SHARED_LIBRARY)
    

在此例中，编译系统在编译 bar.c 时会向编译器传递 -DFOO=1 和 -DBAR=2 标记。它还会在模块的 LOCAL_CFLAGS 前面加上导出的标记，以便您轻松进行替换。

此外，模块之间的关系也具有传递性：如果 zoo 依赖于 bar，而后者依赖于 foo，那么 zoo 也会继承从 foo 导出的所有标记。

最后，编译系统在执行局部编译时（即，编译要导出标记的模块时），不使用导出的标记。因此，在上面的示例中，编译 foo/foo.c 时不会将 -DFOO=1 传递到编译器。要执行局部编译，请改用 LOCAL_CFLAGS。

LOCAL_EXPORT_CPPFLAGS

此变量与 LOCAL_EXPORT_CFLAGS 相同，但仅适用于 C++ 标记。

LOCAL_EXPORT_C_INCLUDES

此变量与 LOCAL_EXPORT_CFLAGS 相同，但适用于 C include 路径。例如，当 bar.c 需要包含模块 foo 的头文件时，此变量很有用。

LOCAL_EXPORT_LDFLAGS

此变量与 LOCAL_EXPORT_CFLAGS 相同，但适用于链接器标记。

LOCAL_EXPORT_LDLIBS

此变量与 LOCAL_EXPORT_CFLAGS 相同，告诉编译系统将特定系统库的名称传递给编译器。请在您指定的每个库名称前附加 -l。

请注意，编译系统会将导入的链接器标记附加到模块的 LOCAL_LDLIBS 变量值上。其原因在于 Unix 链接器的工作方式。

当模块 foo 是静态库并且具有依赖于系统库的代码时，此变量通常很有用。然后，您可以使用 LOCAL_EXPORT_LDLIBS导出依赖关系。例如：

include $(CLEAR_VARS)
    LOCAL_MODULE := foo
    LOCAL_SRC_FILES := foo/foo.c
    LOCAL_EXPORT_LDLIBS := -llog
    include $(BUILD_STATIC_LIBRARY)

    include $(CLEAR_VARS)
    LOCAL_MODULE := bar
    LOCAL_SRC_FILES := bar.c
    LOCAL_STATIC_LIBRARIES := foo
    include $(BUILD_SHARED_LIBRARY)
    

在此示例中，编译系统在编译 libbar.so 时，在链接器命令的末尾指定了 -llog。这样就会告知链接器，由于 libbar.so 依赖于 foo，因此它也依赖于系统日志记录库。

LOCAL_SHORT_COMMANDS

当模块有很多源文件和/或依赖的静态或共享库时，请将此变量设置为 true。这样会强制编译系统将 @ 语法用于包含中间对象文件或链接库的归档。

此功能在 Windows 上可能很有用，在 Windows 上，命令行最多只接受 8191 个字符，这对于复杂的项目来说可能太少。它还会影响个别源文件的编译，而且将几乎所有编译器标记都放在列表文件内。

请注意，true 以外的任何值都将恢复为默认行为。您也可以在 Application.mk 文件中定义 APP_SHORT_COMMANDS，以对项目中的所有模块强制实施此行为。

不建议默认启用此功能，因为它会减慢编译速度。

LOCAL_THIN_ARCHIVE

编译静态库时，请将此变量设置为 true。这样会生成一个瘦归档，即一个库文件，其中不含对象文件，而只包含它通常包含的实际对象的文件路径。

这对于减小编译输出的大小非常有用。但缺点是，这样的库无法移至其他位置（其中的所有路径都是相对路径）。

有效值为 true、false 或空白。您可在 Application.mk 文件中通过 APP_THIN_ARCHIVE 变量设置默认值。

注意：在非静态库模块或预编译的静态库模块中，将会忽略此变量。

LOCAL_FILTER_ASM

请将此变量定义为一个 shell 命令，供编译系统用于过滤根据您为 LOCAL_SRC_FILES 指定的文件提取或生成的汇编文件。定义此变量会导致发生以下情况：

1. 编译系统从任何 C 或 C++ 源文件生成临时汇编文件，而不是将它们编译到对象文件中。
2. 编译系统在任何临时汇编文件以及 LOCAL_SRC_FILES 中所列任何汇编文件的 LOCAL_FILTER_ASM 中执行 shell 命令，因此会生成另一个临时汇编文件。
3. 编译系统将这些过滤的汇编文件编译到对象文件中。

例如：

LOCAL_SRC_FILES  := foo.c bar.S
    LOCAL_FILTER_ASM :=

    foo.c --1--> $OBJS_DIR/foo.S.original --2--> $OBJS_DIR/foo.S --3--> $OBJS_DIR/foo.o
    bar.S                                 --2--> $OBJS_DIR/bar.S --3--> $OBJS_DIR/bar.o
    

“1”对应于编译器，“2”对应于过滤器，“3”对应于汇编程序。过滤器必须是一个独立的 shell 命令，它接受输入文件名作为第一个参数，接受输出文件名作为第二个参数。例如：

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

NDK 提供的函数宏

本部分介绍了 NDK 提供的 GNU Make 函数宏。使用 $(call ) 可以对这些宏进行求值；它们将返回文本信息。

my-dir

这个宏返回最后包含的 makefile 的路径，通常是当前 Android.mk 的目录。 my-dir 可用于在 Android.mk 文件的开头定义 LOCAL_PATH。例如：

LOCAL_PATH := $(call my-dir)
    

由于 GNU Make 的工作方式，这个宏实际返回的是编译系统解析编译脚本时包含的最后一个 makefile 的路径。因此，包含其他文件后就不应调用 my-dir。

例如：

LOCAL_PATH := $(call my-dir)

    # ... declare one module

    include $(LOCAL_PATH)/foo/`Android.mk`

    LOCAL_PATH := $(call my-dir)

    # ... declare another module
    

该示例的问题在于，对 my-dir 的第二次调用将 LOCAL_PATH 定义为 $PATH/foo，而不是 $PATH，因为这是其最近的 include 所指向的位置。

在 Android.mk 文件中的所有其他内容后添加额外的 include 可避免此问题。例如：

LOCAL_PATH := $(call my-dir)

    # ... declare one module

    LOCAL_PATH := $(call my-dir)

    # ... declare another module

    # extra includes at the end of the Android.mk file
    include $(LOCAL_PATH)/foo/Android.mk
    < /span>

如果以这种方式构造文件不可行，请将第一个 my-dir 调用的值保存到另一个变量中。例如：

MY_LOCAL_PATH := $(call my-dir)

    LOCAL_PATH := $(MY_LOCAL_PATH)

    # ... declare one module

    include $(LOCAL_PATH)/foo/`Android.mk`

    LOCAL_PATH := $(MY_LOCAL_PATH)

    # ... declare another module
    

all-subdir-makefiles

返回位于当前 my-dir 路径所有子目录中的 Android.mk 文件列表。

利用此函数，您可以为编译系统提供深度嵌套的源目录层次结构。默认情况下，NDK 只在 Android.mk 文件所在的目录中查找文件。

this-makefile

返回当前 makefile（编译系统从中调用函数）的路径。

parent-makefile

返回包含树中父 makefile 的路径（包含当前 makefile 的 makefile 的路径）。

grand-parent-makefile

返回包含树中祖父 makefile 的路径（包含当前父 makefile 的 makefile 的路径）。

import-module

此函数用于按模块名称查找和包含模块的 Android.mk 文件。典型的示例如下所示：

$(call import-module,<name>)
    

在此示例中，编译系统在 NDK_MODULE_PATH 环境变量所引用的目录列表中查找具有  标记的模块，并且自动包含其 Android.mk 文件。