https://blog.csdn.net/jcl490195138/article/details/52352522
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE_TAGS := optional
LOCAL_SRC_FILES := $(call all-java-files-under, src)
LOCAL_PACKAGE_NAME := Settings
LOCAL_CERTIFICATE := platform
include $(BUILD_PACKAGE)
# Use the folloing include to make our test apk.
include $(call all-makefiles-under,$(LOCAL_PATH)
该Android.mk文件路径是package/app/Settings/Android.mk，来分析该文件
GNU Make‘功能’宏，必须通过使用'$(call )'来调用，调用他们将返回文本化的信息。
(1) LOCAL_PATH:= $(call my-dir)
一个Android.mk file首先必须定义好LOCAL_PATH变量。它用于在开发树中查找源文件。
宏函数’my-dir’，由编译系统提供，用于返回当前路径（即包含Android.mk file文件的目录）。
------------------------------------------------------------------------------------------------------------------------------
(2) Android.mk中可以定义多个编译模块，每个编译模块都是以include $(CLEAR_VARS)开始，以include $(BUILD_XXX)结束。
(2.1) include $(CLEAR_VARS)
CLEAR_VARS指的是clear_vars.mk，由编译系统提供，它会让GNU MAKEFILE为你清除除LOCAL_PATH以外的所有LOCAL_XXX变量，如 LOCAL_MODULE，LOCAL_SRC_FILES，LOCAL_SHARED_LIBRARIES，LOCAL_STATIC_LIBRARIES 等。
这是必要的，因为所有的编译控制文件都在同一个GNU MAKE执行环境中，所有的变量都是全局的。
(2.2) include $(BUILD_PACKAGE) # Tell it to build an APK
$(BUILD_PACKAGE)是用来编译生成package/app/下的apk。
还有其他几种编译情况：
include $(BUILD_STATIC_LIBRARY) 表示编译成静态库
include $(BUILD_SHARED_LIBRARY) 表示编译成动态库
include $(BUILD_EXECUTABLE) 表示编译成可执行程序
至于例子的话，跳转到下面的"扩展"
(3) LOCAL_MODULE_TAGS := optional
解析：
LOCAL_MODULE_TAGS :=user eng tests optional
user: 指该模块只在user版本下才编译
eng: 指该模块只在eng版本下才编译
tests: 指该模块只在tests版本下才编译
optional:指该模块在所有版本下都编译
取值范围debug eng tests optional samples shell_ash shell_mksh。注意不能取值user，如果要预装，则应定义core.mk。
------------------------------------------------------------------------------------------------------------------------------
(4) LOCAL_SRC_FILES := $(call all-java-files-under, src)
(4.1) 如果要包含的是java源码的话，可以调用all-java-files-under得到。(这种形式来包含local_path目录下的所有java文件)
(4.2) 当涉及到C/C++时，LOCAL_SRC_FILES变量就必须包含将要编译打包进模块中的C或C++源代码文件。注意，在这里你可以不用列出头文件和包含文件，因为编译系统将会自动为你找出依赖型的文件；仅仅列出直接传递给编译器的源代码文件就好。
all-java-files-under宏的定义是在build/core/definitions.mk中。
------------------------------------------------------------------------------------------------------------------------------
(5) LOCAL_PACKAGE_NAME := Settings
package的名字，这个名字在脚本中将标识这个app或package。
------------------------------------------------------------------------------------------------------------------------------
(6) LOCAL_CERTIFICATE := platform
LOCAL_CERTIFICATE 后面是签名文件的文件名，说明Settings.apk是一个需要platform key签名的APK
用于指定签名时使用的KEY，如果不指定，默认使用testkey，LOCAL_CERTIFICATE可设置的值如下：
LOCAL_CERTIFICATE := platform
LOCAL_CERTIFICATE := shared
LOCAL_CERTIFICATE := media
而在Android.mk中的这些配置，需要在APK源码的AndroidManifest.xml文件中的manifest节点添加如下内容：
android:sharedUserId="android.uid.system"
android:sharedUserId="android.uid.shared"
android:sharedUserId="android.media"
这些刚好与上面的mk文件里的配置对应上。
在Android源码的build/target/product/security/目录下有如下的4对KEY：
1、media.pk8与media.x509.pem；
2、platform.pk8与platform.x509.pem；
3、shared.pk8与shared.x509.pem；
4、testkey.pk8与testkey.x509.pem；
其中，“*.pk8”文件为私钥，“*.x509.pem”文件为公钥，这需要去了解非对称加密方式。
(8) include $(call all-makefiles-under,$(LOCAL_PATH))
加载当前目录下的所有makefile文件，all-makefiles-under会返回一个位于当前'my-dir'路径的子目录中的所有Android.mk的列表。
all-makefiles-under宏的定义是在build/core/definitions.mk中。
------------------------------------------------------------------------------------------------------------------------------
这个Android.mk文件最后就生成了Settings.apk。分析完上面的Android.mk文件后，来总结下各种LOCAL_XXX。
三种情况说明：
必须定义, 在app或package的Android.mk中必须给定值。
可选定义，在app或package的Android.mk中可以也可以不给定值。
不用定义，在app或package的Android.mk中不要给定值，脚本自动指定值。
LOCAL_PATH， 当前路径，必须定义。
LOCAL_PACKAGE_NAME， 必须定义，package的名字，这个名字在脚本中将标识app或package。
LOCAL_MODULE_SUFFIX， 不用定义，module的后缀，=.apk。
LOCAL_MODULE， 不用定义，=$(LOCAL_PACKAGE_NAME)。
LOCAL_JAVA_RESOURCE_DIRS， 不用定义。
LOCAL_JAVA_RESOURCE_FILES， 不用定义。
LOCAL_MODULE_CLASS， 不用定义。
LOCAL_MODULE_TAGS， 可选定义。默认optional。取值范围user debug eng tests optional samples shell_ash shell_mksh。
LOCAL_ASSET_DIR， 可选定义，推荐不定义。默认$(LOCAL_PATH)/assets
LOCAL_RESOURCE_DIR， 可选定义，推荐不定义。默认product package和device package相应的res路径和$(LOCAL_PATH)/res。
LOCAL_PROGUARD_ENABLED， 可选定义，默认为full，如果是user或userdebug。取值full, disabled, custom。
full_android_manifest， 不用定义，=$(LOCAL_PATH)/AndroidManifest.xml。
LOCAL_EXPORT_PACKAGE_RESOURCES， 可选定义，默认null。如果允许app的资源被其它模块使用，则设置true。
LOCAL_CERTIFICATE， 可选定义，默认为testkey。最终
private_key := $(LOCAL_CERTIFICATE).pk8
certificate := $(LOCAL_CERTIFICATE).x509.pem
扩展：在一个Android.mk中可以生成多个可执行程序、动态库和静态库。
（1）编译APK应用程序模板。
关于编译APK应用程序的模板请参照《Android.mk编译APK范例》
（2）编译JAVA库模板
LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) # Build all java files in the java subdirectory LOCAL_SRC_FILES := $(call all-subdir-java-files) # Any libraries that this library depends on LOCAL_JAVA_LIBRARIES := android.test.runner # The name of the jar file to create LOCAL_MODULE := sample # Build a static jar file. include $(BUILD_STATIC_JAVA_LIBRARY)
LOCAL_JAVA_LIBRARIES := android.test.runner表示生成的JAVA库的jar文件名
编译C/C++应用程序模板如下：
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)
注：‘:=’是赋值的意思，'+='是追加的意思，‘$’表示引用某变量的值
LOCAL_SRC_FILES中加入源文件路径，LOCAL_C_INCLUDES中加入需要的头文件搜索路径 LOCAL_STATIC_LIBRARIES 加入所需要链接的静态库(*.a)的名称， LOCAL_SHARED_LIBRARIES 中加入所需要链接的动态库(*.so)的名称， LOCAL_MODULE表示模块最终的名称，BUILD_EXECUTABLE 表示以一个可执行程序的方式进行编译。
编译C\C++静态库
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)
编译C/C++动态库的模板
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)
和上面相似，BUILD_SHARED_LIBRARY 表示编译一个共享库。
以上三者的生成结果分别在如下目录中，generic 依具体 target 会变(可能是dkb~~)：
out/target/product/generic/obj/APPS out/target/product/generic/obj/JAVA_LIBRARIES out/target/product/generic/obj/EXECUTABLE out/target/product/generic/obj/STATIC_LIBRARY out/target/product/generic/obj/SHARED_LIBRARY
每个模块的目标文件夹分别为：
1）APK程序：XXX_intermediates 2）JAVA库程序：XXX_intermediates 3）C\C++可执行程序：XXX_intermediates 4）C\C++静态库： XXX_static_intermediates 5）C\C++动态库： XXX_shared_intermediates
Android.mk文件是GNU Makefile的一小部分，它用来对Android程序进行编译。
因为所有的编译文件都在同一个 GNU MAKE 执行环境中进行执行，而Android.mk中所有的变量都是全局的。因此，您应尽量少声明变量，不要认为某些变量在解析过程中不会被定义。
一个Android.mk文件可以编译多个模块，每个模块属下列类型之一：
1）APK程序
一般的Android程序，编译打包生成apk文件
2）JAVA库
java类库，编译打包生成jar文件
3)C\C++应用程序
可执行的C\C++应用程序
4）C\C++静态库
编译生成C\C++静态库，并打包成.a文件
5）C\C++共享库
编译生成共享库（动态链接库），并打包成.so文， 有且只有共享库才能被安装/复制到您的应用软件（APK）包中。
可以在每一个Android.mk file 中定义一个或多个模块，你也可以在几个模块中使用同一个
源代码文件。 编译系统为你处理许多细节问题。例如，你不需要在你的 Android.mk 中列出头文件和依
赖文件。编译系统将会为你自动处理这些问题。这也意味着，在升级 NDK 后，你应该
得到新的toolchain/platform支持，而且不需要改变你的 Android.mk 文件。
注意，NDK的Anroid.mk语法同公开发布的Android平台开源代码的Anroid.mk语法很接近，然而编译系统实现他们的
方式却是不同的，这是故意这样设计的，可以让程序开发人员重用外部库的源代码更容易。
在描述语法细节之前，咱们来看一个简单的"hello world"的例子，比如，下面的文件：
sources/helloworld/helloworld.c
sources/helloworld/Android.mk
'helloworld.c'是一个 JNI 共享库，实现返回"hello world"字符串的原生方法。相应的
Android.mk 文件会象下面这样：
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE:= helloworld
LOCAL_SRC_FILES := helloworld.c
include $(BUILD_SHARED_LIBRARY)
解释一下几行代码：
LOCAL_PATH := $(call my-dir)
一个Android.mk file首先必须定义好LOCAL_PATH变量。它表示是当前文件的路径。
在这个例子中， 宏函数‘my-dir’, 由编译系统提供， 用于返回当前路径(即包含Android.mk file
文件的目录)。
include $(CLEAR_VARS)
CLEAR_VARS 由编译系统提供(可以在 android 安装目录下的/build/core/config.mk 文件看到其定义，为 CLEAR_VARS:= $(BUILD_SYSTEM)/clear_vars.mk)，指定让GNU MAKEFILE该脚本为你清除许多 LOCAL_XXX 变量 ( 例如 LOCAL_MODULE ， LOCAL_SRC_FILES ，LOCAL_STATIC_LIBRARIES，等等…)，除 LOCAL_PATH。这是必要的，因为所有的编译文件都在同一个 GNU MAKE 执行环境中，所有的变量都是全局的。所以我们需要先清空这些变量（LOCAL_PATH除外）。又因为LOCAL_PATH总是要求在每个模块中都要进行设置，所以并需要清空它。
另外注意，该语句的意思就是把CLEAR_VARS变量所指向的脚本文件包含进来。
LOCAL_MODULE := helloworld
LOCAL_MODULE 变量必须定义，以标识你在 Android.mk 文件中描述的每个模块。名称必须是唯一的，而且不包含任何空格。注意编译系统会自动产生合适的前缀和后缀，换句话说，一个被命名为'foo'的共享库模 块，将会生成'libfoo.so'文件。
注意：如果把库命名为‘libhelloworld’，编译系统将不会添加任何的 lib 前缀，也会生成 libhelloworld.so。
LOCAL_SRC_FILES := helloworld.c
LOCAL_SRC_FILES 变量必须包含将要编译打包进模块中的 C 或 C++源代码文件。不用
在这里列出头文件和包含文件，编译系统将会自动找出依赖型的文件，当然对于包含文件，你包含时指定的路径应该正确。
注意，默认的 C++源码文件的扩展名是‘.cpp’ 。指定一个不同的扩展名也是可能的，只要定义LOCAL_DEFAULT_CPP_EXTENSION 变量，不要忘记开始的小圆点(也就是定义为 ‘.cxx’,而不是‘cxx’)
include $(BUILD_SHARED_LIBRARY)
BUILD_SHARED_LIBRARY 是编译系统提供的变量，指向一个 GNU Makefile 脚本(应该
就是在 build/core 目录下的 shared_library.mk) ，将根据LOCAL_XXX系列变量中的值，来编译生成共享库（动态链接库）。
如果想生成静态库，则用BUILD_STATIC_LIBRARY
在NDK的sources/samples目录下有更复杂一点的例子，写有注释的 Android.mk 文件。
二、自定义变量
以下是在 Android.mk中依赖或定义的变量列表， 可以定义其他变量为自己使用，但是NDK编译系统保留下列变量名：
-以 LOCAL_开头的名字（例如 LOCAL_MODULE）
-以 PRIVATE_, NDK_ 或 APP_开头的名字（内部使用）
-小写名字（内部使用，例如‘my-dir’）
如果为了方便在 Android.mk 中定义自己的变量，建议使用 MY_前缀，一个小例子：
MY_SOURCES := foo.c
ifneq ($(MY_CONFIG_BAR),)
MY_SOURCES += bar.c
endif
LOCAL_SRC_FILES += $(MY_SOURCES)
注意：‘:=’是赋值的意思；'+='是追加的意思；‘$’表示引用某变量的值。
三、GNU Make系统变量
这些 GNU Make变量在你的 Android.mk 文件解析之前，就由编译系统定义好了。注意在
某些情况下，NDK可能分析 Android.mk 几次，每一次某些变量的定义会有不同。
（1）CLEAR_VARS: 指 向一个编译脚本，几乎所有未定义的 LOCAL_XXX 变量都在"Module-description"节中列出。必须在开始一个新模块之前包含这个脚本：include$(CLEAR_VARS)，用于重 置除LOCAL_PATH变量外的，所有LOCAL_XXX系列变量。
（2）BUILD_SHARED_LIBRARY: 指向编译脚本，根据所有的在 LOCAL_XXX 变量把列出的源代码文件编译成一个共享库。
注意，必须至少在包含这个文件之前定义 LOCAL_MODULE 和 LOCAL_SRC_FILES。
（3） BUILD_STATIC_LIBRARY: 一个 BUILD_SHARED_LIBRARY 变量用于编译一个静态库。静态库不会复制到的APK包中，但是能够用于编译共享库。
示例：include $(BUILD_STATIC_LIBRARY)
注意，这将会生成一个名为 lib$(LOCAL_MODULE).a 的文件
（4）TARGET_ARCH: 目标 CPU平台的名字, 和 android 开放源码中指定的那样。如果是
arm，表示要生成 ARM 兼容的指令，与 CPU架构的修订版无关。
（5）TARGET_PLATFORM: Android.mk 解析的时候，目标 Android 平台的名字.详情可参考/development/ndk/docs/stable- apis.txt.
android-3 -> Official Android 1.5 system images
android-4 -> Official Android 1.6 system images
android-5 -> Official Android 2.0 system images
（6）TARGET_ARCH_ABI: 暂 时只支持两个 value，armeabi 和 armeabi-v7a。在现在的版本中一般把这两个值简单的定义为 arm， 通过 android 平台内部对它重定义来获得更好的匹配。其他的 ABI 将在以后的 NDK 版本中介绍，它们会有不同的名字。注意虽然所有基于
ARM的ABI都会把 'TARGET_ARCH'定义成‘arm’， 但是会有不同的‘TARGET_ARCH_ABI’。
（ 7 ） TARGET_ABI: 目标平台和 ABI 的组合，它事实上被定义成$(TARGET_PLATFORM)-$(TARGET_ARCH_ABI) ，在想要在真实的设备中针对一个特别的目标系统进行测试时，会有用。在默认的情况下，它会是'android-3-arm'。
五、模块描述变量
下面的变量用于向编译系统描述你的模块。你应该定义在'include $(CLEAR_VARS)'和'include $(BUILD_XXXXX)'之间。正如前面描写的那样，$(CLEAR_VARS)是一个脚本，清除所有这些变量。
（1） LOCAL_PATH: 这 个变量用于给出当前文件的路径。必须在 Android.mk 的开头定义，可以这样使用：LOCAL_PATH := $(call my-dir) 这个变量不会被$(CLEAR_VARS)清除，因此每个 Android.mk 只需要定义一次(即使在一个文件中定义了几个模块的情况下)。
（2）LOCAL_MODULE: 这是模块的名字，它必须是唯一的，而且不能包含空格。必须在包含任一的$(BUILD_XXXX)脚本之前定义它。模块的名字决定了生成文件的名字。例如，如果一个一个共享库模块的名字是，那么生成文件的名字就是 lib.so。但是，在的 NDK 生成文
件中(或者 Android.mk 或者 Application.mk)，应该只涉及(引用)有正常名字的其他模块。
（3）LOCAL_SRC_FILES: 这是要编译的源代码文件列表。只要列出要传递给编译器的文件，因为编译系统自动计算依赖。注意源代码文件名称都是相对于 LOCAL_PATH的，你可以使用路径部分，例如：
LOCAL_SRC_FILES := foo.c toto/bar.c\
Hello.c
文件之间可以用空格或Tab键进行分割,换行请用"\".如果是追加源代码文件的话，请用LOCAL_SRC_FILES +=
注意：在生成文件中都要使用UNIX风格的斜杠(/).windows风格的反斜杠不会被正确的处理。
注意：可以LOCAL_SRC_FILES := $(call all-subdir-java-files)这种形式来包含local_path目录下的所有java文件。
（4） LOCAL_CPP_EXTENSION: 这是一个可选变量， 用来指定C++代码文件的扩展名，默认是'.cpp',但是可以改变它，比如：
LOCAL_CPP_EXTENSION := .cxx
（5） LOCAL_C_INCLUDES: 可选变量，表示头文件的搜索路径。默认的头文件的搜索路径是LOCAL_PATH目录。
示例:LOCAL_C_INCLUDES := sources/foo或LOCAL_C_INCLUDES := $(LOCAL_PATH)/../foo
LOCAL_C_INCLUDES需要在任何包含LOCAL_CFLAGS/LOCAL_CPPFLAGS标志之前进行设置。
（6）LOCAL_CFLAGS: 可选的编译器选项，在编译 C 代码文件的时候使用。这可能是有
用的，指定一个附加的包含路径(相对于NDK的顶层目录)，宏定义，或者编译选项。
注意：不要在 Android.mk 中改变 optimization/debugging 级别，只要在 Application.mk 中指定合适的信息，就会自动地为你处理这个问题，在调试期间，会让 NDK自动生成有用的数据文件。
（7）LOCAL_CXXFLAGS: 与 LOCAL_CFLAGS同理，针对 C++源文件。
（8）LOCAL_CPPFLAGS: 与 LOCAL_CFLAGS同理，但是对 C 和 C++ source files都适用。
（9）LOCAL_STATIC_LIBRARIES: 表示该模块需要使用哪些静态库，以便在编译时进行链接。
（10）LOCAL_SHARED_LIBRARIES: 表示模块在运行时要依赖的共享库（动态库），在链接时就需要，以便在生成文件时嵌入其相应的信息。注意：它不会附加列出的模块到编译图，也就是仍然需要在Application.mk 中把它们添加到程序要求的模块中。
（11）LOCAL_LDLIBS: 编译模块时要使用的附加的链接器选项。这对于使用‘-l’前缀传递指定库的名字是有用的。
例如，LOCAL_LDLIBS := -lz表示告诉链接器生成的模块要在加载时刻链接到/system/lib/libz.so
可查看 docs/STABLE-APIS.TXT 获取使用 NDK发行版能链接到的开放的系统库列表。
(注意：LOCAL_LDLIBS与LOCAL_STATIC_LIBRARIES及LOCAL_SHARED_LIBRARIES的区别是，LOCAL_LDLIBS是没有源代码或代码未被包含到Android.mk的库,如库不存在，则会报错找不到; 而其余两个是有代码且被包含到Android.mk的库里了，当她们的代码发生变化时候或当库不存在时，会自动重新编译他们的代码)
（12） LOCAL_ALLOW_UNDEFINED_SYMBOLS: 默认情况下， 在试图编译一个共享库时，任何未定义的引用将导致一个“未定义的符号”错误。这对于在源代码文件中捕捉错误会有很大的帮助。然而，如果因为某些原因，需要不启动这项检查，可把这个变量设为‘true’。
注意相应的共享库可能在运行时加载失败。(这个一般尽量不要去设为 true)。
（13） LOCAL_ARM_MODE: 默认情况下， arm目标二进制会以 thumb 的形式生成(16 位)，你可以通过设置这个变量为 arm如果你希望你的 module 是以 32 位指令的形式。
'arm' (32-bit instructions) mode. E.g.:
LOCAL_ARM_MODE := arm
注意：可以在编译的时候告诉系统针对某个源码文件进行特定的类型的编译
比如，LOCAL_SRC_FILES := foo.c bar.c.arm 这样就告诉系统总是将 bar.c 以arm的模式编译。
(14)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‘功能’宏
GNU Make‘功能’宏，必须通过使用'$(call )'来调用，调用他们将返回文本化的信息。
（1）my-dir:返回当前 Android.mk 所在的目录的路径，相对于 NDK 编译系统的顶层。这是有用的，在 Android.mk 文件的开头如此定义：
LOCAL_PATH := $(call my-dir)
（2）all-subdir-makefiles: 返回一个位于当前'my-dir'路径的子目录中的所有Android.mk的列表。
例如，看下面的目录层次：
sources/foo/Android.mk
sources/foo/lib1/Android.mk
sources/foo/lib2/Android.mk
如果 sources/foo/Android.mk 包含一行：
include $(call all-subdir-makefiles)
那么它就会自动包含 sources/foo/lib1/Android.mk 和 sources/foo/lib2/Android.mk。
这项功能用于向编译系统提供深层次嵌套的代码目录层次。
注意，在默认情况下，NDK 将会只搜索在 sources/*/Android.mk 中的文件。
（3）this-makefile: 返回当前Makefile 的路径(即这个函数调用的地方)
（4）parent-makefile: 返回调用树中父 Makefile 路径。即包含当前Makefile的Makefile 路径。
（5）grand-parent-makefile：返回调用树中父Makefile的父Makefile的路径
八、 Android.mk 使用模板
在一个 Android.mk 中可以生成多个APK应用程序，JAVA库，C\C++可执行程序,C\C++动态库和C\C++静态库。
（1）编译APK应用程序模板。
关于编译APK应用程序的模板请参照《Android.mk编译APK范例》
（2）编译JAVA库模板
LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
# Build all java files in the java subdirectory
LOCAL_SRC_FILES := $(call all-subdir-java-files)
# Any libraries that this library depends on
LOCAL_JAVA_LIBRARIES := android.test.runner
# The name of the jar file to create
LOCAL_MODULE := sample
# Build a static jar file.
include $(BUILD_STATIC_JAVA_LIBRARY)
注：LOCAL_JAVA_LIBRARIES := android.test.runner表示生成的JAVA库的jar文件名
（3）编译C/C++应用程序模板如下：
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)
注：‘:=’是赋值的意思，'+='是追加的意思，‘$’表示引用某变量的值
LOCAL_SRC_FILES中加入源文件路径，LOCAL_C_INCLUDES中加入需要的头文件搜索路径
LOCAL_STATIC_LIBRARIES 加入所需要链接的静态库(*.a)的名称，
LOCAL_SHARED_LIBRARIES 中加入所需要链接的动态库(*.so)的名称，
LOCAL_MODULE表示模块最终的名称，BUILD_EXECUTABLE 表示以一个可执行程序的方式进行编译。
（4）编译C\C++静态库
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)
和上面相似，BUILD_STATIC_LIBRARY 表示编译一个静态库。
（5）编译C\C++动态库的模板
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)
和上面相似，BUILD_SHARED_LIBRARY 表示编译一个共享库。
以上三者的生成结果分别在如下目录中，generic 依具体 target 会变：
out/target/product/generic/obj/APPS
out/target/product/generic/obj/JAVA_LIBRARIES
out/target/product/generic/obj/EXECUTABLE
out/target/product/generic/obj/STATIC_LIBRARY
out/target/product/generic/obj/SHARED_LIBRARY
每个模块的目标文件夹分别为：
1）APK程序：XXX_intermediates
2）JAVA库程序：XXX_intermediates
这里的XXX
3）C\C++可执行程序：XXX_intermediates
4）C\C++静态库： XXX_static_intermediates
5）C\C++动态库： XXX_shared_intermediates
Android Android.mk 文件一点感悟
Android.mk文件时android 中的一个非常重要的概念。我们有以下几个方便的时候需要使用它。
1：添加新的apk源码文件编译。这里我们先参考下AlarmClock的Android.mk文件
LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_SRC_FILES := $(call all-subdir-java-files)
LOCAL_PACKAGE_NAME := AlarmClock
include $(BUILD_PACKAGE)
简单的解释下：
第一行，赋予LOCAL_PATH一个新的值，表示当前的路径。
第二行，清楚所有的系统自带的标准变量值。我们通过查找CLEAR_VARS变量定义，可以发现它实际上代表的是
source\build\core\config.mk中有定义如下：
CLEAR_VARS:= $(BUILD_SYSTEM)/clear_vars.mk
所以查看clear_vars.mk文件可以得到知道：
###########################################################
## Clear out values of all variables used by rule templates.
###########################################################
LOCAL_MODULE:=
LOCAL_MODULE_PATH:=
LOCAL_MODULE_STEM:=
LOCAL_DONT_CHECK_MODULE:=
LOCAL_CHECKED_MODULE:=
LOCAL_BUILT_MODULE:=
LOCAL_BUILT_MODULE_STEM:=
OVERRIDE_BUILT_MODULE_PATH:=
....
它把这些变量都清空了。
注意它这里没有去清空LOCAL_PATH变量。所以这个步骤放在第二行，是没有关系的。它的这个写法有点误导人哈。
第三、四行，给变量赋予新值。这里赋予的是LOCAL_SRC_FILES，LOCAL_PACKAGE_NAME
第五行，执行BUILD_PACKAGE。它的定义也是在config.mk中定义如下：
BUILD_PACKAGE:= $(BUILD_SYSTEM)/package.mk，更多更加具体的，自己去看看吧。
这里其实有很多的，
# ###############################################################
# Build system internal files
# ###############################################################
BUILD_COMBOS:= $(BUILD_SYSTEM)/combo
CLEAR_VARS:= $(BUILD_SYSTEM)/clear_vars.mk
BUILD_HOST_STATIC_LIBRARY:= $(BUILD_SYSTEM)/host_static_library.mk
BUILD_HOST_SHARED_LIBRARY:= $(BUILD_SYSTEM)/host_shared_library.mk
BUILD_STATIC_LIBRARY:= $(BUILD_SYSTEM)/static_library.mk
BUILD_RAW_STATIC_LIBRARY := $(BUILD_SYSTEM)/raw_static_library.mk
BUILD_SHARED_LIBRARY:= $(BUILD_SYSTEM)/shared_library.mk
BUILD_EXECUTABLE:= $(BUILD_SYSTEM)/executable.mk
BUILD_RAW_EXECUTABLE:= $(BUILD_SYSTEM)/raw_executable.mk
BUILD_HOST_EXECUTABLE:= $(BUILD_SYSTEM)/host_executable.mk
BUILD_PACKAGE:= $(BUILD_SYSTEM)/package.mk
BUILD_HOST_PREBUILT:= $(BUILD_SYSTEM)/host_prebuilt.mk
BUILD_PREBUILT:= $(BUILD_SYSTEM)/prebuilt.mk
BUILD_MULTI_PREBUILT:= $(BUILD_SYSTEM)/multi_prebuilt.mk
BUILD_JAVA_LIBRARY:= $(BUILD_SYSTEM)/java_library.mk
BUILD_STATIC_JAVA_LIBRARY:= $(BUILD_SYSTEM)/static_java_library.mk
BUILD_HOST_JAVA_LIBRARY:= $(BUILD_SYSTEM)/host_java_library.mk
BUILD_DROIDDOC:= $(BUILD_SYSTEM)/droiddoc.mk
BUILD_COPY_HEADERS := $(BUILD_SYSTEM)/copy_headers.mk
BUILD_KEY_CHAR_MAP := $(BUILD_SYSTEM)/key_char_map.mk
基本上你有用到的就已经提前给你设计好了。你要做的很简单了。
这里的思想其实和makefile的是一样的。
目标：信赖文件
执行命令
只是android在这里进行了高度的封装和简化。
前面四行相当于设置目标文件。
最后一行相当于执行命令。
所以，如果我们要添加自己的apk,就按照这种思想添加就可以了。
2：变量的使用
makefile文件有一个基础的东西就是变量。大家可以自己了解下。这里我们说说android.mk这个变量的不同的地方。主要是用它来做代码管理。这个部分是我同事小强总结出来的，我就cp过来。
替它总结下。
首先在执行make文件的时候这些变量是全局有效的，一些公共的变量会通过include $(CLEAR_VARS)给清除掉。我们这里主要是添加自己的变量。
我们在使用自己定义变量的时候有两种情况，一种是在mk中使用，一种是在cpp中使用。注意java不支持的。
这两种情况有点不同，请注意。
首先我们得定义这个变量，一般来讲都是在产品的BoardConfig.mk中定义，例如：
TARGET_MEMORY_STYLE := TARGET_MEM_256MB
#TARGET_MEMORY_STYLE := TARGET_MEM_256MB_ST
#TARGET_MEMORY_STYLE := TARGET_MEM_512MB
#TARGET_MEMORY_STYLE := TARGET_MEM_512MB_ST
# board-specific configuration
BOARD_OPENCORE_FLAGS := -DTELECHIPS_ALSA
ifeq ($(BOARD_KERNEL_BASE),0x40000000)
BOARD_MEM_FLAGS := -DTCC_MEM_256MB
else
BOARD_MEM_FLAGS := -DTCC_MEM_512MB
endif
这里总共有两个我们经常用的东西。
第一：
如果是mk总使用，定义如前四行就可以了。
变量 := 字符串
在mk中的使用方法就像后面例子一样。
ifeq($(变量),对比值)
else
endif
第二：如果你想在cpp中使用，请定义方式如下
变量 := -D+变量名
如后面几行示例一样的。
如果想在cpp中应用，首先必须在cpp对于的mk文件中，声明如下
LOCAL_CFLAGS += $(BOARD_MEM_FLAGS)
格式：
LOCAL_CFLAGS += $(变量)
然后它的cpp中就可以引用如下：
此时去掉了-D前缀。
ifdef TCC_MEM_512MB
......
endif
特此感谢小强同学的代码控制.doc。
http://www.ibm.com/developerworks/cn/opensource/os-cn-android-build/
理解 Android Build 系统
Android Build 系统是用来编译 Android 系统，Android SDK 以及相关文档的一套框架。众所周知，Android 是一个开源的操作系统。Android 的源码中包含了许许多多的模块。 不同产商的不同设备对于 Android 系统的定制都是不一样的。如何将这些模块统一管理起来，如何能够在不同的操作系统上进行编译，如何在编译时能够支持面向不同的硬件设备，不同的编译类型， 且还要提供面向各个产商的定制扩展，是非常有难度的。 但 Android Build 系统很好的解决了这些问题，这里面有很多值得我们开发人员学习的地方。对于 Android 平台开发人员来说，本文可以帮助你熟悉你每天接触到的构建环境。对于其他开发人员来说，本文可以作为一个 GNU Make 的使用案例，学习这些成功案例，可以提升我们的开发经验。
前言
Android Build 系统是 Android 源码的一部分。关于如何获取 Android 源码，请参照 Android Source 官方网站：
http://source.android.com/source/downloading.html。
Android Build 系统用来编译 Android 系统，Android SDK 以及相关文档。该系统主要由 Make 文件，Shell 脚本以及 Python 脚本组成，其中最主要的是 Make 文件。
众所周知，Android 是一个开源的操作系统。Android 的源码中包含了大量的开源项目以及许多的模块。不同产商的不同设备对于 Android 系统的定制都是不一样的。
如何将这些项目和模块的编译统一管理起来，如何能够在不同的操作系统上进行编译，如何在编译时能够支持面向不同的硬件设备，不同的编译类型，且还要提供面向各个产商的定制扩展，是非常有难度的。
但 Android Build 系统很好的解决了这些问题，这里面有很多值得我们开发人员学习的地方。
对于 Android 平台开发人员来说，本文可以帮助你熟悉你每天接触到的构建环境。
对于其他开发人员来说，本文可以作为一个 GNU Make 的使用案例，学习这些成功案例，可以提升我们的开发经验。
概述
Build 系统中最主要的处理逻辑都在 Make 文件中，而其他的脚本文件只是起到一些辅助作用，由于篇幅所限，本文只探讨 Make 文件中的内容。
整个 Build 系统中的 Make 文件可以分为三类：
第一类是 Build 系统核心文件，此类文件定义了整个 Build 系统的框架，而其他所有 Make 文件都是在这个框架的基础上编写出来的。
图 1 是 Android 源码树的目录结构，Build 系统核心文件全部位于 /build/core（本文所提到的所有路径都是以 Android 源码树作为背景的，“/”指的是源码树的根目录，与文件系统无关）目录下。
图 1. Android 源码树的目录结构
第 二类是针对某个产品（一个产品可能是某个型号的手机或者平板电脑）的 Make 文件，这些文件通常位于 device 目录下，该目录下又以公司名以及产品名分为两级目录，图 2 是 device 目录下子目录的结构。对于一个产品的定义通常需要一组文件，这些文件共同构成了对于这个产品的定义。例如，/device/sony/it26 目录下的文件共同构成了对于 Sony LT26 型号手机的定义。
图 2. device 目录下子目录的结构
第 三类是针对某个模块（关于模块后文会详细讨论）的 Make 文件。整个系统中，包含了大量的模块，每个模块都有一个专门的 Make 文件，这类文件的名称统一为“Android.mk”，该文件中定义了如何编译当前模块。Build 系统会在整个源码树中扫描名称为“Android.mk”的文件并根据其中的内容执行模块的编译。
编译 Android 系统
执行编译
Android 系统的编译环境目前只支持 Ubuntu 以及 Mac OS 两种操作系统。关于编译环境的构建方法请参见以下路径：http://source.android.com/source/initializing.html
在完成编译环境的准备工作以及获取到完整的 Android 源码之后，想要编译出整个 Android 系统非常的容易：
打开控制台之后转到 Android 源码的根目录，然后执行如清单 1 所示的三条命令即可（"$"是命令提示符，不是命令的一部分。）：
完整的编译时间依赖于编译主机的配置，在笔者的 Macbook Pro（OS X 10.8.2, i7 2G CPU，8G RAM, 120G SSD）上使用 8 个 Job 同时编译共需要一个半小时左右的时间。
清单 1. 编译 Android 系统
$ source build/envsetup.sh $ lunch full-eng $ make -j8
这三行命令的说明如下：
第一行命令“source build/envsetup.sh”引入了 build/envsetup.sh脚本。该脚本的作用是初始化编译环境，并引入一些辅助的 Shell 函数，这其中就包括第二步使用 lunch 函数。
除此之外，该文件中还定义了其他一些常用的函数，它们如表 1 所示：
表 1. build/envsetup.sh 中定义的常用函数
| 名称 | 说明 |
|---|---|
| croot | 切换到源码树的根目录 |
| m | 在源码树的根目录执行 make |
| mm | Build 当前目录下的模块 |
| mmm | Build 指定目录下的模块 |
| cgrep | 在所有 C/C++ 文件上执行 grep |
| jgrep | 在所有 Java 文件上执行 grep |
| resgrep | 在所有 res/*.xml 文件上执行 grep |
| godir | 转到包含某个文件的目录路径 |
| printconfig | 显示当前 Build 的配置信息 |
| add_lunch_combo | 在 lunch 函数的菜单中添加一个条目 |
第二行命令“lunch full-eng”是调用 lunch 函数，并指定参数为“full-eng”。lunch 函数的参数用来指定此次编译的目标设备以及编译类型。在这里，这两个值分别是“full”和“eng”。“full”是 Android 源码中已经定义好的一种产品，是为模拟器而设置的。而编译类型会影响最终系统中包含的模块，关于编译类型将在表 7 中详细讲解。
如果调用 lunch 函数的时候没有指定参数，那么该函数将输出列表以供选择，该列表类似图 3 中的内容（列表的内容会根据当前 Build 系统中包含的产品配置而不同，具体参见后文“添加新的产品”），此时可以通过输入编号或者名称进行选择。
图 3. lunch 函数的输出
第三行命令“make -j8”才真正开始执行编译。make 的参数“-j”指定了同时编译的 Job 数量，这是个整数，该值通常是编译主机 CPU 支持的并发线程总数的 1 倍或 2 倍（例如：在一个 4 核，每个核支持两个线程的 CPU 上，可以使用 make -j8 或 make -j16）。在调用 make 命令时，如果没有指定任何目标，则将使用默认的名称为“droid”目标，该目标会编译出完整的 Android 系统镜像。
Build 结果的目录结构
所有的编译产物都将位于 /out 目录下，该目录下主要有以下几个子目录：
- /out/host/：该目录下包含了针对主机的 Android 开发工具的产物。即 SDK 中的各种工具，例如：emulator，adb，aapt 等。
- /out/target/common/：该目录下包含了针对设备的共通的编译产物，主要是 Java 应用代码和 Java 库。
- /out/target/product/<product_name>/：包含了针对特定设备的编译结果以及平台相关的 C/C++ 库和二进制文件。其中，<product_name>是具体目标设备的名称。
- /out/dist/：包含了为多种分发而准备的包，通过“
make disttarget”将文件拷贝到该目录，默认的编译目标不会产生该目录。
Build 生成的镜像文件
Build 的产物中最重要的是三个镜像文件，它们都位于 /out/target/product/<product_name>/ 目录下。
这三个文件是：
- system.img：包含了 Android OS 的系统文件，库，可执行文件以及预置的应用程序，将被挂载为根分区。
- ramdisk.img：在启动时将被 Linux 内核挂载为只读分区，它包含了 /init 文件和一些配置文件。它用来挂载其他系统镜像并启动 init 进程。
- userdata.img：将被挂载为 /data，包含了应用程序相关的数据以及和用户相关的数据。
Make 文件说明
整个 Build 系统的入口文件是源码树根目录下名称为“Makefile”的文件，当在源代码根目录上调用 make 命令时，make 命令首先将读取该文件。
Makefile 文件的内容只有一行：“include build/core/main.mk”。该行代码的作用很明显：包含 build/core/main.mk 文件。在 main.mk 文件中又会包含其他的文件，其他文件中又会包含更多的文件，这样就引入了整个 Build 系统。
这些 Make 文件间的包含关系是相当复杂的，图 3 描述了这种关系，该图中黄色标记的文件（且除了 $开头的文件）都位于 build/core/ 目录下。
图 4. 主要的 Make 文件及其包含关系
表 2 总结了图 4 中提到的这些文件的作用：
表 2. 主要的 Make 文件的说明
| 文件名 | 说明 |
|---|---|
| main.mk | 最主要的 Make 文件，该文件中首先将对编译环境进行检查，同时引入其他的 Make 文件。另外，该文件中还定义了几个最主要的 Make 目标，例如 droid，sdk，等（参见后文“Make 目标说明”）。 |
| help.mk | 包含了名称为 help 的 Make 目标的定义，该目标将列出主要的 Make 目标及其说明。 |
| pathmap.mk | 将许多头文件的路径通过名值对的方式定义为映射表，并提供 include-path-for 函数来获取。例如，通过 $(call include-path-for, frameworks-native)便可以获取到 framework 本地代码需要的头文件路径。 |
| envsetup.mk | 配置 Build 系统需要的环境变量，例如：TARGET_PRODUCT，TARGET_BUILD_VARIANT，HOST_OS，HOST_ARCH 等。 当前编译的主机平台信息（例如操作系统，CPU 类型等信息）就是在这个文件中确定的。 另外，该文件中还指定了各种编译结果的输出路径。 |
| combo/select.mk | 根据当前编译器的平台选择平台相关的 Make 文件。 |
| dumpvar.mk | 在 Build 开始之前，显示此次 Build 的配置信息。 |
| config.mk | 整个 Build 系统的配置文件，最重要的 Make 文件之一。该文件中主要包含以下内容：
|
| definitions.mk | 最重要的 Make 文件之一，在其中定义了大量的函数。这些函数都是 Build 系统的其他文件将用到的。例如：my-dir，all-subdir-makefiles，find-subdir-files，sign-package 等，关于这些函数的说明请参见每个函数的代码注释。 |
| distdir.mk | 针对 dist 目标的定义。dist 目标用来拷贝文件到指定路径。 |
| dex_preopt.mk | 针对启动 jar 包的预先优化。 |
| pdk_config.mk | 顾名思义，针对 pdk（Platform Developement Kit）的配置文件。 |
${ONE_SHOT_MAKEFILE} | ONE_SHOT_MAKEFILE 是一个变量，当使用“mm”编译某个目录下的模块时，此变量的值即为当前指定路径下的 Make 文件的路径。 |
${subdir_makefiles} | 各个模块的 Android.mk 文件的集合，这个集合是通过 Python 脚本扫描得到的。 |
| post_clean.mk | 在前一次 Build 的基础上检查当前 Build 的配置，并执行必要清理工作。 |
| legacy_prebuilts.mk | 该文件中只定义了 GRANDFATHERED_ALL_PREBUILT 变量。 |
| Makefile | 被 main.mk 包含，该文件中的内容是辅助 main.mk 的一些额外内容。 |
Android 源码中包含了许多的模块，模块的类型有很多种，例如：Java 库，C/C++ 库，APK 应用，以及可执行文件等 。并且，Java 或者 C/C++ 库还可以分为静态的或者动态的，库或可执行文件既可能是针对设备（本文的“设备”指的是 Android 系统将被安装的设备，例如某个型号的手机或平板）的也可能是针对主机（本文的“主机”指的是开发 Android 系统的机器，例如装有 Ubuntu 操作系统的 PC 机或装有 MacOS 的 iMac 或 Macbook）的。不同类型的模块的编译步骤和方法是不一样，为了能够一致且方便的执行各种类型模块的编译，在 config.mk 中定义了许多的常量，这其中的每个常量描述了一种类型模块的编译方式，这些常量有：
- BUILD_HOST_STATIC_LIBRARY
- BUILD_HOST_SHARED_LIBRARY
- BUILD_STATIC_LIBRARY
- BUILD_SHARED_LIBRARY
- BUILD_EXECUTABLE
- BUILD_HOST_EXECUTABLE
- BUILD_PACKAGE
- BUILD_PREBUILT
- BUILD_MULTI_PREBUILT
- BUILD_HOST_PREBUILT
- BUILD_JAVA_LIBRARY
- BUILD_STATIC_JAVA_LIBRARY
- BUILD_HOST_JAVA_LIBRARY
通过名称大概就可以猜出每个变量所对应的模块类型。（在模块的 Android.mk 文件中，只要包含进这里对应的常量便可以执行相应类型模块的编译。对于 Android.mk 文件的编写请参见后文：“添加新的模块”。）
这些常量的值都是另外一个 Make 文件的路径，详细的编译方式都是在对应的 Make 文件中定义的。这些常量和 Make 文件的是一一对应的，对应规则也很简单：常量的名称是 Make 文件的文件名除去后缀全部改为大写然后加上“BUILD_”作为前缀。例如常量 BUILD_HOST_PREBUILT 的值对应的文件就是 host_prebuilt.mk。
这些 Make 文件的说明如表 3 所示：
表 3. 各种模块的编译方式的定义文件
| 文件名 | 说明 |
|---|---|
| host_static_library.mk | 定义了如何编译主机上的静态库。 |
| host_shared_library.mk | 定义了如何编译主机上的共享库。 |
| static_library.mk | 定义了如何编译设备上的静态库。 |
| shared_library.mk | 定义了如何编译设备上的共享库。 |
| executable.mk | 定义了如何编译设备上的可执行文件。 |
| host_executable.mk | 定义了如何编译主机上的可执行文件。 |
| package.mk | 定义了如何编译 APK 文件。 |
| prebuilt.mk | 定义了如何处理一个已经编译好的文件 ( 例如 Jar 包 )。 |
| multi_prebuilt.mk | 定义了如何处理一个或多个已编译文件，该文件的实现依赖 prebuilt.mk。 |
| host_prebuilt.mk | 处理一个或多个主机上使用的已编译文件，该文件的实现依赖 multi_prebuilt.mk。 |
| java_library.mk | 定义了如何编译设备上的共享 Java 库。 |
| static_java_library.mk | 定义了如何编译设备上的静态 Java 库。 |
| host_java_library.mk | 定义了如何编译主机上的共享 Java 库。 |
不同类型的模块的编译过程会有一些相同的步骤，例如：编译一个 Java 库和编译一个 APK 文件都需要定义如何编译 Java 文件。因此，表 3 中的这些 Make 文件的定义中会包含一些共同的代码逻辑。为了减少代码冗余，需要将共同的代码复用起来，复用的方式是将共同代码放到专门的文件中，然后在其他文件中包含这些文件的方式来实现的。这些包含关系如图 5 所示。由于篇幅关系，这里就不再对其他文件做详细描述（其实这些文件从文件名称中就可以大致猜出其作用）。
图 5. 模块的编译方式定义文件的包含关系
Make 目标说明
make /make droid
如果在源码树的根目录直接调用“make”命令而不指定任何目标，则会选择默认目标：“droid”（在 main.mk 中定义）。因此，这和执行“make droid”效果是一样的。
droid 目标将编译出整个系统的镜像。从源代码到编译出系统镜像，整个编译过程非常复杂。这个过程并不是在 droid 一个目标中定义的，而是 droid 目标会依赖许多其他的目标，这些目标的互相配合导致了整个系统的编译。
图 6 描述了 droid 目标所依赖的其他目标：
图 6. droid 目标所依赖的其他 Make 目标
图 6 中这些目标的说明如表 4 所示：
表 4. droid 所依赖的其他 Make 目标的说明
| 名称 | 说明 |
|---|---|
| apps_only | 该目标将编译出当前配置下不包含 user，userdebug，eng 标签（关于标签，请参见后文“添加新的模块”）的应用程序。 |
| droidcore | 该目标仅仅是所依赖的几个目标的组合，其本身不做更多的处理。 |
| dist_files | 该目标用来拷贝文件到 /out/dist 目录。 |
| files | 该目标仅仅是所依赖的几个目标的组合，其本身不做更多的处理。 |
| prebuilt | 该目标依赖于 $(ALL_PREBUILT)，$(ALL_PREBUILT)的作用就是处理所有已编译好的文件。 |
$(modules_to_install) | modules_to_install 变量包含了当前配置下所有会被安装的模块（一个模块是否会被安装依赖于该产品的配置文件，模块的标签等信息），因此该目标将导致所有会被安装的模块的编译。 |
$(modules_to_check) | 该目标用来确保我们定义的构建模块是没有冗余的。 |
$(INSTALLED_ANDROID_INFO_TXT_TARGET) | 该目标会生成一个关于当前 Build 配置的设备信息的文件，该文件的生成路径是：out/target/product/<product_name>/android-info.txt |
| systemimage | 生成 system.img。 |
$(INSTALLED_BOOTIMAGE_TARGET) | 生成 boot.img。 |
$(INSTALLED_RECOVERYIMAGE_TARGET) | 生成 recovery.img。 |
$(INSTALLED_USERDATAIMAGE_TARGET) | 生成 userdata.img。 |
$(INSTALLED_CACHEIMAGE_TARGET) | 生成 cache.img。 |
$(INSTALLED_FILES_FILE) | 该目标会生成 out/target/product/<product_name>/ installed-files.txt 文件，该文件中内容是当前系统镜像中已经安装的文件列表。 |
其他目标
Build 系统中包含的其他一些 Make 目标说明如表 5 所示：
表 5. 其他主要 Make 目标
| Make 目标 | 说明 |
|---|---|
| make clean | 执行清理，等同于：rm -rf out/。 |
| make sdk | 编译出 Android 的 SDK。 |
| make clean-sdk | 清理 SDK 的编译产物。 |
| make update-api | 更新 API。在 framework API 改动之后，需要首先执行该命令来更新 API，公开的 API 记录在 frameworks/base/api 目录下。 |
| make dist | 执行 Build，并将 MAKECMDGOALS 变量定义的输出文件拷贝到 /out/dist 目录。 |
| make all | 编译所有内容，不管当前产品的定义中是否会包含。 |
| make help | 帮助信息，显示主要的 make 目标。 |
| make snod | 从已经编译出的包快速重建系统镜像。 |
| make libandroid_runtime | 编译所有 JNI framework 内容。 |
| makeframework | 编译所有 Java framework 内容。 |
| makeservices | 编译系统服务和相关内容。 |
| make <local_target> | 编译一个指定的模块，local_target 为模块的名称。 |
| make clean-<local_target> | 清理一个指定模块的编译结果。 |
| makedump-products | 显示所有产品的编译配置信息，例如：产品名，产品支持的地区语言，产品中会包含的模块等信息。 |
| makePRODUCT-xxx-yyy | 编译某个指定的产品。 |
| makebootimage | 生成 boot.img |
| makerecoveryimage | 生成 recovery.img |
| makeuserdataimage | 生成 userdata.img |
| makecacheimage | 生成 cache.img |
在 Build 系统中添加新的内容
添加新的产品
当我们要开发一款新的 Android 产品的时候，我们首先就需要在 Build 系统中添加对于该产品的定义。
在 Android Build 系统中对产品定义的文件通常位于 device 目录下（另外还有一个可以定义产品的目录是 vender 目录，这是个历史遗留目录，Google 已经建议不要在该目录中进行定义，而应当选择 device 目录）。device 目录下根据公司名以及产品名分为二级目录，这一点我们在概述中已经提到过。
通常，对于一个产品的定义通常至少会包括四个文件：AndroidProducts.mk，产品版本定义文件，BoardConfig.mk 以及 verndorsetup.sh。下面我们来详细说明这几个文件。
- AndroidProducts.mk：该文文件中的内容很简单，其中只需要定义一个变量，名称为“PRODUCT_MAKEFILES”，该变量的值为产品版本定义文件名的列表，例如：
PRODUCT_MAKEFILES := \ $(LOCAL_DIR)/full_stingray.mk \ $(LOCAL_DIR)/stingray_emu.mk \ $(LOCAL_DIR)/generic_stingray.mk
- 产品版本定义文件：顾名思义，该文件中包含了对于特定产品版本的定义。该文件可能不只一个，因为同一个产品可能会有多种版本（例如，面向中国地区一个版本，面向美国地区一个版本）。该文件中可以定义的变量以及含义说明如表 6 所示：
表 6. 产品版本定义文件中的变量及其说明
| 常量 | 说明 |
|---|---|
| PRODUCT_NAME | 最终用户将看到的完整产品名，会出现在“关于手机”信息中。 |
| PRODUCT_MODEL | 产品的型号，这也是最终用户将看到的。 |
| PRODUCT_LOCALES | 该产品支持的地区，以空格分格，例如：en_GB de_DE es_ES fr_CA。 |
| PRODUCT_PACKAGES | 该产品版本中包含的 APK 应用程序，以空格分格，例如：Calendar Contacts。 |
| PRODUCT_DEVICE | 该产品的工业设计的名称。 |
| PRODUCT_MANUFACTURER | 制造商的名称。 |
| PRODUCT_BRAND | 该产品专门定义的商标（如果有的话）。 |
| PRODUCT_PROPERTY_OVERRIDES | 对于商品属性的定义。 |
| PRODUCT_COPY_FILES | 编译该产品时需要拷贝的文件，以“源路径 : 目标路径”的形式。 |
| PRODUCT_OTA_PUBLIC_KEYS | 对于该产品的 OTA 公开 key 的列表。 |
| PRODUCT_POLICY | 产品使用的策略。 |
| PRODUCT_PACKAGE_OVERLAYS | 指出是否要使用默认的资源或添加产品特定定义来覆盖。 |
| PRODUCT_CONTRIBUTORS_FILE | HTML 文件，其中包含项目的贡献者。 |
| PRODUCT_TAGS | 该产品的标签，以空格分格。 |
通常情况下，我们并不需要定义所有这些变量。Build 系统的已经预先定义好了一些组合，它们都位于 /build/target/product 下，每个文件定义了一个组合，我们只要继承这些预置的定义，然后再覆盖自己想要的变量定义即可。例如：
# 继承 full_base.mk 文件中的定义 $(call inherit-product, $(SRC_TARGET_DIR)/product/full_base.mk) # 覆盖其中已经定义的一些变量 PRODUCT_NAME := full_lt26 PRODUCT_DEVICE := lt26 PRODUCT_BRAND := Android PRODUCT_MODEL := Full Android on LT26
- BoardConfig.mk：该文件用来配置硬件主板，它其中定义的都是设备底层的硬件特性。例如：该设备的主板相关信息，Wifi 相关信息，还有 bootloader，内核，radioimage 等信息。对于该文件的示例，请参看 Android 源码树已经有的文件。
- vendorsetup.sh：该文件中作用是通过 add_lunch_combo 函数在 lunch 函数中添加一个菜单选项。该函数的参数是产品名称加上编译类型，中间以“-”连接，例如：add_lunch_combo full_lt26-userdebug。/build/envsetup.sh 会扫描所有 device 和 vender 二 级目 录下的名称 为"vendorsetup.sh"文件，并根据其中的内容来确定 lunch 函数的 菜单选项。
在配置了以上的文件之后，便可以编译出我们新添加的设备的系统镜像了。
首先，调用“source build/envsetup.sh”该命令的输出中会看到 Build 系统已经引入了刚刚添加的 vendorsetup.sh 文件。
然后再调用“lunch”函数，该函数输出的列表中将包含新添加的 vendorsetup.sh 中添加的条目。然后通过编号或名称选择即可。
最后，调用“make -j8”来执行编译即可。
添加新的模块
关于“模块”的说明在上文中已经提到过，这里不再赘述。
在 源码树中，一个模块的所有文件通常都位于同一个文件夹中。为了将当前模块添加到整个 Build 系统中，每个模块都需要一个专门的 Make 文件，该文件的名称为“Android.mk”。Build 系统会扫描名称为“Android.mk”的文件，并根据该文件中内容编译出相应的产物。
需 要注意的是：在 Android Build 系统中，编译是以模块（而不是文件）作为单位的，每个模块都有一个唯一的名称，一个模块的依赖对象只能是另外一个模块，而不能是其他类型的对象。对于已经 编译好的二进制库，如果要用来被当作是依赖对象，那么应当将这些已经编译好的库作为单独的模块。对于这些已经编译好的库使用 BUILD_PREBUILT 或 BUILD_MULTI_PREBUILT。例如：当编译某个 Java 库需要依赖一些 Jar 包时，并不能直接指定 Jar 包的路径作为依赖，而必须首先将这些 Jar 包定义为一个模块，然后在编译 Java 库的时候通过模块的名称来依赖这些 Jar 包。
下面，我们就来讲解 Android.mk 文件的编写：
Android.mk 文件通常以以下两行代码作为开头：
LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS)
这两行代码的作用是：
- 设置当前模块的编译路径为当前文件夹路径。
- 清理（可能由其他模块设置过的）编译环境中用到的变量。
为了方便模块的编译，Build 系统设置了很多的编译环境变量。要编译一个模块，只要在编译之前根据需要设置这些变量然后执行编译即可。它们包括：
- LOCAL_SRC_FILES：当前模块包含的所有源代码文件。
- LOCAL_MODULE：当前模块的名称，这个名称应当是唯一的，模块间的依赖关系就是通过这个名称来引用的。
- LOCAL_C_INCLUDES：C 或 C++ 语言需要的头文件的路径。
- LOCAL_STATIC_LIBRARIES：当前模块在静态链接时需要的库的名称。
- LOCAL_SHARED_LIBRARIES：当前模块在运行时依赖的动态库的名称。
- LOCAL_CFLAGS：提供给 C/C++ 编译器的额外编译参数。
- LOCAL_JAVA_LIBRARIES：当前模块依赖的 Java 共享库。
- LOCAL_STATIC_JAVA_LIBRARIES：当前模块依赖的 Java 静态库。
- LOCAL_PACKAGE_NAME：当前 APK 应用的名称。
- LOCAL_CERTIFICATE：签署当前应用的证书名称。
- LOCAL_MODULE_TAGS：当前模块所包含的标签，一个模块可以包含多个标签。标签的值可能是 debug, eng, user，development 或者 optional。其中，optional 是默认标签。标签是提供给编译类型使用的。不同的编译类型会安装包含不同标签的模块，关于编译类型的说明如表 7 所示：
-
表 7. 编译类型的说明
名称 说明 eng 默认类型，该编译类型适用于开发阶段。
当选择这种类型时，编译结果将：- 安装包含 eng, debug, user，development 标签的模块
- 安装所有没有标签的非 APK 模块
- 安装所有产品定义文件中指定的 APK 模块
user 该编译类型适合用于最终发布阶段。
当选择这种类型时，编译结果将：- 安装所有带有 user 标签的模块
- 安装所有没有标签的非 APK 模块
- 安装所有产品定义文件中指定的 APK 模块，APK 模块的标签将被忽略
userdebug 该编译类型适合用于 debug 阶段。
该类型和 user 一样，除了：- 会安装包含 debug 标签的模块
- 编译出的系统具有 root 访问权限
表 3 中的文件已经定义好了各种类型模块的编译方式。所以要执行编译，只需要引入表 3 中对应的 Make 文件即可（通过常量的方式）。例如，要编译一个 APK 文件，只需要在 Android.mk 文件中，加入“
include $(BUILD_PACKAGE)除此以外，Build 系统中还定义了一些便捷的函数以便在 Android.mk 中使用，包括：
$(call my-dir)：获取当前文件夹路径。$(call all-java-files-under, <src>)：获取指定目录下的所有 Java 文件。$(call all-c-files-under, <src>)：获取指定目录下的所有 C 语言文件。$(call all-Iaidl-files-under, <src>)：获取指定目录下的所有 AIDL 文件。$(call all-makefiles-under, <folder>)：获取指定目录下的所有 Make 文件。$(call intermediates-dir-for, <class>, <app_name>, <host or target>, <common?> )：获取 Build 输出的目标文件夹路径。-
清单 2 和清单 3 分别是编译 APK 文件和编译 Java 静态库的 Make 文件示例：
清单 2. 编译一个 APK 文件
LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) # 获取所有子目录中的 Java 文件 LOCAL_SRC_FILES := $(call all-subdir-java-files) # 当前模块依赖的静态 Java 库，如果有多个以空格分隔 LOCAL_STATIC_JAVA_LIBRARIES := static-library # 当前模块的名称 LOCAL_PACKAGE_NAME := LocalPackage # 编译 APK 文件 include $(BUILD_PACKAGE)
清单 3. 编译一个 Java 的静态库
LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) # 获取所有子目录中的 Java 文件 LOCAL_SRC_FILES := $(call all-subdir-java-files) # 当前模块依赖的动态 Java 库名称 LOCAL_JAVA_LIBRARIES := android.test.runner # 当前模块的名称 LOCAL_MODULE := sample # 将当前模块编译成一个静态的 Java 库 include $(BUILD_STATIC_JAVA_LIBRARY)
120
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
