Android 编译系统分析_实用编译系统分析-CSDN博客

Android 编译系统分析之返璞归真

自Android开源以来，引起了嵌入式行业一股热潮，很多嵌入式开发者表示对Android有很强的兴趣，并下载Android源码进行编译和移植。Android源码的巨大（repo下来，大概2G）给人以Android相当复杂的错觉。本文从Android编译系统的角度，让大家了解Android其实也是很纯真的。

Android编译系统（build system）集中于Android源码下的build/core下，在Android2.2中，共有56个*.mk文件。另外还有一些shell脚本。可谓相当庞大，为什么google将它的编译系统弄的如此复杂庞大呢？在build/core下的build-system.html中有以下讲述：

1.     Multiple Targets
2.     Non-Recursive Make
3.     Rapid Compile-Test Cycles
4.     Both Environment and Config File Based Settings
5.     Object File Directory / make clean

基于以上目标，google Android开发人员将Android build system做成了现在的样子。在android.git.kernel.org上可以看到android build system作为一个项目一直在更新，因此，对于其编译系统的维护也是一个相当复杂的项目。为了实现Android在除ARM平台（x86、mips甚至一个全新的架构）上移植，必须深入了解Android编译系统。

Android 架构

这几天又恶补了一下Makefile的规则，以下是摘自http://www.360doc.com/content/10/0409/13/502243_22235679.shtml

的一段，强烈推荐对Makefile感兴趣的同学读一下，好像有PDF下，叫做《跟我一起写Makefile》可以加深对编译过程的了解。Linux有了make工具，就可以藐视Windows的Visual Studio的IDE了。

     Makefile的规则：

     target ... : prerequisites ...

            command

            ...

            ...

target也就是一个目标文件，可以是Object File，也可以是执行文件。还可以是一个标签（Label），对于标签这种特性，在后续的“伪目标”章节中会有叙述。

prerequisites就是，要生成那个target所需要的文件或是目标。

command也就是make需要执行的命令。（任意的Shell命令）

这是一个文件的依赖关系，也就是说，target这一个或多个的目标文件依赖于prerequisites中的文件，其生成规则定义在command中。说白一点就是说，prerequisites中如果有一个以上的文件比target文件要新的话，command所定义的命令就会被执行。这就是 Makefile的规则。也就是Makefile中最核心的内容。

     正如上面作者所述，上面是Makefile中最核心的内容，Android编译系统符合GNU make的标准，当然这也是Android 编译系统最核心的内容。

     Android编译系统的架构：

     分析Android编译系统，你会发现，Android编译系统完成的并不仅仅是对目标（主机）系统二进制文件、java应用程序的编译、链接、打包等，而且还有包括生成各种依赖关系、确保某个模块的修改引起相依赖的文件的重新编译链接，甚至还包括目标文件系统的生成，配置文件的生成等，因此Android编译系统具有支持多架构（linux-x86、windows、arm等）、多语言（汇编、C、C++、Java等）、多目标、多编译方式。这些目标和结构决定其架构也很重要。

         Android编译系统集中于build/core下，几个很重要的*.mk文件如下：

         main.mk(主控Makefile)

         base_rules.mk(对一些Makefile的变量规则化)

         config.mk（关于编译参数、编译命令的一些配置）

         definations.mk（定义了很多编译系统中用到的宏，相当于函数库）

         Makefile（这个Makefile特指build/core下的Makefile，此文件主要控制生成system.img,ramdisk.img,userdata.img,以及recorvery image，sdk等）

         Binary.mk(控制如何生成目标文件)

         Clear_vars.mk（清除编译系统中用到的临时变量）

         Combo/linux-arm.mk(控制如何生成linux-arm二进制文件，包括ARM相关的编译器，编译参数等的设置)

         Copy_headers.mk（将头文件拷贝到指定目录）

         分散于各个目录下的Android.mk(控制生成局部模块的源码，名称所需头文件路径，依赖库等特殊选项)

         Build/envsetup.mk(编译环境初始化，定义一些实用的shell函数，方便编译使用)

         以上几个主要的文件，可以按照社会分工打一个比方：

         Main.mk是总统，是老大，承担了很多工作。

         Makefile是副总统，辅佐老大Main.mk

         Base_rules.mk是交警，让不规则的东西，变得规则。

         Config.mk是省长，规定了各个人民群众该如何行事

         Definations.mk是图书馆管理员

         Binary.mk应该属于村长了，规定每个人该如何行事

         Clear_vars.mk应该属于保洁公司的工人吧

         Combo/linux-arm.mk应该属于社会公民了，他决定自己该如何去做

         注：明天会将对main.mk的分析贴上来，欢迎大家指正。

