在之前的公司参与项目开发的时候，虽然不负责系统固件编译脚本的维护，但为了工作的过程中更加的顺利，便学习了一下Android的Build系统。本文就是对之前的学习做个总结。

• 系统版本：AOSP 5.1.1

1. Android Build 系统核心

Android Build系统的核心位于源码目录的build/core，该目录下有几十个mk文件以及若干个shell脚本。

通常是使用下面的命令来编译Android系统：

$ . build/envsetup.sh
$ lunch
$ make

• envsetup.sh 文件的作用

该脚本会建立Android的编译环境，该脚本中，定义了很多的shell命令，比如m、mm、mmm和lunch等命令就是在该脚本中定义的，如图：

image.png

除了命令的定义外，来看看运行envsetup.sh脚本实际执行的代码：

image.png

image.png

可以看到，envsetup.sh有两段代码会执行：

• 中间的6条add_lunch_combo命令的调用
• 结尾处的在device和vendor目录下搜索vendorsetup.sh文件

这里以mako产品为例(对应Nexus 4手机)，看一下device/lge/mako目录下的vendorsetup.sh的内容：

image.png

可以看到它仍然是调用了add_lunch_combo命令。这样看来，build/core/envsetup.sh 除了定义shell命令外，就是执行add_lunch_combo命令而已。它的定义也是在envsetup.sh中，如下：

image.png

add_lunch_combo命令的功能就是将调用该命令的参数存放到一个全局数组变量LUNCH_MENU_CHOICES中。
执行lunch命令时的打印出来的菜单项正是这个数组的内容。

envsetup.sh脚本定义了一些挺有用的命令，如下表：

• lunch命令

lunch命令如果没有参数，系统会打印出产品列表供选择。lunch命令也可以有参数，格式为：lunch <product_name>-<build_variant>
参数前半部分的 "product_name"必须是系统中已经定义的产品名称，后半部分的 "build_variant" 必须是 "eng"、"userdebug" 和 "user" 三者之一。

lunch命令的主要功能是根据用户输入或选择的产品名来设置与之相关的环境变量。这些环境变量与产品编译相关的，主要有下面三项：

• TARGET_PRODUCT：对应 “product_name”;
• TARGET_BUILD_VARIANT：对应 "build_variant";
• TARGET_BUILD_TYPE：一般是release。

• 与编译相关的环境变量

执行lunch命令后，系统会打印出当前配置所生成的环境变量。比如选择 full_mako-eng后，打印如下信息：

image.png

如上图，这些环境变量将影响编译过程，其中：

• PLATFORM_VERSION_CODENAME：表示平台版本的名称
• PLATFORM_VERSION：Android平台的版本号
• TARGET_PRODUCT：所编译的产品名称
• TARGET_BUILD_VARIANT：表示编译的产品的类型。可能的值有：eng、user和userdebug
• TARGET_BUILD_TYPE：表示编译的类型，可选的值是：release和debug。当选择debug版时，编译系统会加入调试信息，方便追踪底层的bug。
• TARGET_BUILD_APPS：编译Android系统时，该变量的值为NULL。使用Build系统编译单个模块时，这个变量的值是所编译模块的路径。
• TARGET_ARCH：表示编译目标的CPU架构
• TARGET_ARCH_VARIANT：表示编译目标的CPU架构版本
• TARGET_CPU_VARIANT：表示编译目标的CPU代号
• TARGET_2ND_ARCH：表示编译目标的第二CPU架构
• TARGET_2ND_ARCH_VARIANT：表示编译目标的第二CPU架构版本
• TARGET_2ND_CPU_VARIANT：表示编译目标的第二CPU的代号
• HOST_ARCH：表示编译平台的CPU架构
• HOST_OS：表示编译平台使用的操作系统
• HOST_OS_EXTRA：编译平台操作系统的一些其他信息，如内核版本号，产品名称和系统代号。
• BUILD_ID：BUILD_ID的值会出现在编译的版本信息中，可以利用这个环境变量来定义公司特有的标识
• OUT_DIR：指定编译结果的输出目录

