Android系统源码Build系统入门详解

那么我们就以上列出的文件，一个个找添加依赖的方法，为了更清晰的了解我们要做什么，我们先来研究一下我们在eclipse开发第一个hello-jni的时候写过的Android.mk，这个大概是大部分同学接触的第一个mk文件了吧？因此我们先研究一下Jni下的Android.mk。

包含C的Android.mk

以最简单的Android.mk为例，就是说这个创建的时候啥都没有，脑补一下你刚刚学习安卓的时候写的那个helloworld，没错没错，就是他了，现在要求你的helloworld写在系统源码里面，那么就需要一个包含以下内容的mk文件（不要再偷懒了，这已经是最简化的了）：

LOCAL_PATH := $(call my-dir)include $(CLEAR_VARS)LOCAL_MODULE    := hello-jniLOCAL_SRC_FILES := hello-jni.cinclude $(BUILD_SHARED_LIBRARY)

别着急，一条一条分析：

第一行

LOCAL_PATH := $(call my-dir)

每个Android.mk文件必须以定义LOCAL_PATH为开始。它用于在开发tree中查找源文件。
宏my-dir 则由Build System提供。返回包含Android.mk的目录路径。

那么具有批判性思维的同学要问了，这个LOCAL_PATH是个什么鬼，:=是什么鬼，$(call my-dir)又是什么鬼？还有这个my-dir又是怎么来的，为什么不是he-dir或者是she-dir。

”:=“这冒号等号看上去是赋值的意思吧？
小伙子真机智，你又答对了！

“$(XXX)”这大概是取值把，比如上面的意思就是取系统变量LOCAL_PATH ？
真机智，你又答对了！

这个问题问得好，我们一个个找答案。

LOCAL_PATH ：根据我们以往的开发经验，这种大写的带下划线的变量一般是编译环境变量，事实上为了方便模块的编译，Build 系统设置了很多的编译环境变量。要编译一个模块，只要在编译之前根据需要设置这些变量然后执行编译即可。它们包括：

• LOCAL_SRC_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_PACKAGE_NAME：当前 APK 应用的名称。
• LOCAL_CERTIFICATE：签署当前应用的证书名称。

• LOCAL_MODULE_TAGS：当前模块所包含的标签，一个模块可以包含多个标签。标签的值可能是 debug, eng, user，development 或者 optional。其中，optional 是默认标签。标签是提供给编译类型使用的。不同的编译类型会安装包含不同标签的模块，那么这些标签的值有代表什么呢？

  这个问题问得好，这些标签代表编译类型，编译类型的各个标签分别如下（表格略吃藕，凑合看了 ）：

名称 说明 eng 默认类型，该编译类型适用于开发阶段。 当选择这种类型时，编译结果将： 安装包含 eng, debug, user，development 标签的模块 安装所有没有标签的非 APK 模块 安装所有产品定义文件中指定的 APK 模块 user 该编译类型适合用于最终发布阶段。 当选择这种类型时，编译结果将： 安装所有带有 user 标签的模块 安装所有没有标签的非 APK 模块 安装所有产品定义文件中指定的 APK 模块，APK 模块的标签将被忽略 userdebug 该编译类型适合用于 debug 阶段。 该类型和 user 一样，除了： 会安装包含 debug 标签的模块 编译出的系统具有 root 访问权限

---

第二行

include $(CLEAR_VARS)

从字面意思理解，这大概就是清除之前的变量值吧？有批判性思维的同学就要问了，清除什么变量值，为什么要清除呢？留着不是更好吗？这个CLEAR_VARS里面都有些什么值我们要包含进来？

嗯，这位同学又提出了一个不错的问题，我们带着疑问猜，会不会是因为安卓系统编译的时候为了防止定义过多的变量，把一些变量定义公用的，但是这些变量在编译上一个模块的时候已经被赋值了，如果下一个模块要继续使用就需要把这些变量清除或者叫做重新初始化？

恩恩，这位同学真机智，就是这样的。

第三行

LOCAL_MODULE := hello-jni

等号前面的我们知道了，那么后面的这个 hello-jni是个什么鬼？
嗯，我们回到上面看下LOCAL_MODULE的定义。
LOCAL_MODULE模块必须定义，以表示Android.mk中的每一个模块。名字必须唯一且不包含空格。Build System会自动添加适当的前缀和后缀。例如，foo，要产生动态库，则生成libfoo.so.
但请注意：如果模块名被定为：libfoo.则生成libfoo.so. 不再加前缀。

模块间的依赖关系就是通过这个名称来引用的。

上面这句话有没有想到什么？对了，模块间的依赖关系，不就是这个文章讲的怎么应用另一个模块嘛？别激动，这个还只是定义，我们继续探索。

第四行

