Android.mk file syntax specification
Android.mk 文件语法规范
Introduction:
简介：
-------------
This document describes the syntax of Android.mk build file
written to describe your C and C++ source files to the Android
NDK. To understand what follows, it is assumed that you have
read the docs/OVERVIEW.html file that explains their role and
usage.
这份文档描述了 Android.mk 生成文件的语法向 Android NDK 描述你的 C 和 C++ 源文件。
理解下面内容，假设你已经读过 docs/OVERVIEW.html
(http://wzhnsc.blogspot.com/2011/04/android-ndk-rb5.html) 文件，清楚它们的作用和用法。
Overview:
概述：
---------
An Android.mk file is written to describe your sources to the
build system. More specifically:
编写一个 Android.mk 文件向生成系统描述你的源文件。更具体地说：
- The file is really a tiny GNU Makefile fragment that will be
parsed one or more times by the build system. As such, you
should try to minimize the variables you declare there and
do not assume that anything is not defined during parsing.
- Android.mk 文件实际上是一个极小的 GNU Makefile 片断部分，将被生成系统分析一或多次。
就其本身而论，你将试着减少你声明在那里的变量并且不要假设在分析期间没有定义任何东西。
- The file syntax is designed to allow you to group your
sources into 'modules'. A module is one of the following:
- Android.mk 文件语法是已经设计成允许你把你的源文件分组到模块。
一个模块是下述的一个：
- a static library
- 一个静态库
- a shared library
- 一个共享库
Only shared libraries will be installed/copied to your
application package. Static libraries can be used to generate
shared libraries though.
只有共享库将安装或拷贝到你的应用程序包。然而静态库可以是用来产生共享库。
You can define one or more modules in each Android.mk file,
and you can use the same source file in several modules.
你可以定义一个或多个模块在每个 Android.mk 文件中，并且你可以在几个模块中使用相同的源文件。
- The build system handles many details for you. For example, you
don't need to list header files or explicit dependencies between
generated files in your Android.mk. The NDK build system will
compute these automatically for you.
- 生成系统为你处理许多细节。
例如,你不需要在产生文件之间在你的 Android.mk 文件中列出头文件或明确依赖关系。
NDK 生成系统将自动地为你估算这些。
This also means that, when updating to newer releases of the NDK,
you should be able to benefit from new toolchain/platform support
without having to touch your Android.mk files.
这同样意味着当更新较新的 NDK 发布版时，你将从新工具链或平台支持中受益而不损坏你的 Android.mk 文件。
Note that the syntax is *very* close to the one used in Android.mk files
distributed with the full open-source Android platform sources. While
the build system implementation that uses them is different, this is
an intentional design decision made to allow reuse of 'external' libraries'
source code easier for application developers.
注意：在随完全开源的 Android 平台源文件发布的 Android.mk 文件中静态库与共享库使用的语法是非常接近的。
虽然生成系统实现使用它们是不同的，这是一个故意的设计决定，
允许应用程序开发者们更容易的重用外部库源文件。
Simple example:
简单的例子：
---------------
Before describing the syntax in details, let's consider the simple
"hello JNI" example, i.e. the files under:
在描述语法细节之前，让我们细想简单的 hello JNI 例子，也就是下面目录中的这些文件：
apps/hello-jni/project
Here, we can see:
在这里，我们可以看到：
- The 'src' directory containing the Java sources for the
sample Android project.
- src 目录包含作为例子的 Android 工程的 Java 源文件。
- The 'jni' directory containing the native source for
the sample, i.e. 'jni/hello-jni.c'
- jni 目录包含示作为例子的本机源文件，也就是 jni/hello-jni.c
This source file implements a simple shared library that
implements a native method that returns a string to the
VM application.
这个源文件实现了一个简单的共享库，实现了一个本机方法为虚拟机应用程序返回一个字符串。
- The 'jni/Android.mk' file that describes the shared library
to the NDK build system. Its content is:
- jni/Android.mk 文件为 NDK 生成系统描述共享库。它的内容是：
---------- cut here ------------------
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := hello-jni
LOCAL_SRC_FILES := hello-jni.c
include $(BUILD_SHARED_LIBRARY)
---------- cut here ------------------
Now, let's explain these lines:
现在，让我们解释这些行：
LOCAL_PATH := $(call my-dir)
An Android.mk file must begin with the definition of the LOCAL_PATH variable.
It is used to locate source files in the development tree. In this example,
the macro function 'my-dir', provided by the build system, is used to return
the path of the current directory (i.e. the directory containing the
Android.mk file itself).
一个 Android.mk 文件必须从 LOCAL_PATH 变量定义开始。
它是用于在开发树中找出源文件。
在这个例子中，宏函数 my-dir ，由生成系统已提供的，是用于返回当前目录的路径。
(也就是包含 Android.mk 文件的目录的自身路径)
include $(CLEAR_VARS)
The CLEAR_VARS variable is provided by the build system and points to a
special GNU Makefile that will clear many LOCAL_XXX variables for you
(e.g. LOCAL_MODULE, LOCAL_SRC_FILES, LOCAL_STATIC_LIBRARIES, etc...),
with the exception of LOCAL_PATH. This is needed because all build
control files are parsed in a single GNU Make execution context where
all variables are global.
CLEAR_VARS 变量是由生成系统已提供的，
并且指出一个特殊的 GNU Makefile 文件将为你清除除了 LOCAL_PATH 以外的许多的 LOCAL_XXX 变量，
(例如：LOCAL_MODULE, LOCAL_SRC_FILES, LOCAL_STATIC_LIBRARIES,等等...)
这是必须的，因为全部的生成控制文件是在一个单独的 GNU Make 执行环境中被分析的，在那里所有的变量是全局的。
LOCAL_MODULE := hello-jni
The LOCAL_MODULE variable must be defined to identify each module you
describe in your Android.mk. The name must be *unique* and not contain
any spaces. Note that the build system will automatically add proper
prefix and suffix to the corresponding generated file. In other words,
a shared library module named 'foo' will generate 'libfoo.so'.
LOCAL_MODULE 变量必须是已定义的，用来标识你的 Android.mk 文件中描述的每个模块。
模块名字必须是唯一，并且不能包含任何的空格。
注意生成系统将自动添加适当的前缀和后缀到相应的产生文件。
换句话说，一个共享库模块命名为 foo 将产生 libfoo.so 。
IMPORTANT NOTE:
If you name your module 'libfoo', the build system will not
add another 'lib' prefix and will generate libfoo.so as well.
This is to support Android.mk files that originate from the
Android platform sources, would you need to use these.
重点提示：
如果你命名你的模块 libfoo ，生成系统将不再添加 lib 前缀并且将同样产生 libfoo.so 。
这是源于 Android 平台源文件对 Android.mk 文件的支持，你将需要使用这些。
LOCAL_SRC_FILES := hello-jni.c
The LOCAL_SRC_FILES variables must contain a list of C and/or C++ source
files that will be built and assembled into a module. Note that you should
not list header and included files here, because the build system will
compute dependencies automatically for you; just list the source files
that will be passed directly to a compiler, and you should be good.
LOCAL_SRC_FILES 变量必须包含将生成且汇编成一个模块的 C 和/或 C++ 源文件的列表。
注意你将不列出头文件和包含文件在这里，因为生成系统将自动地为你估算依赖；
刚才列出的源文件将直接递给编译器，所以你得到好处。
Note that the default extension for C++ source files is '.cpp'. It is
however possible to specify a different one by defining the variable
LOCAL_CPP_EXTENSION. Don't forget the initial dot (i.e. '.cxx' will
work, but not 'cxx').
注意 C++ 源文件默认扩展名是 .cpp。
然而通过定义变量 LOCAL_CPP_EXTENSION 可以具体指定一个不同的扩展名。
不要忘记扩展名开头的点(也就是 .cxx 将有效，但不是 cxx)。
include $(BUILD_SHARED_LIBRARY)
The BUILD_SHARED_LIBRARY is a variable provided by the build system that
points to a GNU Makefile script that is in charge of collecting all the
information you defined in LOCAL_XXX variables since the latest
'include $(CLEAR_VARS)' and determine what to build, and how to do it
exactly. There is also BUILD_STATIC_LIBRARY to generate a static library.
BUILD_SHARED_LIBRARY 是一个已由生成系统提供的变量，
表明一个 GNU Makefile 脚本是负责收集你定义的从最近的 include $(CLEAR_VARS) 并决定去生成以来的 LOCAL_XXX 变量的全部信息，
然后正确地生成。
BUILD_STATIC_LIBRARY 同样地产生一个静态库。
There are more complex examples in the samples directories, with commented
Android.mk files that you can look at.
这是更多复杂的例子在这个示例目录中，你可以研究带注释的 Android.mk 文件。
Reference:
参考：
----------
This is the list of variables you should either rely on or define in
an Android.mk. You can define other variables for your own usage, but
the NDK build system reserves the following variable names:
这是你将二者选一信赖或定义在一个 Android.mk 文件中的变量列表。
你可以定义为你自己使用的其它变量，但是 NDK 生成系统保留如下变量名：
- names that begin with LOCAL_ (e.g. LOCAL_MODULE)
- 以 LOCAL_ 开头的名字 (例如：LOCAL_MODULE)
- names that begin with PRIVATE_, NDK_ or APP_ (used internally)
- 以 PRIVATE_ 、NDK_ 或 APP_ 开头的名字 (内部使用)
- lower-case names (used internally, e.g. 'my-dir')
- 小写字母的名字 (内部使用，例如：'my-dir')
If you need to define your own convenience variables in an Android.mk
file, we recommend using the MY_ prefix, for a trivial example:
如果你需要在一个 Android.mk 文件中定义你自己的有用变量，
我们推荐使用 MY_ 前缀，适合于一个普通的例子：
---------- cut here ------------------
MY_SOURCES := foo.c
ifneq ($(MY_CONFIG_BAR),)
MY_SOURCES += bar.c
endif
LOCAL_SRC_FILES += $(MY_SOURCES)
---------- cut here ------------------
So, here we go:
那么，让我们开始：
NDK-provided variables:
NDK 提供的变量：
- - - - - - - - - - - -
These GNU Make variables are defined by the build system before
your Android.mk file is parsed. Note that under certain circumstances
the NDK might parse your Android.mk several times, each with different
definition for some of these variables.
这些 GNU Make 变量是被生成系统已定义了在分析你的 Android.mk 文件之前。
注意在某种情况下 NDK 可能分析你的 Android.mk 数次，每次这些变量的有些定义是不同的。
CLEAR_VARS
Points to a build script that undefines nearly all LOCAL_XXX variables
listed in the "Module-description" section below. You must include
the script before starting a new module, e.g.:
指向一个在 Module-description 段下列出未定义的几乎全部 LOCAL_XXX 变量的生成脚本。
你必须在开始一个新模块之前包含这个脚本，例如：
include $(CLEAR_VARS)
BUILD_SHARED_LIBRARY
Points to a build script that collects all the information about the
module you provided in LOCAL_XXX variables and determines how to build
a target shared library from the sources you listed. Note that you
must have LOCAL_MODULE and LOCAL_SRC_FILES defined, at a minimum before
including this file. Example usage:
指向一个收集你提供的模块全部信息的生成脚本，
按 LOCAL_XXX 变量接着决定如何从你列出的源文件来生成一个目标共享库。
注意你必须在包含这个文件之前最近位置有 LOCAL_MODULE 或 LOCAL_SRC_FILES 变量的定义，
(在如下语句之前紧挨着定义)，用法：
include $(BUILD_SHARED_LIBRARY)
note that this will generate a file named lib$(LOCAL_MODULE).so
注意这将产生一个名为 lib$(LOCAL_MODULE).so 的文件
BUILD_STATIC_LIBRARY
A variant of BUILD_SHARED_LIBRARY that is used to build a target static
library instead. Static libraries are not copied into your
project/packages but can be used to build shared libraries (see
LOCAL_STATIC_LIBRARIES and LOCAL_STATIC_WHOLE_LIBRARIES described below).
Example usage:
BUILD_SHARED_LIBRARY 的一个变种是用来生成一个目标静态库。
静态库是不会拷贝进你的 工程/包 目录中的，但是可以使用到生成共享库。
( 看在下面的 LOCAL_STATIC_LIBRARIES 和 LOCAL_STATIC_WHOLE_LIBRARIES 描述 )
用法：
include $(BUILD_STATIC_LIBRARY)
Note that this will generate a file named lib$(LOCAL_MODULE).a
注意这将产生一个名为 lib$(LOCAL_MODULE).a 的文件
PREBUILT_SHARED_LIBRARY
Points to a build script used to specify a prebuilt shared library.
Unlike BUILD_SHARED_LIBRARY and BUILD_STATIC_LIBRARY, the value
of LOCAL_SRC_FILES must be a single path to a prebuilt shared
library (e.g. foo/libfoo.so), instead of a source file.
指向一个生成脚本用于确切说明一个预编译共享库。
和 BUILD_SHARED_LIBRARY 与 BUILD_STATIC_LIBRARY 不同，
LOCAL_SRC_FILES 的值对于一个预编译共享库必须是一个单一路径(例如：foo/libfoo.so)，
而不是一个源文件。
You can reference the prebuilt library in another module using
the LOCAL_PREBUILTS variable (see docs/PREBUILTS.html for more
information).
你可以在其它模块中使用 LOCAL_PREBUILTS 变量引用预编译库。
(看 docs/PREBUILTS.html 提供的更多信息)
PREBUILT_STATIC_LIBRARY
This is the same as PREBUILT_SHARED_LIBRARY, but for a static library
file instead. See docs/PREBUILTS.html for more.
这是与 PREBUILT_SHARED_LIBRARY 一样的，只是适合于一个静态库文件。
见 docs/PREBUILTS.html 更多信息。
TARGET_ARCH
Name of the target CPU architecture as it is specified by the
full Android open-source build. This is 'arm' for any ARM-compatible
build, independent of the CPU architecture revision.
由完整的 Android 开源版本明确规定的目标 CPU 体系结构名。
如 arm 适合于任何与 ARM 相兼容的版本，独立于 CPU 体系结构修订版。
TARGET_PLATFORM
Name of the target Android platform when this Android.mk is parsed.
For example, 'android-3' correspond to Android 1.5 system images. For
a complete list of platform names and corresponding Android system
images, read docs/STABLE-APIS.html.
当这个 Android.mk 是已分析过时的目标 Android 平台名。
例如：android-3 与 Android 1.5 系统映像 相对应。
阅读 docs/STABLE-APIS.html 了解一个完整的平台名与对应的 Android 系统映像列表。
注：$ cd ~/android-sdk-linux_x86/tools <-- 进入 android-sdk-linux_x86/tools 目录下
$ ./android list targets <-- 查询当前可用的模拟器类型(平台名与对应映像信息)及所支持的显示模式
TARGET_ARCH_ABI
Name of the target CPU+ABI when this Android.mk is parsed.
Two values are supported at the moment:
当这个 Android.mk 是已分析过时的目标 CPU+ABI 名。
目前支持两个值：
armeabi
For Armv5TE
armeabi-v7a
NOTE: Up to Android NDK 1.6_r1, this variable was simply defined
as 'arm'. However, the value has been redefined to better
match what is used internally by the Android platform.
注意：一直到 Android NDK 1.6_r1，这个变量被简单地定义为 arm。
然而，值已经重新定义为更好的匹配被 Android 平台内部使用。
For more details about architecture ABIs and corresponding
compatibility issues, please read docs/CPU-ARCH-ABIS.html
关于体系结构 ABI 和 相应的兼容性问题的更多细节，请阅读 docs/CPU-ARCH-ABIS.html
Other target ABIs will be introduced in future releases of the NDK
and will have a different name. Note that all ARM-based ABIs will
have 'TARGET_ARCH' defined to 'arm', but may have different
'TARGET_ARCH_ABI'
其它目标 ABI 将是在 NDK 的未来发行版引入并将有一个不同的名字。
注意所有基于 ARM 的 ABI 都将会定义 TARGET_ARCH 为 arm ，
但是可以有不同的 TARGET_ARCH_ABI
TARGET_ABI
The concatenation of target platform and abi, it really is defined
as $(TARGET_PLATFORM)-$(TARGET_ARCH_ABI) and is useful when you want
to test against a specific target system image for a real device.
一连串的目标平台和 abi ，实际上是被定义为 $(TARGET_PLATFORM)-$(TARGET_ARCH_ABI)，
当你想要为一台真实设备进行反向测试一个具体的目标系统映像时是有用的。
By default, this will be 'android-3-armeabi'
默认时，这将是 android-3-armeabi
(Up to Android NDK 1.6_r1, this used to be 'android-3-arm' by default)
(一直到 Android NDK 1.6_r1，默认使用的是 android-3-arm )
TARGET_SIMULATOR
如果值为 true 说明是在模拟器里运行。
NDK-provided function macros:
NDK 提供的函数宏：
- - - - - - - - - - - - - - -
The following are GNU Make 'function' macros, and must be evaluated
by using '$(call <function>)'. They return textual information.
下面是 GNU Make 函数宏，但是必须是通过使用 $(call <function>) 评估过。
它们返回原文的信息。
my-dir
Returns the path of the last included Makefile, which typically is
the current Android.mk's directory. This is useful to define
LOCAL_PATH at the start of your Android.mk as with:
返回最后包含 Makefile 的路径，典型地是当前的 Android.mk 的目录。
这是有用的对于在你的 Android.mk 文件的开始处定义 LOCAL_PATH 变量 ，正如：
LOCAL_PATH := $(call my-dir)
IMPORTANT NOTE: Due to the way GNU Make works, this really returns
the path of the *last* *included* *Makefile* during the parsing of
build scripts. Do not call my-dir after including another file.
重要提示：由于 GNU Make 工作方式，这实际上返回最后包含 Makefile 文件的路径在生成脚本的分析期间。
不要在包含其它文件之后调用 my-dir。
For example, consider the following example:
例如，考虑如下例子：
LOCAL_PATH := $(call my-dir)
... declare one module
... 声明一个模块
include $(LOCAL_PATH)/foo/Android.mk
LOCAL_PATH := $(call my-dir)
... declare another module
... 声明其它模块
The problem here is that the second call to 'my-dir' will define
LOCAL_PATH to $PATH/foo instead of $PATH, due to the include that
was performed before that.
这里的问题是第二次调用 my-dir 将定义 LOCAL_PATH 变量为 $PATH/foo 目录而不是 $PATH 目录的路径，
因为包含语句是完成在第二次定义变量之前。
For this reason, it's better to put additional includes after
everything else in an Android.mk, as in:
由于这个原因，最好在一个 Android.mk 文件的最后放置额外的包含语句，如：
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
include $(LOCAL_PATH)/foo/Android.mk
If this is not convenient, save the value of the first my-dir call
into another variable, for example:
如果这不是方便地，保存第一个 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
Returns a list of Android.mk located in all sub-directories of
the current 'my-dir' path. For example, consider the following
hierarchy:
返回一个位于当前 my-dir 路径下的所有子目录中的 Android.mk 文件的列表。
例如，考虑以下的层次：
sources/foo/Android.mk
sources/foo/lib1/Android.mk
sources/foo/lib2/Android.mk
If sources/foo/Android.mk contains the single line:
如果 sources/foo/Android.mk 包含如下一行：
include $(call all-subdir-makefiles)
Then it will include automatically sources/foo/lib1/Android.mk and
sources/foo/lib2/Android.mk
那么它将自动地包含 sources/foo/lib1/Android.mk 和 sources/foo/lib2/Android.mk
This function can be used to provide deep-nested source directory
hierarchies to the build system. Note that by default, the NDK
will only look for files in sourcesAndroid.mk 文件
this-makefile
Returns the path of the current Makefile (i.e. where the function
is called).
返回当前 Makefile 文件的路径(也就是调用该函数的 Makefile的路径)。
parent-makefile
Returns the path of the parent Makefile in the inclusion tree,
i.e. the path of the Makefile that included the current one.
返回在包含树中父 Makefile 文件的路径，
也就是包含当前 Makefile 文件的 Makefile 文件的路径。
grand-parent-makefile
Guess what...
猜猜看...
import-module
A function that allows you to find and include the Android.mk
of another module by name. A typical example is:
允许你通过名字查找且包含其它模块的 Android.mk 文件。
典型例子是：
$(call import-module,<name>)
And this will look for the module tagged <name> in the list of
directories referenced by your NDK_MODULE_PATH environment
variable, and include its Android.mk automatically for you.
这将在你的 NDK_MODULE_PATH 环境变量提到的目录列表中查找模块标记的名字，
并自动地为你包含它的 Android.mk 文件。
Read docs/IMPORT-MODULE.html for more details.
阅读 docs/IMPORT-MODULE.html 得到更多细节。
Module-description variables:
模块描述变量：
- - - - - - - - - - - - - - -
The following variables are used to describe your module to the build
system. You should define some of them between an 'include $(CLEAR_VARS)'
and an 'include $(BUILD_XXXXX)'. As written previously, $(CLEAR_VARS) is
a script that will undefine/clear all of these variables, unless explicitly
noted in their description.
下面的变量是用来为生成系统描述你的模块。
你将在 include $(CLEAR_VARS) 和 include $(BUILD_XXXXX) 之间定义它们的某些变量。
正如之前所写，$(CLEAR_VARS) 是一个将解定义或清除全部这些变量的脚本，除非明确地在它们的描述中注明。
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, which can
be done with:
这个变量是用于提供当前文件的路径。
你必须定义它在你的 Android.mk 文件开始处，以如下形式：
LOCAL_PATH := $(call my-dir)
This variable is *not* cleared by $(CLEAR_VARS) so only one
definition per Android.mk is needed (in case you define several
modules in a single file).
这个变量是不被 $(CLEAR_VARS) 清除的，因此每个 Android.mk 文件仅需要一个定义。
(以防你在单一文件中定义数个模块)
LOCAL_MODULE
This is the name of your module. It must be unique among all
module names, and shall not contain any space. You MUST define
it before including any $(BUILD_XXXX) script.
这是你的模块名字。
它必须在全部模块名中是独一无二的，并且将不包含任何的空格。
你必须在包含无论哪一个 $(BUILD_XXXX) 脚本之前定义它。
By default, the module name determines the name of generated files,
e.g. lib<foo>.so for a shared library module named <foo>. However
you should only refer to other modules with their 'normal'
name (e.g. <foo>) in your NDK build files (either Android.mk
or Application.mk)
默认情况下，模块名决定产生的文件的名字，例如：lib<foo>.so 是因为一个共享库模块被命名为 <foo> 。
不管怎么样，你将只在你的 NDK 生成文件(Android.mk 或 Application.mk 两者中的任何一个)中，
用普通名字来涉及其它模块(例如：<foo>)。
You can override this default with LOCAL_MODULE_FILENAME (see below)
你可以用 LOCAL_MODULE_FILENAME 替代默认情况(看下面)
LOCAL_MODULE_FILENAME
This variable is optional, and allows you to redefine the name of
generated files. By default, module <foo> will always generate a
static library named lib<foo>.a or a shared library named lib<foo>.so,
which are standard Unix conventions.
这个变量是可选的，允许你重定义产生文件的名字。
默认情况下，模块 <foo> 将一直按标准 Unix 协定产生一个名为 lib<foo>.a 的静态库，
或一个名为 lib<foo>.so 的共享库。
You can override this by defining LOCAL_MODULE_FILENAME, For example:
你可以通过定义 LOCAL_MODULE_FILENAME 替代这个默认情况，例如：
LOCAL_MODULE := foo-version-1
LOCAL_MODULE_FILENAME := libfoo
NOTE: You should not put a path or file extension in your
LOCAL_MODULE_FILENAME, these will be handled automatically by the
build system.
注意：你不用给 LOCAL_MODULE_FILENAME 变量一个带有路径或文件扩展名的值，
这些将由生成系统自动地处理。
LOCAL_MODULE_TAGS
下面给出其它选项简介：
LOCAL_MODULE_TAGS ：=user eng tests optional
user 指该模块只在user版本下才编译
eng 指该模块只在eng版本下才编译
tests 指该模块只在tests版本下才编译
optional 指该模块在所有版本下都编译
optional 这个选项有问题，虽说 optional 表示在所有版本都可以编译，
但是 LOCAL_MODULE_TAGS 变量跟 TARGET_BUILD_VARIANT 变量息息相关。
LOCAL_SRC_FILES
This is a list of source files that will be built for your module.
Only list the files that will be passed to a compiler, since the
build system automatically computes dependencies for you.
这是一个将用于生成你模块的源文件的列表。
只列出将被传递给编译器的文件，因为生成系统自动地为你估算信赖。
Note that source files names are all relative to LOCAL_PATH and
you can use path components, e.g.:
注意源文件名是全部相对于 LOCAL_PATH 而且你可以使用路径部分，例如：
LOCAL_SRC_FILES := foo.c \
toto/bar.c
NOTE: Always use Unix-style forward slashes (/) in build files.
Windows-style back-slashes will not be handled properly.
注意：在生成文件中一直使用 Unix 风格的向前的斜线号(/)。
Windows 风格的向后斜线号将不能正确地处理。
LOCAL_CPP_EXTENSION
This is an optional variable that can be defined to indicate
the file extension of C++ source files. The default is '.cpp'
but you can change it. For example:
这是一个可选变量，可以定义指出 C++ 源文件的文件扩展名。
默认是 .cpp ，但是你可以改变它。例如：
LOCAL_CPP_EXTENSION := .cxx
LOCAL_C_INCLUDES
An optional list of paths, relative to the NDK *root* directory,
which will be appended to the include search path when compiling
all sources (C, C++ and Assembly). For example:
一个可选的路径列表，相对于 NDK 根目录，当编译全部源文件（C，C++ 和 汇编）时添加到 include 搜索路中。例如：
LOCAL_C_INCLUDES := sources/foo
Or even:
乃至：
LOCAL_C_INCLUDES := $(LOCAL_PATH)/../foo
These are placed before any corresponding inclusion flag in
LOCAL_CFLAGS / LOCAL_CPPFLAGS
这些是放置在 LOCAL_CFLAGS 或 LOCAL_CPPFLAGS 无论哪个包含标志之前
The LOCAL_C_INCLUDES path are also used automatically when
launching native debugging with ndk-gdb.
当用 ndk-gdb 本地调试时 LOCAL_C_INCLUDES 路径是同样地自动地被使用。
LOCAL_CFLAGS
An optional set of compiler flags that will be passed when building
C *and* C++ source files.
一组可选的编译器标志当编译 C 和 C++ 源文件时将是被传达。
This can be useful to specify additional macro definitions or
compile options.
这对具体指定附加宏定义或编译选项可是有用的。
IMPORTANT: Try not to change the optimization/debugging level in
your Android.mk, this can be handled automatically for
you by specifying the appropriate information in
your Application.mk, and will let the NDK generate
useful data files used during debugging.
重点：尽量不要在你的 Android.mk 文件中去改变优化或调试级别，
这可以凭借在你的 Application.mk 文件中具体指出的恰当的信息自动地为你处理，
并将让 NDK 产生使用在调试期间有用的数据文件。
NOTE: In android-ndk-1.5_r1, the corresponding flags only applied
to C source files, not C++ ones. This has been corrected to
match the full Android build system behaviour. (You can use
LOCAL_CPPFLAGS to specify flags for C++ sources only now).
注意：在 android-ndk-1.5_r1 中，相应的标志仅适于 C 源文件，没有 C++ 一个。
这个已经纠正来直接地匹配 Android 生成系统行为。
(现在你可以使用 LOCAL_CPPFLAGS 去为 C++ 源文件具体指定标志)
It is possible to specify additional include paths with
LOCAL_CFLAGS += -I<path>, however, it is better to use LOCAL_C_INCLUDES
for this, since the paths will then also be used during native
debugging with ndk-gdb.
用 LOCAL_CFLAGS += -I<path> 可指定额外的 include 路径，
可是最好使用 LOCAL_C_INCLUDES 来做这事，
因为该路径以后同样使用在用 ndk-gdb 本地调试期间。
例如：LOCAL_CFLAGS += -DDEBUG 这个相当于在头文件中出现了：#define DEBUG
LOCAL_CXXFLAGS
An alias for LOCAL_CPPFLAGS. Note that use of this flag is obsolete
as it may disappear in future releases of the NDK.
LOCAL_CPPFLAGS 的一个化名。
注意这个标志的使用是过时的，因为它可能在未来的 NDK 发行版中消失。
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.
一组可选的编译器标志当仅仅生成 C++ 源文件时将被传递。
它们将出现在编译器的命令行 LOCAL_CFLAGS 之后。
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. (You can use LOCAL_CFLAGS to specify
flags for both C and C++ sources now).
注意：在 android-ndk-1.5_r1 中，相应的标志对 C 和 C++ 源文件两个都适用。
这已经被纠正来直接地匹配 Android 生成系统。
(你可以使用 LOCAL_CFLAGS 来为 C 和 C++ 源文件两个去具体指定标志)
LOCAL_STATIC_LIBRARIES
The list of static libraries modules (built with BUILD_STATIC_LIBRARY)
that should be linked to this module. This only makes sense in
shared library modules.
将链接到本模块的静态库模块列表(用 BUILD_STATIC_LIBRARY 生成的)。
这仅在共享库模块中有意义。
LOCAL_SHARED_LIBRARIES
The list of shared libraries *modules* this module depends on at runtime.
This is necessary at link time and to embed the corresponding information
in the generated file.
本模块运行时依赖的共享库模块列表。
在产生文件连接时嵌入相应的信息是必需的。
LOCAL_LDLIBS
The list of additional linker flags to be used when building your
module. This is useful to pass the name of specific system libraries
with the "-l" prefix. For example, the following will tell the linker
to generate a module that links to /system/lib/libz.so at load time:
使用在生成你的模块时的额外的链接器标志列表。
用 -l 前缀传递特定的系统库名是有用的。
例如，如下将告诉链接器产生一个模块，在它加载时与 /system/lib/libz.so 连接起来：
LOCAL_LDLIBS := -lz
See docs/STABLE-APIS.html for the list of exposed system libraries you
can linked against with this NDK release.
参见 docs/STABLE-APIS.html 中对照本 NDK 发布版你可以链接的公开系统库的列表。
为了让 C 语言编译的时候引入相关的库文件，则在 Android.mk 中写入，例如：
LOCAL_LDLIBS := -llog
这样，我们可以调用 liblog.so 共享库中提供的函数。
一般这些共享库在 Android 系统的 /system/lib 目录下。
LOCAL_LDLIBS 与 LOCAL_SHARED_LIBRARIES的区别：
如果在 Android.mk 文件中出现了，例如：
LOCAL_LDLIBS := -lGLESv2
则 libGLESv2.so 共享库将不再被编译，一般这种共享库由系统提供。
但是，如果在 Android.mk 文件中出现了，例如：
LOCAL_SHARED_LIBRARIES := libGLESv2
这时候任何和 libGLESv2.so 有关联的改动都将造成共享库的重新编译，
这种情况比较适合导入个人共享库的场景。
LOCAL_ALLOW_UNDEFINED_SYMBOLS
By default, any undefined reference encountered when trying to build
a shared library will result in an "undefined symbol" error. This is a
great help to catch bugs in your source code.
默认情况下，在试图生成一个共享库时任何未定义引用都会引起一个 "未定义符号" 错误。
这是一个在你源代码中捕捉错误的极好帮助。
However, if for some reason you need to disable this check, set this
variable to 'true'. Note that the corresponding shared library may fail
to load at runtime.
然而，如果出于一些原因你需要禁止这个检查，设置这个变量值为 true 。
注意相应的共享库可能在运行时加载失败。
LOCAL_ARM_MODE
By default, ARM target binaries will be generated in 'thumb' mode, where
each instruction are 16-bit wide. You can define this variable to 'arm'
if you want to force the generation of the module's object files in
'arm' (32-bit instructions) mode. E.g.:
默认情况下，ARM 目标二进制代码将是用 thumb 模式产生的，每个指令是16位宽。
如果你想要强制产生的模块对象文件用 arm 模式(32位指令)的话，你可以定义这个变量值为 arm 。例如：
LOCAL_ARM_MODE := arm
Note that you can also instruct the build system to only build specific
sources in arm mode by appending an '.arm' suffix to its source file
name. For example, with:
注意你同样可以命令生成系统用 arm 模式仅生成特定的源文件，通过附加一个 .arm 后缀到特定的源文件名。
例如，使用：
LOCAL_SRC_FILES := foo.c bar.c.arm
Tells the build system to always compile 'bar.c' in arm mode, and to
build foo.c according to the value of LOCAL_ARM_MODE.
告诉生成系统一直用 arm 模式编译 bar.c ，并且生成 foo.c 依照 LOCAL_ARM_MODE 的值。
NOTE: Setting APP_OPTIM to 'debug' in your Application.mk will also force
the generation of ARM binaries as well. This is due to bugs in the
toolchain debugger that don't deal too well with thumb code.
注意：在你的 Application.mk 文件中设置 APP_OPTIM 的值为 debug 将同样强制 ARM 二进制代码的产生。
这是由于故障在工具链调试程序中用 thumb 代码不太好处理。
LOCAL_ARM_NEON
Defining this variable to 'true' allows the use of ARM Advanced SIMD
(a.k.a. NEON) GCC intrinsics in your C and C++ sources, as well as
NEON instructions in Assembly files.
定义这个变量值为 true 允许在你的 C 和 C++ 源文件中使用 ARM 高级的 SIMD (又叫做 NEON) GCC 内联函数，
和 NEON 指令在汇编代码文件中一样。
You should only define it when targetting the 'armeabi-v7a' ABI that
corresponds to the ARMv7 instruction set. Note that not all ARMv7
based CPUs support the NEON instruction set extensions and that you
should perform runtime detection to be able to use this code at runtime
safely. To learn more about this, please read the documentation at
docs/CPU-ARM-NEON.html and docs/CPU-FEATURES.html.
你将仅仅定义它在把 armeabi-v7a 作为目标 ABI 时，与 ARMv7 指令集相对应。
注意并非全部的 ARMv7 基础型 CPU 都支持 NEON 指令集扩展，
而且对于在运行时安全地使用该代码你应该执行运行时检测。
要了解更多，请阅读 docs/CPU-ARM-NEON.html 和 docs/CPU-FEATURES.html 文档。
Alternatively, you can also specify that only specific source files
may be compiled with NEON support by using the '.neon' suffix, as in:
或者，你可以同样具体说明仅特定的源文件可以是支持 NEON 编译的，通过使用 .neon 后缀，如：
LOCAL_SRC_FILES = foo.c.neon bar.c zoo.c.arm.neon
In this example, 'foo.c' will be compiled in thumb+neon mode,
'bar.c' will be compiled in 'thumb' mode, and 'zoo.c' will be
compiled in 'arm+neon' mode.
在这个例子中，foo.c 将用 thumb 加 neon 模式编译，bar.c 将用 thumb 模式编译，
并且 zoo.c 将是用 arm 加 neon 模式编译。
Note that the '.neon' suffix must appear after the '.arm' suffix
if you use both (i.e. foo.c.arm.neon works, but not foo.c.neon.arm !)
注意如果 .arm 和 .neon 两个你都要使用的话，.neon 后缀必须出现在 .arm 后缀之后。
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 if you *really*
need to by setting this variable to 'true'.
Android NDK r4 添加 NX bit 安全功能支持。
该功能默认是启用的，但如果你的确需要你可以禁用它，通过设置本变量的值为 true 。
NOTE: This feature does not modify the ABI and is only enabled on
kernels targetting ARMv6+ CPU devices. Machine code generated
with this feature enabled will run unmodified on devices
running earlier CPU architectures.
注意：这个功能不能修改 ABI 并且是仅在内核把 ARMv6+ CPU 作为目标设备上启用。
这个功能开启后产生的机器码将不被修改的运行在设备上，运行在早期的 CPU 体系结构。
For more information, see:
更多信息，看：
http://en.wikipedia.org/wiki/NX_bit
http://www.gentoo.org/proj/en/hardened/gnu-stack.xml
LOCAL_EXPORT_CFLAGS
Define this variable to record a set of C/C++ compiler flags that will
be added to the LOCAL_CFLAGS definition of any other module that uses
this one with LOCAL_STATIC_LIBRARIES or LOCAL_SHARED_LIBRARIES.
定义这个变量来记录一组 C 或 C++ 编译器标志，
将是被加入到使用 LOCAL_STATIC_LIBRARIES 或 LOCAL_SHARED_LIBRARIES 的任何其它模块的 LOCAL_CFLAGS 变量定义中。
For example, consider the module 'foo' with the following definition:
例如，用如下定义考虑模块 foo ：
include $(CLEAR_VARS)
LOCAL_MODULE := foo
LOCAL_SRC_FILES := foo/foo.c
LOCAL_EXPORT_CFLAGS := -DFOO=1
include $(BUILD_STATIC_LIBRARY)
And another module, named 'bar' that depends on it as:
和另一个名为 bar 的模块依赖于它：
include $(CLEAR_VARS)
LOCAL_MODULE := bar
LOCAL_SRC_FILES := bar.c
LOCAL_CFLAGS := -DBAR=2
LOCAL_STATIC_LIBRARIES := foo
include $(BUILD_SHARED_LIBRARY)
Then, the flags '-DFOO=1 -DBAR=2' will be passed to the compiler when building bar.c
于是，在生成 bar.c 时标志 -DFOO=1 -DBAR=2 将被传递给了编译器
Exported flags are prepended to your module's LOCAL_CFLAGS so you can
easily override them. They are also transitive: if 'zoo' depends on
'bar' which depends on 'foo', then 'zoo' will also inherit all flags
exported by 'foo'.
导出的标志是被添加到你的模块的 LOCAL_CFLAGS 变量值之前，所以你可以容易地覆盖它们。
它们同样是可转变的：如果 zoo 信赖于 bar ,而 bar 信赖于 foo ，
那么 zoo 将同样继承 foo 导出的全部标志。
Finally, exported flags are *not* used when building the module that
exports them. In the above example, -DFOO=1 would not be passed to the
compiler when building foo/foo.c.
最后，在生成 foo 模块时导出的标志是不使用的。
在这个例子上，当生成 foo/foo.c 时 -DFOO=1 将不能传递给编译。
LOCAL_EXPORT_CPPFLAGS
Same as LOCAL_EXPORT_CFLAGS, but for C++ flags only.
类似于 LOCAL_EXPORT_CFLAGS 变量，仅仅只适合于 C++ 标志。
LOCAL_EXPORT_C_INCLUDES
Same as LOCAL_EXPORT_CFLAGS, but for C include paths.
This can be useful if 'bar.c' wants to include headers
that are provided by module 'foo'.
类似于 LOCAL_EXPORT_CFLAGS 变量，只适合于 C 包含路径。
如果 bar.c 想要包含由 foo 模块提供的头文件的话，这可是有用的。
LOCAL_EXPORT_LDLIBS
Same as LOCAL_EXPORT_CFLAGS, but for linker flags. Note that the
imported linker flags will be appended to your module's LOCAL_LDLIBS
though, due to the way Unix linkers work.
类似于 LOCAL_EXPORT_CFLAGS 变量，只适合于链接器标志。
注意导入的链接器标志不过将附加到你模块的 LOCAL_LDLIBS 变量值中，
因为 Unix 链接器工作方式。
This is typically useful when module 'foo' is a static library and has
code that depends on a system library. LOCAL_EXPORT_LDLIBS can then be
used to export the dependency. For example:
当模块 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)
There, libbar.so will be built with a -llog at the end of the linker
command to indicate that it depends on the system logging library,
because it depends on 'foo'.
在那里，libbar.so 将在链接器命令最后用一个 -llog 来生成，指出依赖系统日志库，
因为 libbar.so 依赖于 foo 静态库。
LOCAL_FILTER_ASM
Define this variable to a shell command that will be used to filter
the assembly files from, or generated from, your LOCAL_SRC_FILES.
定义这个变量用于一个 shell 命令来过滤汇编文件或来过滤你的 LOCAL_SRC_FILES 变量值中源文件产生的汇编文件。
When it is defined, the following happens:
当它是被定义时，将会发生如下过程：
- Any C or C++ source file is generated into a temporary assembly
file (instead of being compiled into an object file).
- 任何的 C 或 C++ 源文件是产生一个临时的汇编文件(而不是编译成一个目标文件)。
- Any temporary assembly file, and any assembly file listed in
LOCAL_SRC_FILES is sent through the LOCAL_FILTER_ASM command
to generate _another_ temporary assembly file.
- 任何临时的汇编文件，和 LOCAL_SRC_FILES 变量值列出的汇编文件是被通过 LOCAL_FILTER_ASM 命令产生 另一个 的临时汇编文件。
- These filtered assembly files are compiled into object file.
- 这些过滤过的汇编文件是被编译成目标文件。
In other words, If you have:
换句话说，如果你有：
LOCAL_SRC_FILES := foo.c bar.S
LOCAL_FILTER_ASM := myasmfilter
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
Were "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, as in:
1是对应的编译器，2是对应过滤器 ，3是汇编器。
过滤器必须是独立的 shell 过滤命令，接受输入文件名做为它的第一个参数，并且输出文件名做为第二个参数，如：
myasmfilter $OBJS_DIR/foo.S.original $OBJS_DIR/foo.S
myasmfilter bar.S $OBJS_DIR/bar.S
扫一扫
713
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
