Android Build 系统是 Android 系统的一部分,主要用来编译 Android 系统,Android SDK 以及相关文档。该系统主要由 Make 文件,Shell 脚本以及 Python 脚本组成。 Android build 分类:
Android Build 系统核心在目录 build/core,这个目录中有 mk 文件、shell 脚本和 per 脚本,他们构成 Android Build 系统的基础和架构。
在核心的 buil/core 里,系统主要干了三件事情:
常用命令:
- source build/envsetup.sh
- lunch
- make
而在 build/envsetup.sh 中主要完成了三件事:
执行 Android 系统的编译,必须先执行 envsetup.sh 脚本,这个脚本会建立 Android 的编译环境。其具体执行的是建立 shell 命令以及调用 add_lunch_combo 命令,这个命令的将调用该命令的所传递的参数存放到一个全局的数组变量 LUNCH_MENU_CHOICES 中。
envsetup.sh 脚本中定义的常用 shell 命令:
命令 | 说明 |
---|---|
contact-button | 指定当前编译的产品 |
croot | 快速切换到源码的根目录,方便开始编译 |
m | 编译整个源码,但不用将当前的目录切换到源码的根目录 |
mm | 编译当前目录下的所有模块,但是不编译他们的依赖项 |
mm | 编译当前目录下的所有模块,但是不编译他们的依赖项 |
cgrep | 对系统中所有的 C/C++ 文件执行 grep 命令 |
sgrep | 对系统中所有的源文件执行 grep 命令 |
Android 系统的编译环境目前只支持 Ubuntu 以及 Mac OS 两种操作系统。在编译 Android 系统之前我们需要先获取完整的 Android 源码。打开控制台之后转到 Android 源码的根目录,然后执行如下命名:
- source build/envsetup.sh
- lunch full-eng
- make -j8
关于这几条命令的意思,我们上面提过。 第一步命令 "source build/envsetup.sh" 引入了 build/envsetup.sh 脚本,该脚本的作用是初始化编译环境,并引入一些辅助的 Shell 函数;
第二步命令 "lunch full-eng" 是调用 lunch 函数,并指定参数为 "full-eng"。lunch 函数的参数用来指定此次编译的目标设备以及编译类型。
第三部命令 "make -j8" 才真正开始执行编译。make 的参数 "-j" 指定了同时编译的 Job 数量,这是个整数,该值通常是编译主机 CPU 支持的并发线程总数的 1 倍或 2 倍(例如:在一个 4 核,每个核支持两个线程的 CPU 上,可以使用 make -j8 或 make -j16)。 完整的编译时间依赖于编译主机的配置。
所有的编译产物都将位于 /out 目录下,该目录下主要包含:
Build 的产物中最重要的是三个镜像文件,它们都位于 /out/target/product// 目录下:
整个 Build 系统的入口文件是源码树根目录下名称为 "Makefile" 的文件,当在源代码根目录上调用 make 命令时,make 命令首先将读取该文件。 Makefile 文件的内容只有一行:"include build/core/main.mk"。该行代码的作用很明显:包含 build/core/main.mk 文件。在 main.mk 文件中又会包含其他的文件,其他文件中又会包含更多的文件,这样就引入了整个 Build 系统。
在整个 Build 系统中,Make 文件间的关系是相当复杂的。看一张 make 文件主要的关系图:
Make 常用文件:
文件名 | 说明 |
---|---|
main.mk | 主要的 Make 文件,该文件中首先将对编译环境进行检查,同时引入其他的 Make 文件。另外,该文件中还定义了几个最主要的 Make 目标,例如 droid,sdk,等(参见后文 "Make 目标说明")。 |
help.mk | 含了名称为 help 的 Make 目标的定义,该目标将列出主要的 Make 目标及其说明。 |
envsetup.mk | 配置 Build 系统需要的环境变量,例如:TARGET_PRODUCT,TARGET_BUILD_VARIANT,HOST_OS,HOST_ARCH 等。 当前编译的主机平台信息(例如操作系统,CPU 类型等信息)就是在这个文件中确定的。 另外,该文件中还指定了各种编译结果的输出路径。 |
pathmap.mk | 将许多头文件的路径通过名值对的方式定义为映射表,并提供 include-path-for 函数来获取。例如,通过 $(call include-path-for, frameworks-native) 便可以获取到 framework 本地代码需要的头文件路径。 |
combo/select.mk | 根据当前编译器的平台选择平台相关的 Make 文件。 |
dumpvar.mk | 在 Build 开始之前,显示此次 Build 的配置信息。 |
config.mk | 整个 Build 系统的配置文件,最重要的 Make 文件之一。该文件中主要包含以下内容: 定义了许多的常量来负责不同类型模块的编译。 定义编译器参数以及常见文件后缀,例如 .zip,.jar.apk。 根据 BoardConfig.mk 文件,配置产品相关的参数。 设置一些常用工具的路径,例如 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)的配置文件。 |
post_clean.mk | 在前一次 Build 的基础上检查当前 Build 的配置,并执行必要清理工作。 |
legacy_prebuilts.mk | 该文件中只定义了 GRANDFATHERED_ALL_PREBUILT 变量。 |
Makefile | 被 main.mk 包含,该文件中的内容是辅助 main.mk 的一些额外内容。 |
droid 所依赖的其他 Make 目标说明:
![这里写图片描述](http://img.blog.csdn.net/20170402233525703?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQveGlhbmd6aGlob25nOA==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast)
那么需要编译出系统镜像,需要哪些依赖呢?
droid 目标将编译出整个系统的镜像。从源代码到编译出系统镜像,整个编译过程非常复杂。这个过程并不是在 droid 一个目标中定义的,而是 droid 目标会依赖许多其他的目标,这些目标的互相配合导致了整个系统的编译。
如果在源码树的根目录直接调用 "make" 命令而不指定任何目标,则会选择默认目标:"droid"(在 main.mk 中定义)。因此,这和执行 "make droid" 效果是一样的。
### make /make droid
## Make 编译镜像
![这里写图片描述](http://img.blog.csdn.net/20170402232734662?watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQveGlhbmd6aGlob25nOA==/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast)
模块的编译方式定义文件的包含关系:
不同类型的模块的编译过程会有一些相同的步骤,例如:编译一个 Java 库和编译一个 APK 文件都需要定义如何编译 Java 文件。为了减少代码冗余,需要将共同的代码复用起来,复用的方式是将共同代码放到专门的文件中,然后在其他文件中包含这些文件的方式来实现的。
BUILD_HOST_JAVA_LIBRARY
BUILD_STATIC_JAVA_LIBRARY
BUILD_JAVA_LIBRARY
BUILD_HOST_PREBUILT
BUILD_MULTI_PREBUILT
BUILD_PREBUILT
BUILD_PACKAGE
BUILD_HOST_EXECUTABLE
BUILD_EXECUTABLE
BUILD_SHARED_LIBRARY
BUILD_STATIC_LIBRARY
BUILD_HOST_SHARED_LIBRARY
BUILD_HOST_STATIC_LIBRARY
Android 源码中包含了许多的模块,模块的类型有很多种,例如:Java 库,C/C++ 库,APK 应用,以及可执行文件等 。并且,Java 或者 C/C++ 库还可以分为静态的或者动态的,库或可执行文件既可能是针对设备(本文的 "设备" 指的是 Android 系统将被安装的设备,例如某个型号的手机或平板)的也可能是针对主机(本文的 "主机" 指的是开发 Android 系统的机器,例如装有 Ubuntu 操作系统的 PC 机或装有 MacOS 的 iMac 或 Macbook)的。不同类型的模块的编译步骤和方法是不一样,为了能够一致且方便的执行各种类型模块的编译,在 config.mk 中定义了许多的常量,这其中的每个常量描述了一种类型模块的编译方式。常见的有:
名称 | 说明 |
---|---|
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//android-info.txt |
systemimage | 生成 system.img。 |
Build 系统中包含的其他一些 Make 目标:
Make 目标说明 | 说明 |
---|---|
make clean | 执行清理,等同于:rm -rf out/ |
make sdk | 编译出 Android 的 SDK |
Make 目标说明 | 说明 |
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 snod | 从已经编译出的包快速重建系统镜像 |
make libandroid_runtime | 编译所有 JNI framework 内容 |
makeframework | 编译所有 Java framework 内容 |
makeservices | 编译系统服务和相关内容 |
make | 编译一个指定的模块,local_target 为模块的名称 |
make clean- | 清理一个指定模块的编译结果 |
makedump-products | 显示所有产品的编译配置信息,例如:产品名,产品支持的地区语言,产品中会包含的模块等信息 |
makePRODUCT-xxx-yyy | 编译某个指定的产品 |
makebootimage | 生成 boot.img |
编译类型说明:
- LOCAL_MODULE_TAGS:当前模块所包含的标签,一个模块可以包含多个标签。标签的值可能是 debug, eng,user,development 或者 optional。其中,optional 是默认标签。标签是提供给编译类型使用的,不同的编译类型会安装包含不同标签的模块。
- LOCAL_CERTIFICATE:签署当前应用的证书名称。
- LOCAL_PACKAGE_NAME:当前 APK 应用的名称。
- LOCAL_STATIC_JAVA_LIBRARIES:当前模块依赖的 Java 静态库。
- LOCAL_JAVA_LIBRARIES:当前模块依赖的 Java 共享库。
- LOCAL_CFLAGS:提供给 C/C++ 编译器的额外编译参数。
- LOCAL_SHARED_LIBRARIES:当前模块在运行时依赖的动态库的名称。
- LOCAL_STATIC_LIBRARIES:当前模块在静态链接时需要的库的名称。
- LOCAL_C_INCLUDES:C 或 C++ 语言需要的头文件的路径。
- LOCAL_MODULE:当前模块的名称,这个名称应当是唯一的,模块间的依赖关系就是通过这个名称来引用的。
- LOCAL_SRC_FILES:当前模块包含的所有源代码文件。
为了方便模块的编译,Build 系统设置了很多的编译环境变量。要编译一个模块,只要在编译之前根据需要设置这些变量然后执行编译即可。常见的如:
```
include $(CLEAR_VARS)// 清理编译环境中用到的变量
LOCAL_PATH := $(call my-dir) // 设置当前模块的编译路径为当前文件夹路径
```
Android.mk 文件通常以以下两行代码作为开头:
那么怎么编写 Android.mk 文件呢?
在 Android Build 系统中,编译是以模块(而不是文件)作为单位的,每个模块都有一个唯一的名称,一个模块的依赖对象只能是另外一个模块,而不能是其他类型的对象。对于已经编译好的二进制库,如果要用来被当作是依赖对象,那么应当将这些已经编译好的库作为单独的模块。对于这些已经编译好的库使用 BUILD_PREBUILT 或 BUILD_MULTI_PREBUILT。例如:当编译某个 Java 库需要依赖一些 Jar 包时,并不能直接指定 Jar 包的路径作为依赖,而必须首先将这些 Jar 包定义为一个模块,然后在编译 Java 库的时候通过模块的名称来依赖这些 Jar 包。
注:
在源码树中,一个模块的所有文件通常都位于同一个文件夹中。为了将当前模块添加到整个 Build 系统中,每个模块都需要一个专门的 Make 文件,该文件的名称为 "Android.mk"。Build 系统会扫描名称为 "Android.mk" 的文件,并根据该文件中内容编译出相应的产物。
## 添加新模块
来查看 Build 系统已经引入了刚刚添加的 vendorsetup.sh 文件。
```
source build/envsetup.sh
```
我们可以使用命令:
在配置了以上的文件之后,便可以编译出我们新添加的设备的系统镜像了。
该文件中作用是通过 add_lunch_combo 函数在 lunch 函数中添加一个菜单选项。该函数的参数是产品名称加上编译类型,中间以 "-" 连接,例如:add_lunch_combo full_lt26-userdebug。/build/envsetup.sh 会扫描所有 device 和 vender 二 级目 录下的名称 为 "vendorsetup.sh" 文件,并根据其中的内容来确定 lunch 函数的 菜单选项。
## vendorsetup.sh
该文件用来配置硬件主板,它其中定义的都是设备底层的硬件特性。例如:该设备的主板相关信息,Wifi 相关信息,还有 bootloader,内核,radioimage 等信息。
## BoardConfig.mk
```
PRODUCT_MODEL := Full Android on LT26
PRODUCT_BRAND := Android
PRODUCT_DEVICE := lt26
PRODUCT_NAME := full_lt26
# 覆盖其中已经定义的一些变量
$(call inherit-product, $(SRC_TARGET_DIR)/product/full_base.mk)
# 继承 full_base.mk 文件中的定义
```
通常情况下,我们并不需要定义所有这些变量。Build 系统的已经预先定义好了一些组合,它们都位于 /build/target/product 下,每个文件定义了一个组合,我们只要继承这些预置的定义,然后再覆盖自己想要的变量定义即可。
该文件中包含了对于特定产品版本的定义。该文件可能不只一个,因为同一个产品可能会有多种版本。
## 产品版本定义文件
```
$(LOCAL_DIR)/generic_stingray.mk
$(LOCAL_DIR)/stingray_emu.mk \
$(LOCAL_DIR)/full_stingray.mk \
PRODUCT_MAKEFILES := \
```
该文件只需要定义一个变量,名称为 "PRODUCT_MAKEFILES"。
## AndroidProducts.mk
通常,对于一个产品的定义通常至少会包括四个文件:AndroidProducts.mk,产品版本定义文件,BoardConfig.mk 以及 verndorsetup.sh。
当我们要开发一款新的 Android 产品的时候,我们首先就需要在 Build 系统中添加对于该产品的定义。在 Android Build 系统中对产品定义的文件通常位于 device 目录下,device 目录下可以公司名以及产品名分为二级目录,然后加入到系统中,如以前小米等基于 Android 深度定制的系统。
# 定制 Build 系统中内容
名称 | 说明 |
---|---|
eng | 默认类型,该编译类型适用于开发阶段。 当选择这种类型时,编译结果将: 安装包含 eng, debug, user,development 标签的模块 安装所有没有标签的非 APK 模块 安装所有产品定义文件中指定的 APK 模块 |
user | 该编译类型适合用于最终发布阶段。 当选择这种类型时,编译结果将: 安装所有带有 user 标签的模块 安装所有没有标签的非 APK 模块 安装所有产品定义文件中指定的 APK 模块,APK 模块的标签将被忽略 |
userdebug | 该编译类型适合用于 debug 阶段。 该类型和 user 一样,除了: 会安装包含 debug 标签的模块 编译出的系统具有 root 访问权限 |
根据上表各种类型模块的编译方式,要执行编译,只需要引入表 3 中对应的 Make 文件即可。例如,要编译一个 APK 文件,只需要在 Android.mk 文件中,加入 "include $(BUILD_PACKAGE)。 除此以外,Build 系统中还定义了一些便捷的函数以便在 Android.mk 中使用,包括:
如:编译一个 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)
编译一个 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)
附:Android 编译系统详解
来源: https://yq.aliyun.com/articles/73256