欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

Android 6.0中的Makefile

程序员文章站 2024-01-22 07:59:34
...

本文基于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文件,主要分成三部分:

  1. 核心组件,全部在build/core/目录下。
    这里的几十个mk文件,是编译系统的核心内容,定义了编译流程的框架。
  2. 产品组件,出现在build/target/device/vendor/目录中。
    这部分的主要入口是AndroidProducts.mk文件,功能是指定一些产品独特的内容。这些额外的组件,会随着编译前lunch PRODUCT的PRODUCT参数而改变。
  3. 模块组件,入口为各个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-dirall-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-armaosp-arm64等PRODUCT。而get-all-product-makefiles则是在项目的device/vendor/两个目录下,查找6层以内的所有AndroidProducts.mk文件。

它include的三个文件,与definitions.mk类似,分别定义一些函数。比如,product.mk中定义了get-product-makefilescheck-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年,开始退场。

参考