Main.mk分析

Main.mk主要包含如下几个部分的内容

1.       SHELL设置

2.       编译环境配置

3.       编译环境检查

4.       包含必要的宏

5.       根据make参数设置编译时的变量

6.       包含需要编译的Android.mk

7.       设置编译系统Target：prerequisites 控制整个编译流程

下面对上面几点进行必要解释：

有了前面小节对Android编译系统架构的分析，如果需要修改Android编译系统，就可以不至于盲目找问题，修改代码了。今天分析下main.mk，看它能为我们Android编译提供什么有价值的信息，以及如何自己定制我们的Android编译系统。

Main.mk的第一句就根据ANDROID_BUILD_SHELL来包裹编译系统用到的Shell，如果我们不想使用bash，而想使用sh，那么就可以在它前面写上ANDROID_BUILD_SHELL := /bin/sh，或者在build/envsetup.sh中添加相关定义。

定义完SHELL之后，就是对MAKE_VERSION的检查，然后定义了默认的编译目标droid!

如果我们敲入make之后，不加任何参数，默认的目标就是droid。注意虽然后面的include $(BUILD_SYSTEM)/config.mk写在默认目标droid依赖之后，但其和之后的语句都是要执行的，这是Makefile的语法决定的。

后面会include config.mk cleanbuild.mk对编译系统进行必要的配置。后面就是对编译环境的检查，包括是否大小写敏感、路径检查、java版本检查、javac版本检查。Android对编译环境的检查如果符合条件，在下次编译的时候，不会再次进行检查。

检查完版本之后，会包含进definations.mk，如前所述，definations.mk中定义了很多编译系统中用到的宏，这些宏在编译时需要经常调用，因此在编译的很靠前的阶段，就将之包含了进来。

然后就是针对make时传入的编译类型（eng user userdebug showcommands等）进行编译配置，这些配置会影响到最终编译目标所包括的模块。对于eng user userdebug sdk win_sdk tests等编译目标的区别，读者可以通过查看main.mk的代码找出其中到底有什么不同。

此处略去部分部分不重要的内容，直接跳到

Ifeq($(SDK_ONLY),true)处，大概368行附近，这个判断语句一直到这个语句块结束，都是对subdirs变量的设置，subdirs变量决定了哪些子文件夹最终被编译。

在后面的subdir_makefiles变量的设置，决定了哪些Android.mk被编译。紧接着include $(subdir_makefiles)就会添加所有这些Android.mk文件的依赖。这其中包含了droid的依赖，后面我们会发现。

然后就会根据这些Makefile，找出所有需要编译的模块（module），以及进行必要的分类（eng_MODULES/debug_MODULES/tests_MODULES等、modules_to_check/modules_to_install等），用以区别对待。

紧接着是定义了一系列的隐含目标：prebuilt、all_copied_headers、files、checkbuild、ramdisk、systemtallball、userdataimage、userdatatarball、bootimg、droidcore等。最重要的一点，是会发现droid依赖于droidcore,而droidcore依赖于

droidcore: files /

         systemimage /

         $(INSTALLED_BOOTIMAGE_TARGET) /

         $(INSTALLED_RECOVERYIMAGE_TARGET) /

         $(INSTALLED_USERDATAIMAGE_TARGET) /

         $(INSTALLED_FILES_FILE)

正是这几个依赖项，控制着整个android的编译。

下一篇博文会讲述一个system.img的整个生成过程。