这些变量中，TARGET_2ND_ARCH、TARGET_2ND_ARCH_VARIANT和TARGET_2ND_CPU_VARIANT是Android 5.0新增加的。当系统运行在64位环境时，考虑到还要支持32位的应用，因此这里定义了两套CPU架构.

• Build相关脚本的层次包含关系

下图显示了Build系统中编译脚本的包含关系，图中不带路径的文件都位于build/core下，同时 combo 目录和 clang目录也都位于 build/core目录下，而device目录位于系统源码根目录下。

main.png

Build系统会在其中的 $(TOP)/*/Android.mk、device/*/AndroidProducts.mk 和 device/*/BroadConfig.mk 三处地方引入具体的产品配置文件AndroidProduct.mk和BroadConfig.mk，以及各个模块的编译文件Android.mk。

combo目录下的这些mk文件定义了gcc编译器的版本和参数
clang目录下的mk文件定义了LLVM的编译器clang的版本和参数

下表罗列了Build系统各编译脚本的简介：

Android Build系统中定义了大量的编译变量，通过改变这些编译变量的值就能控制整个编译过程和结果。产品的配置文件实际上是对这些编译变量赋值的脚本文件。学习Android Build系统很大程度上是在了解这些编译变量的含义和用法。

2. Android的产品配置文件

产品配置文件的作用就是按照Build系统的要求，将生成产品的各种image文件所需要的配置信息(如版本号、各种参数等)、资源(图片、字体、铃声等)、二进制文件(apk、jar包、so库等)有机地组织起来，同时进行裁剪，加入或去掉一些模块。

Android的产品配置文件位于系统源码根目录的device目录下，但产品配置文件也可以放在vendor目录下。这两个目录从Build系统的角度看没有太大的区别，Build系统中搜寻产品配置的关联文件时会同时在这两个目录进行，但实际使用时，往往会让这两个目录配合使用，通常产品配置文件放在device目录下，而vendor目录下则存放一些硬件的HAL库。比如我给Nexus 4手机编译固件之前，会从Google官方的相关站点下载适用于Nexus 4手机的不开源的那些HAL库、驱动，并将其放在系统源码根目录下并释放出放在vendor目录下。

• 与mako相关的配置文件

通常device目录下有以下几个子目录：

• common：用来存放各个产品通用的配置脚本、文件等
• sample：一个产品配置的例子，写一个新的产品配置时可以使用sample目录下的文件作为模板
• google：用途不详
• generic：存放的是用于模拟器的产品，包括x86、arm、mips架构
• asus、lge、samsung：分别代表宏碁、LG、三星3家公司。各家产品放在对应的目录下。

如果需要添加新的产品，可在device目录下新建一个目录。

mako手机(Nexus 4) 是由LG代工的，所以它的产品配置文件位于lge目录下，内容如下：

• mako：存放 Google Nexus4(mako) 的产品配置文件。
• mako-kernel：存放的是mako kernel的二进制文件
• hammerhead：存放Google Nexus5(hammerhead) 的产品配置文件。
• hammerhead：存放的是 hammerhead kernel的二进制文件。

下面简单说一下 device/lge/mako目录下与Build系统相关的几个产品配置的关键文件：

• vendorsetup.sh
  该文件在初始化编译环境时被envsetup.sh文件包含进去。它作用是调用add_lunch_combo命令来添加产品名称串。

• AndroidProduct.mk
  AndroidProduct.mk会在Build系统的ProductConfig.mk文件中被包含进去，这个文件最重要的作用是定义了一个变量 PRODUCT_MAKEFILES，它定义了本配置目录中所有编译入口文件，但每种产品编译时只会使用其中之一。

• BoardConfig.mk
  BoardConfig.mk文件会被Build系统的envsetup.sh文件包含进去。该文件主要定义了和设备硬件(包括CPU、WIFI、GPS等)相关的一些参数。

• device.mk
  device.mk是产品配置中经常需要修改的一个文件。产品定义中需要包含进的模块、文件以及各种环境变量的定义一般都放在这个文件里。

device.mk中一些重要的编译变量说明如下：
(1) PRODUCT_COPY_FILES：一个格式为"源文件路径：目标文件路径" 字符串的组合。使用PRODUCT_COPY_FILES变量能方便地将编译目录下的一个文件复制到目标文件系统中。需要注意的是，PRODUCT_COPY_FILES仅仅复制文件。如果复制的是apk或者Java库，这些文件的签名会保留。

(2) PRODUCT_PACKAGES：用来定义产品的模块列表，所有在模块列表中的模块的定义都会被执行。
(3) PRODUCT_AAPT_CONFIG：指定了系统中能够被支持的屏幕密度类型(dip)。所谓支持，是指系统编译时，会将相应的资源文件添加到framework_res.apk文件中。
(4) PRODUCT_AAPT_PREF_CONFIG：指定系统实际的屏幕密度类型。
(5) DEVICE_PACKAGE_OVERLAYS：这是一个很重要的变量，它指定了系统的overlay目录。系统编译时会使用overlay目录下存放的资源文件替换系统或模块原有的资源文件。这样在不覆盖原生资源文件的情况下，就能实现产品的个性化。而且overlay的目录可以有多个，它们会按照在变量中的先后顺序来替换资源文件，利用这个特性可以定义公共的overlay目录，以及各个产品专属的overlay目录，最大限度地重用资源文件。
(6) PRODUCT_PROPERTY_OVERRIDES：定义系统的属性值。如果属性名称以 "ro." 开头，那这个属性就是只读属性。一旦设置，属性值将不能改变。如果属性名称以 "persist."开头，则当设置这个属性时，它的值将写入文件/data/property中。

• 编译类型 eng、user和userdebug

(1) eng

缺省的编译类型。执行 "make" 相当于执行 "make eng"
编译时会将下列模块安装到系统：

• 在Android.mk 中用 LOCAL_MODULE_TAGS 变量定义了标签：eng、debug、shell_$(TARGET_SHELL)、user和development 的模块
• 非APK模块并且不带任何标签的模块
  所有产品配置文件中指定的APK模块

编译的系统带有如下属性：

• ro.secure=0
• ro.debuggable=1
• ro.kernel.android.checkjni=1

编译的系统中缺省情况下adb是可用的

(2) user

编译时会将下列模块安装到系统：

• 在Android.mk 中用 LOCAL_MODULE_TAGS 变量定义了标签：shell_$(TARGET_SHELL)、user的模块
• 非APK模块并且不带任何标签的模块
  所有产品配置文件中指定的APK模块，同时忽略其标签属性

编译的系统带有如下属性：

• ro.secure=1
• ro.debuggable=0

编译的系统中缺省情况下adb是不可用的，需要在系统设置中手动开启

(3) userdebug

编译时会将下列模块安装到系统：

• 在Android.mk 中用 LOCAL_MODULE_TAGS 变量定义了标签：shell_$(TARGET_SHELL)、debug和user的模块
• 非APK模块并且不带任何标签的模块
  所有产品配置文件中指定的APK模块，同时忽略其标签属性

编译的系统带有如下属性：

• ro.secure=1
• ro.debuggable=1

编译的系统中缺省情况下adb是不可用的，需要在系统设置中手动开启

3. 编译Android的模块

Android中的各种模块，无论是APK应用、可执行程序还是jar包，都可以通过Build系统编译生成。在每个模块的源码目录下，都有一个Android.mk文件，里面包含了模块代码的位置、模块的名称、需要链接的动态库等一系列的定义。

这里以 package/apps/Settings 目录下的 Android.mk文件为例：

image.png

• 模块的编译变量

Android.mk 文件能编译出不同的模块，是通过包含某个模块编译文件实现的，如上面例子中的 include $(BULID_PACKAGE) 。Android的Build系统定义了很多模块编译变量，如下表：

• 常用模块的定义示例

(1) 编译一个apk文件

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)

LOCAL_JAVA_LIBRARIES :=                      # 指定依赖的共享Java类库
LOCAL_STATIC_JAVA_LIBRARIES :=        # 指定依赖的静态Java类库

# 指定源码列表。这里使用系统定义的函数搜寻src目录下的文件形成列表
LOCAL_SRC_FILES := $(call all-java-files-under, src)

LOCAL_MODULE_TAGS := optional        #指定模块的标签
LOCAL_CERTIFICATE := shared             #指定模块的签名方式
LOCAL_PACKAGE_NAME := testapk      # 指定模块的名称
include $(BUILD_PACKAGE)

(2) 编译一个Java共享库

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)

LOCAL_SRC_FILES := $(call all-java-files-under, src)
LOCAL_MODULE_TAGS := optional           # 指定模块的标签
LOCAL_MODULE := javadynamiclib           # 指定模块的名称
include $(BUILD_JAVA_LIBRARY)

(3) 编译一个Java静态库

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)

LOCAL_SRC_FILES := $(call all-java-files-under, src)
LOCAL_MODULE := javastaticlib            # 指定模块的名称
include $(BUILD_STATIC_JAVA_LIBRARY)

(4) 编译一个Java资源包文件

资源包也是一个apk文件，但没有代码，类似 framework_res.apk

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)

LOCAL_NO_STANDARD_LIBRARIES := true       # 指定依赖的静态Java类库
LOCAL_PACKAGE_NAME := javareslib                #  定义模块名
LOCAL_CERTIFICATE := platform                        # 指定签名类型
LOCAL_AAPT_FLAGS := -x                                  # 定义AAPT工具参数
LOCAL_MODULE_TAGS := user                          # 定义模块标签为user
LOCAL_MODULE_PATH := $(TARGET_OUT_JAVA_LIBRARIES)  #指定模块的安装路径

LOCAL_EXPORT_PACKAGE_RESOURCES := true   #为true时，其他的apk模块能引用本模块的资源
include $(BUILD_PACKAGE)

(5) 编译一个可执行文件

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_SRC_FILES := service.cpp
LOCAL_SHARED_LIBRARIES := libutils libbinder  #指定模块需要链接的动态库
ifeq ($(TARGET_OS), linux)
    LOCAL_CFLAGS += -DXP_UNIX          #定义编译标志
endif
LOCAL_MODULE := service                    #指定模块的名称
include $(BUILD_EXECUTABLE)            #指定模块的名称

(6) 编译一个native 的共享库

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE_TAGS := optional
LOCAL_MODULE := libnativedynamic           # 指定模块的名称
LOCAL_SRC_FILES := \                                # 指定模块的源文件
          nativedynamic.cpp
LOCAL_SHARED_LIBRARIES := \               # 指定模块需要链接的动态库
          libcutils \
          libutils

LOCAL_STATIC_LIBRARIES := libnativestatic            # 指定模块依赖的静态库
LOCAL_C_INCLUDES += \                                          # 指定头文件的查找路径
       $(JNI_H_INCLUDE) \
       $(LOCAL_PATH)/../include
LOCAL_CFLAGS += -O                                             # 定义编译标志
include $(BUILD_SHARED_LIBRARY)

(7) 编译一个native静态库

LOCAL_PATH := $(call my-dir)
include $(CLEAR_VARS)

LOCAL_MODULE_TAGS := optional           #指定模块的标签
LOCAL_MODULE := libnativestatic             #指定模块的名称
LOCAL_SRC_FILES := \                             #指定模块的源文件
       nativestatic.cpp
LOCAL_C_INCLUDES +=  
        LOCAL_CFLAGS += -o                       #定义编译标志

include $(BUILD_STATIC_LIBRARY)

• 预编译模块的目标定义

在实际的系统开发中，并不会像Android一样将所有源码集中在一起编译，有很多APK文件，jar包等都是预先编译好的，编译系统时需要将这些二进制文件复制到生成的image文件中。

常用的方法是通过 PRODUCT_COPY_FILES 变量将这些文件直接复制到生成的image文件中。但有些APK文件或jar包，需要使用系统的签名文件才能正常运行，这样用复制的方式就行不通了。另外，一些动态库文件可能是源码中的某些模块所依赖的，用复制的方法也无法建立依赖关系，这将导致这些模块编译失败。

Android 可通过定义预编译模块的方式来解决上述问题。

定义一个预编译模块和定义一个普通的编译模块格式相似。不同的是LOCAL_SRC_FILES 变量指定的不是源文件，而是二进制文件的路径，同时还要通过 LOCAL_MODULE_CLASS 来指定模块的类型，最后 include 的是 BUILD_PREBUILT 变量定义的编译文件。

下面是常见预编译模块的示例：
(1) 定义apk文件目标

include $(CLEAR_VARS)
LOCAL_MODULE := ThemeManager.apk   #这里可以是任何字符串，但必须是系统唯一的目标
LOCAL_SRC_FILES := app/$(LOCAL_MODULE)
LOCAL_MODULE_TAGS := optional
LOCAL_MODULE_CLASS := APPS                    #这里的值是APPS
LOCAL_CERTIFICATE := platform                      #这里可以指定签名方式
include $(BUILD_PREBUILT)

(2) 定义静态jar包目标

include $(CLEAR_VARS)
LOCAL_MODULE := libfirewall.jar
LOCAL_SRC_FILES := app/$(LOCAL_MODULE)
LOCAL_MODULE_TAGS := optional
LOCAL_MODULE_CLASS := JAVA_LIBRARIES         #这里的值是JAVA_LIBRARIES
LOCAL_CERTIFICATE := platform
include $(BUILD_PREBUILT)

(3) 定义动态库文件目标

include $(CLEAR_VARS)
LOCAL_MODULE := libglobaltheme_jni.so
LOCAL_MODULE_OWNER :=
LOCAL_SRC_FILES := lib/$(LOCAL_MODULE)
LOCAL_MODULE_TAGS := optional
LOCAL_MODULE_CLASS := SHARED_LIBRARIES        # 这里的值是SHARED_LIBRARIES
include $(BUILD_PREBUILT)

(4) 定义可执行文件目标

include $(CLEAR_VARS)
LOCAL_MODULE := bootanimation
LOCAL_MODULE_OWNER :=
LOCAL_SRC_FILES := bin/bootanimation
LOCAL_MODULE_TAGS := optional
LOCAL_MODULE_CLASS := EXECUTABLES   #这里的值是EXECUTABLES
LOCAL_MODULE_PATH := $(TARGET_OUT)/bin         #还可以指定复制到的目标目录
include $(BUILD_PREBUILT)

(5) 定义xml文件目标

include $(CLEAR_VARS)
LOCAL_MODULE := apns-conf-cu.xml
LOCAL_MODULE_OWNER :=
LOCAL_SRC_FILES := etc/$(LOCAL_MODULE)
LOCAL_MODULE_TAGS := optional
LOCAL_MODULE_CLASS := ETC               # ETC表示文件将复制到/system/etc 目录下
include $(BUILD_PREBUILT)

(6) 定义host平台下的jar包

这例子挺有意思的，将系统编译时用到的 signapk.jar 预编译，然后复制到out目录下，这样Build系统将能够使用这个文件来给其他文件签名：

include $(CLEAR_VARS)
LOCAL_MODULE := signapk
LOCAL_PREBUILT_JAVA_LIBRARIES := lib/$(LOCAL_MODULE).jar
include $(BUILD_HOST_PREBUILT)

该例子中除了使用 BUILD_HOST_PREBUIT 表示目标定义是针对编译平台而不是设备平台外，还给出了定义预编译jar包模块的另外一种定义方式，即使用变量 LOCAL_PREBUILT_JAVA_LIBRARIES 来定义。

• 常用的 "LOCAL_" 变量

编写模块的编译文件，实际就是定义一系列以 "LOCAL_" 开头的编译变量，下表罗列了一些经常使用的编译变量和说明：

参考

http://gityuan.com/2016/03/19/android-build/
https://blog.csdn.net/luoshengyang/article/details/18928789
https://www.jianshu.com/p/4a6d8c0e034a
https://www.ibm.com/developerworks/cn/opensource/os-cn-android-build/index.html
https://source.android.com/setup/develop/64-bit-builds
《深入解析Android 5.0系统》