理解Android Build系统
理解Android Build系统
Android源码的一部分
前言
Android Build系统是Android源码的一部分。关于如何获取Android源码，请参照Android Source官方网站。
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,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文件之一。该文件中主要包含以下内容：1.定义了许多的常量来负责不同类型模块的编译。2.定义编译器参数以及常见文件后缀，例如.zip,.jar,.apk。3.根据BoardConfig.mk文件，配置产品相关的参数。4.设置一些常用工具的路径，例如flex，e2fsck，dx。 |
| 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是一个变量，当使用"mm"编译某个目录下的模块时，此变量的值即为当前指定路径下的Make文件的路径。 |
| $ | 各个模块的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所示：
| 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内容。 |
| make framework | 编译所有Java framework内容。 |
| make services | 编译系统服务和相关内容。 |
| make | 编译一个指定的模块，local_target为模块的名称。 |
| make clean- | 清理一个指定模块的编译结果。 |
| make dump-products | 显示所有产品的编译配置信息，例如：产品名，产品支持的地区语言，产品中会包含的模块等信息。 |
| make PRODUCT-xxx-yyy | 编译某个指定的产品。 |
| make bootimage | 生成boot.img |
| make recoveryimage | 生成recovery.img |
| make userdataimage | 生成userdata.img |
| make cacheimage | 生成cache.img |
在Build系统中添加新的内容
添加新的产品
当我们要开发一款新的Android产品的时候，我们首先就需要在Build系统中添加对于该产品的定义。
在Android Build系统中对产品定义的文件通常位于device目录下（另外还有一个可以定义产品的目录是vendor目录，这是个历史遗留目录，Google已经建议不要在该目录中进行定义，而应当选择device目录）。device目录下根据公司名以及产品名分为二级目录，这一点我们在概述中已经提到过。
通常，对于一个产品的定义通常至少会包括四个文件：AndroidProducts.mk，产品版本定义文件，BoardConfig.mk以及vendorsetup.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_MANUFACTUER | 制造商的名称。 |
| 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和vendor二级目录下的名称为“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_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_PAKAGE_NAME: 当前APK应用的名称。
- LOCAL_CERTIFICATE: 签署当前应用的证书名称。
- LOCAL_MODULE_TAGS: 当前模块所包含的标签，一个模块可以包含多个标签。标签的值可能是debug，eng，user，development或者optional。其中，optional是默认标签。标签是提供给编译类型使用的。不同的编译类型会安装包含不同标签的模块，关于编译类型的说明如表7所示：
表7.编译类型的说明
名称|说明
- | -
eng|默认类型，该编译类型适用于开发阶段。当选择这种类型时，编译结果将：1.安装包含eng，debug，user，development标签的模块 2.安装所有没有标签的非APK模块 3.安装所有产品定义文件中指定的APK模块
user|该编译类型适合用于最终发布阶段。当选择这种类型时，编译结果将：1.安装所有带有user标签的模块 2.安装所有没有标签的非APK模块 3.安装所有产品定义文件中指定的APK模块，APK模块的标签将被忽略
userdebug|该编译类型适合用于debug阶段。该类型和user一样，除了：1.会安装包含debug标签的模块 2.编译出的系统具有root访问权限
表3中的文件已经定义好了各种类型模块的编译方式。所以要执行编译，只需要引入表3中对应的Make文件即可（通过常量的方式）。例如，要编译一个APK文件，只需要在Android.mk文件中，加入“include $(BUILD_PACKAGE)”
除此以外，Build系统中还定义了一些便捷的函数以便在Android.mk中使用，包括：
- $(call my-dir): 获取当前文件夹路径。
- $(call all-java-files-under,
): 获取指定目录下的所有Java文件。 - $(call all-c-files-under,
): 获取指定目录下的所有C语言文件。 - $(call all-Iaidl-files-under,
): 获取指定目录下的所有AIDL文件。 - $(call all-makefiles-under,
): 获取指定目录下的所有Make文件。 - $(call intermediates-dir-for,
, <app_name>, , <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)
结束语
整个Build系统包含了非常多的内容，由于篇幅所限，本文只能介绍其中最主要内容。
由于Build系统本身也是在随着Android平台不断的开发过程中，所以不同的版本其中的内容和定义可能会发生变化。网络上关于该部分的资料很零碎，并且很多资料中的一些内容已经过时不再适用，再加上缺少官方文档，所以该部分的学习存在一定的难度。
这就要求我们要有很强的代码阅读能力，毕竟代码是不会说谎的。要知道，对于我们这些开发人员来说，源代码就是我们最忠实的朋友。Use the Source，Luke！
浙公网安备 33010602011771号