本文基于AOSP的android-6.0.1_r9分支，介绍Android平台编译系统中的Makefile。
（本文转载自本人的个人网站，谢绝二次转载。原文链接：http://note.qidong.name/2017/08/android-6.0-makefile/）
简介
之所以选android-6.0.1_r9这个分支，是因为这是最后一个纯Makefile的大版本。后面随着时间的发展，Android项目变得越来越庞大，纯Makefile编译系统已经越来越不堪使用。使用Makefile，不仅扩展不便，而且执行效率也不太高。从7.0版本开始，Android已经开始用Ninja来替代Makefile。
6.0版本，是Makefile最后的辉煌。Android平台的编译系统，其实就是用Makefile写出来的一个独立项目。这个项目，不仅把分散在数百个Git库中的代码整合起来、统一编译，而且还把产物分门别类地输出到一个目录，打包成手机ROM，更能产生应用开发时所使用的SDK、NDK、网页文档等。以前，从来没有这么大规模的一个手写Makefile项目，以后应该也不会再有了。
在大、中型项目都普遍使用高级工具来生成Makefile的时候，Android竟然还是手写Makefile。现在看来，这也是一件咄咄怪事。
主要文件
在Android项目根目录，都有一个Makefile文件，其核心内容只有一行。
### DO NOT EDIT THIS FILE ###
include build/core/main.mk
### DO NOT EDIT THIS FILE ###
所以，build/core/main.mk就是Android真正的Makefile入口。
在Android 6.0以前，主要的Makefile都在build/core目录下。在Android 7.0以后，全部调整到了build/make/core中，因为build目录下，又新增了kati、soong、blueprint等项目的目录。
Android的编译系统的Makefile文件，主要分成三部分：
-
核心组件，全部在
build/core/目录下。
这里的几十个mk文件，是编译系统的核心内容，定义了编译流程的框架。 -
产品组件，出现在
build/target/、device/或vendor/目录中。
这部分的主要入口是AndroidProducts.mk文件，功能是指定一些产品独特的内容。这些额外的组件，会随着编译前lunch PRODUCT的PRODUCT参数而改变。 - 模块组件，入口为各个Git库的Android.mk。
这是普通平台开发者最熟悉的文件，其中定义了一个模块的必要参数，使模块跟随平台编译。
本文只分析核心组件中的结构，以及build/core/下的一些重要文件。
核心组件
结构
build/core/main.mk
├── help.mk
├── config.mk
│ ├── pathmap.mk
│ ├── envsetup.mk
│ │ ├── version_defaults.mk
│ │ └── product_config.mk
│ │ ├── node_fns.mk
│ │ ├── product.mk
│ │ └── device.mk
│ ├── combo/select.mk
│ ├── ccache.mk
│ ├── combo/javac.mk
│ ├── clang/config.mk
│ │ ├── clang/HOST_$(HOST_2ND_ARCH).mk
│ │ ├── clang/HOST_$(HOST_ARCH).mk
│ │ ├── clang/TARGET_$(TARGET_2ND_ARCH).mk
│ │ └── clang/TARGET_$(TARGET_ARCH).mk
│ └── dumpvar.mk
├── cleanbuild.mk
│ └── cleanspec.mk
├── definitions.mk
│ └── distdir.mk
├── dex_preopt.mk
│ └── dex_preopt_libart.mk
│ └── dex_preopt_libart_boot.mk
├── pdk_config.mk
├── post_clean.mk
├── legacy_prebuilts.mk
└── Makefile
├── sdk_font.mk
└── tasks/*.mk
以上结构代表main.mk中对其它Makefile的include关系。排列顺序，大致依照文件中include的顺序，但要注意，Makefile的排列顺序不一定代表执行顺序。
这个图中仅列出了build/core目录下的文件，不包括其它目录下被包含的mk文件。并且，build/core目录下总计近百个mk文件，这里也未列出没被包含到main.mk中的那些。
部分文件说明
| 文件 | 作用 |
|---|---|
| main.mk | make命令入口，是整个Android编译系统最核心的文件。 |
| help.mk | 在执行make help时打印几个主要的Target信息。 |
| config.mk | 定义了编译过程中的环境变量，包括BUILD_*、TARGET_*等。它include的其它mk文件，也是类似作用。 |
| cleanbuild.mk | 定义了完整编译前，清理产物的步骤和内容。 |
| definitions.mk | 定义了大量编译过程中会用到的函数，如my-dir、all-subdir-makefile等。 |
| dex_preopt.mk | 利用dexopt（Dalvik）或dex2oat（ART）对dex进行优化。 |
| pdk_config.mk | 编译PDK（Platform Developement Kit）的产物platform.zip。 |
| post_clean.mk | 针对应用层模块的产物清理。 |
| legacy_prebuilts.mk | 定义了GRANDFATHERED_ALL_PREBUILT变量，指定一些预编译Target。 |
| Makefile | 这是一个功能复杂的文件，可以看做main.mk的延伸。 |
在上述Makefile文件中，还include了tasks/*.mk，其中内容如下：
- apicheck.mk
- boot_jars_package_check.mk
- build_custom_images.mk
- collect_gpl_sources.mk
- cts.mk
- deps_licenses.mk
- ide.mk
- oem_image.mk
- product-graph.mk
- sdk-addon.mk
- vendor_module_check.mk
其作用可以通过文件名来推测，这里不再赘述。
产品组件的相关文件
产品组件的主要入口是AndroidProducts.mk文件，而product_config.mk就是提供相关支持的文件。文件头中，有一段注释：
# Generic functions
# TODO: Move these to definitions.make once we're able to include
# definitions.make before config.make.
可见，这个文件原本只是一个临时的独立文件，但因为历史原因，一直沿用至今。这也体现了这个Makefile编译系统的一些固有缺陷。
其中的核心逻辑如下：
ifneq ($(strip $(TARGET_BUILD_APPS)),)
# An unbundled app build needs only the core product makefiles.
all_product_configs := $(call get-product-makefiles,\
$(SRC_TARGET_DIR)/product/AndroidProducts.mk)
else
# Read in all of the product definitions specified by the AndroidProducts.mk
# files in the tree.
all_product_configs := $(get-all-product-makefiles)
endif
$(SRC_TARGET_DIR)/product/AndroidProducts.mk，就是build/target/product/AndroidProducts.mk，是系统默认自带的文件，内含aosp-arm、aosp-arm64等PRODUCT。而get-all-product-makefiles则是在项目的device/、vendor/两个目录下，查找6层以内的所有AndroidProducts.mk文件。
它include的三个文件，与definitions.mk类似，分别定义一些函数。比如，product.mk中定义了get-product-makefiles、check-all-products等函数，提供了查找AndroidProducts.mk文件、列出所有可以被lunch的PRODUCT参数等功能。
所以，如果要新增一个PRODUCT，只需在device/或vendor/下合适的位置，新增一个AndroidProducts.mk，指定PRODUCT_*的各项参数即可。
Android.mk的相关文件
在build/core/main.mk中，有以下代码：
subdir_makefiles := \
$(shell build/tools/findleaves.py $(FIND_LEAVES_EXCLUDES) $(subdirs) Android.mk)
$(foreach mk, $(subdir_makefiles), $(info including $(mk) ...)$(eval include $(mk)))
这就是查找整个Android项目中所有的Android.mk文件，并且include进来。Android.mk的组合方式，本质上和AndroidProducts.mk并无不同。只是AndroidProducts.mk的范围小一些，而Android.mk则是在整个项目中搜索。
除此之外，build/core/下还有很多mk文件，虽然没有直接被main.mk所include，却会被各种Android.mk所include。比如，clear_vars.mk、package.mk等。
新增一个LOCAL_MODULE，只需要在任意位置新增一个Android.mk，指定LOCAL_*参数即可。篇幅所限，不对此做详细介绍。
其它文件
除了Makefile文件以外，在build/下还包含了其它的工具，主要集中在build/tools/目录下。很多用Makefile做起来不方便的工作，都由它们去做。
这些工具，以Python、Bash脚本为主，也包含部分C语言写的微型项目，比如build/tools/acp/。
总结
我在深入研究Android的编译系统前，从未想过Makefile会有这样壮丽的风景。利用Makefile的依赖管理，构建一个庞大而复杂的编译系统，这无疑是一个令人惊叹的构思。
不过，无论如何，它也快走到了尽头。
如果说Bash的语法，令人难以把握，那么Makefile则更是令人每学每忘。假如早知道要以Makefile为主，Python、Bash、乃至C语言为辅，构建这样一个大型项目，说不定2003年组建之初的Android团队，就不会这样选择。若是以Python作为胶水，粘合各个模块的Makefile，也许能经久不衰。
Google从7.0开始，逐步用各种工具替换Makefile，利弊参半。在编译前用kati来把Makefile转换为Ninja，在实际编译各模块时用Ninja替代Makefile。历时12年，Android中的Makefile终于在2016年，开始退场。
网友评论