LOCAL_SRC_FILES := hello-jni.c
这句话的意思就是说，我这个工程的源码路径只有一个文件，这个文件就是我这个MK文件所在目录下的hello-jni.c

第五行

include $(BUILD_SHARED_LIBRARY)
当前模块在静态链接时需要的库的名称。

---

不含C的Android.mk

其实上面就是在源码树下我们添加jni文件的mk写法。我们先来研究一下纯不包含C文件的Android.mk，也就是我们写的第一个程序helloworld在安卓源码树中的展现。我们来分析分析Android.mk内容。

  LOCAL_PATH := $(call my-dir)  include $(CLEAR_VARS)  # Build all java files in the java subdirectory  LOCAL_SRC_FILES := $(call all-subdir-java-files)  # Name of the APK to build  LOCAL_PACKAGE_NAME := LocalPackage  LOCAL_CERTIFICATE := platform  # Tell it to build an APK  include $(BUILD_PACKAGE)

第二行

LOCAL_SRC_FILES := $(call all-subdir-java-files)

我们看到这里的写法和上面C的写法不相同，all-subdir-java-files代表的是子目录下的所有java文件，上面的jni例子里面是直接指定c文件，那么如果有多个C文件怎么办？是不是也应该all-subdir-java-files这样来一下。

我找啊找，找到了这个：

除此以外，Build 系统中还定义了一些便捷的函数以便在 Android.mk 中使用，包括： $(call my-dir)：获取当前文件夹路径。

• $(call all-java-files-under, <src>)：获取指定目录下的所有 Java文件。
• $(call all-c-files-under, <src>)：获取指定目录下的所有 C 语言文件。
• $(call> all-Iaidl-files-under, <src>) ：获取指定目录下的所有 AIDL 文件。
• $(call> all-makefiles-under, <folder>)：获取指定目录下的所有 Make 文件。
• $(call intermediates-dir-for, <class>, <app_name>, <host or target>, <common?> )：获取 Build 输出的目标文件夹路径。

提示（与本文无关，可忽略）：我在编辑这篇文章的时候类似于 <src>的格式直接被浏览器解析掉了，无法显示，所以我才用的是特殊字符编码的形式，比如：

<   &lt;　　<=   &le;>   &gt;　　>=   &ge;

第三行

LOCAL_PACKAGE_NAME := LocalPackage //应用名称

这个指的是当前 APK 应用的名称，这个和LOCAL_MODULE不一样，它不是是唯一的，就相当于Manifest.xml清单文件里面的appName。

第四行

LOCAL_CERTIFICATE := platform//签署当前应用的证书名称。

证书？莫非系统签名和这个有关系？如果是，是不是说只要这个名字对应的系统签名，那么就能使用android:sharedUserId=”android.uid.system”并使用系统级别的一些方法？
带着疑问我查了一下，没想到又被我猜对了，我真是个机智的少年。
现在我们知道了LOCAL_CERTIFICATE 的作用，那么后面的platform是啥意思呢？哦，原来是签名类型。

####**签名类型** android的标准签名key有：testkeymediaplatformshared以上的四种，可以在源码的/build/target/product/security里面看到对应的密钥，其中shared.pk8代表私钥，shared.x509.pem公钥，一定是成对出现的。其中testkey是作为android编译的时候默认的签名key，如果系统中的apk的android.mk中没有设置LOCAL_CERTIFICATE的值，就默认使用testkey。而如果设置成：LOCAL_CERTIFICATE := platform就代表使用platform来签名，这样的话这个apk就拥有了和system相同的签名，因为系统级别的签名也是使用的platform来签名，此时使用android:sharedUserId="android.uid.system"才有用！

第五行

我们来看最后一行

include $(BUILD_PACKAGE)

BUILD_PACKAGE是什么呢？编译目标对象？难道说是区分给手机用，还是给平板用的？
好像没猜对，我们看下资料：

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_SHARED_LIBRARY
BUILD_EXECUTABLE
BUILD_PACKAGE BUILD_PREBUILT
BUILD_MULTI_PREBUILT
BUILD_JAVA_LIBRARY
BUILD_HOST_JAVA_LIBRARY

通过名称大概就可以猜出每个变量所对应的模块类型。（在模块的 Android.mk
文件中，只要包含进这里对应的常量便可以执行相应类型模块的编译。

这些常量的值都是另外一个 Make 文件的路径，详细的编译方式都是在对应的 Make 文件中定义的。这些常量和 Make
文件的是一一对应的，对应规则也很简单：常量的名称是 Make 文件的文件名除去后缀全部改为大写然后加上“BUILD_”作为前缀。例如常量
BUILD_HOST_PREBUILT 的值对应的文件就是 host_prebuilt.mk。

既然讲到了这里那么我们也来看下其他值对应的什么吧

依赖关系

顺带着我们把mk之间的依赖关系看一下。有些文章一来就给我们看这个，你说谁看得懂。。。