Android编译系统二

一，Android编 译系统结构

android的编译文件主要依赖于mk文件，其源码编译名字是Android.mk,而不我们常见的Makefile文件。
android目录下的Makefile文件，include了build/core目录下的main.mk文件。
main.mk文件
main.mk要完成功能，主要如下：
    包含build/core/config.mk：根据目标板的标准变量和主机信息，设置一些变量。确定输出目录和产品工程。
    SHELL := /bin/bash， 表明用到系统bash，如果想用其他的sh，那么据此而改即可。
    检测host的操作系统，编译环境。
    包含definitions.mk，标准的编译系统设定参数。主要是一些宏定义，如在Android.mk常见到的all-subdir-makefiles、my-dir之类的宏。
    主要内容还是在 config.mk文件。
1config.mk

    首先会检测主目录下的buildspec.mk，目前此文件不存在，我们可在此设置一些参数。

    这些参数，可用于envsettup.mk，如果没有buildspec.mk文件，envsettup.mk则默认一些变量，如TARGET_ARCH:= arm ，TARGET_OS := linux等。  

1.1 envsettup.mk  

    应该说envsettup.mk是config.mk重要组成部分，设置一些主要编译工程的相关参数。

    首先includeversion_defaults.mk，设置以下变量：

        PLATFORM_VERSION

        PLATFORM_SDK_VERSION

        DEFAULT_APP_TARGET_SDK

        BUILD_ID

        BUILD_NUMBER

    其次设定TARGET_PRODUCT，也就是在编译地时候如果没有用makePRODUCT-xxx-xxx，则会在此处设定。否则就要根据product_config.mk文件里的内容进行target和product的相关参数。

    再次，设置一些输出文件路径变量，如TARGET_OUT_XXX之类的。

    最后把一些简单信息显示终端上：

    $(info============================================)

    $(info  PLATFORM_VERSION_CODENAME=$(PLATFORM_VERSION_CODENAME))

    $(info   PLATFORM_VERSION=$(PLATFORM_VERSION))

    $(info   TARGET_PRODUCT=$(TARGET_PRODUCT))

    $(info   TARGET_BUILD_VARIANT=$(TARGET_BUILD_VARIANT))

    $(info   TARGET_SIMULATOR=$(TARGET_SIMULATOR))

    $(info   TARGET_BUILD_TYPE=$(TARGET_BUILD_TYPE))

    $(info   TARGET_ARCH=$(TARGET_ARCH))

    $(info   HOST_ARCH=$(HOST_ARCH))

    $(info   HOST_OS=$(HOST_OS))

    $(info   HOST_BUILD_TYPE=$(HOST_BUILD_TYPE))

    $(info   BUILD_ID=$(BUILD_ID))

    $(info============================================)

    envsetup.mk里头最主要的就是product_config.mk
    product_config.mk包含三个文件node_fns.mk、product.mk和device.mk。此三文件都是一些宏定义或变量定义，目的是根据make时传进来的参数，从vendor目录和build/target目录下，找到相应的product和devcie信息，即找BoardConfig.mk文件，从而设定TARGET_PRODUCT、TARGET_DEVICE等值。  

1.2 pathmap.mk，一些头文件路径，及androidframework目录。
     编译系统内部的一些文件：host_static_library.mk、host_shared_library.mk等

1.3 BoardConfig.mk
    默认情况下是编译的board是generic。
    查找build/target/board/generic目录上的内容，共有两个mk文件，AndroidBoard.mk和BoardConfig.mk。其中BoardConfig.mk定义一些硬件特性。
2 Makefile文件

    build/core/Makefile文件是系统集成了，完成img，app，frameworks、模块的编译
3 对于framework开发，或者在系统移植时添加应用程序，每写一次代码就要进行编译，而每次用make相关参数命令时，编译的时间会比较长。这时可以考虑以下方式进行编译

    cdanddroid_top_path

    ./build/envsetup.sh

    此时就用mmm，mm和m命令进行编译：

    m表示在顶层目录进行编译

    mm　表示在当前目录下进行模块编译

    mmm　path，　编译path目录下的模块。

    一般在写模块时，用mmm命令就可以了。

二，Android编译系统分析
1. Android编译系统分析
编译脚本及系统变量
build/envsetup.sh脚本分析
在编译源代码之前通常需要在android源代码顶层目录执行 . ./build/envsetup.sh 目的是为了使用
脚本 envsetup.sh 里面定义了一些函数：
function help()
function get_abs_build_var()
function get_build_var()
function check_product()
function check_variant()
function setpaths()
function printconfig()
function set_stuff_for_environment()
function set_sequence_number()
function settitle()
function choosetype()
function chooseproduct()
function choosevariant()
function tapas()
function choosecombo()
function print_lunch_menu()
function lunch()
function gettop
function m()
function findmakefile()
function mm()
function mmm()
function croot()
function pid()
function gdbclient()
function jgrep()
function cgrep()
function resgrep()
function getprebuilt
function tracedmdump()
function runhat()
function getbugreports()
function startviewserver()
function stopviewserver()
function isviewserverstarted()
function smoketest()
function runtest()
function runtest_py()
function godir ()

choosecombo 命令分析：
function choosecombo()
{
choosesim $1
echo
echo
choosetype $2

echo
echo
chooseproduct $3

echo
echo
choosevariant $4

echo
set_stuff_for_environment
printconfig
}
会依次进行如下选择：
Build for the simulator or the device?
1. Device
2. Simulator
Which would you like? [1]

Build type choices are:
1. release
2. debug
Which would you like? [1]

Product choices are:
1. emulator
2. generic
3. sim
4. littleton
You can also type the name of a product if you know it.
Which would you like? [littleton]

Variant choices are:
1. user
2. userdebug
3. eng
Which would you like? [eng] user
默认选择以后会出现：
TARGET_PRODUCT=littleton
TARGET_BUILD_VARIANT=user
TARGET_SIMULATOR=false
TARGET_BUILD_TYPE=release
TARGET_ARCH=arm
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=
＝＝＝＝＝＝＝＝＝＝
function chooseproduct()函数分析：
choices=(`/bin/ls build/target/board/*/BoardConfig.mk vendor/*/*/BoardConfig.mk 2> /dev/null`)
读取 build/target/board/* 目录下的板配置文件：BoardConfig.mk
读取 vendor/*/*/目录下的板配置文件：BoardConfig.mk
choices 的值为：
build/target/board/emulator/BoardConfig.mk
build/target/board/generic/BoardConfig.mk
build/target/board/sim/BoardConfig.mk
vendor/marvell/littleton/BoardConfig.mk
经过：
for choice in ${choices[@]}
do
# The product name is the name of the directory containing
# the makefile we found, above.
prodlist=(${prodlist[@]} `dirname ${choice} | xargs basename`)
done
的处理，prodlist的值为：
emulator generic sim littleton
所以选择菜单为：
Product choices are:
1. emulator
2. generic
3. sim
4. littleton
如果选择 4，那么 TARGET_PRODUCT 被赋值为： littleton。


board_config_mk := /
$(strip $(wildcard /
$(SRC_TARGET_DIR)/board/$(TARGET_DEVICE)/BoardConfig.mk /
vendor/*/$(TARGET_DEVICE)/BoardConfig.mk /
))



怎样添加一个模块
LOCAL_PATH:= $(call my-dir)
#编译静态库
include $(CLEAR_VARS)
LOCAL_MODULE = libhellos
LOCAL_CFLAGS = $(L_CFLAGS)
LOCAL_SRC_FILES = hellos.c
LOCAL_C_INCLUDES = $(INCLUDES)
LOCAL_SHARED_LIBRARIES := libcutils
LOCAL_COPY_HEADERS_TO := libhellos
LOCAL_COPY_HEADERS := hellos.h
include $(BUILD_STATIC_LIBRARY)

#编译动态库
include $(CLEAR_VARS)
LOCAL_MODULE = libhellod
LOCAL_CFLAGS = $(L_CFLAGS)
LOCAL_SRC_FILES = hellod.c
LOCAL_C_INCLUDES = $(INCLUDES)
LOCAL_SHARED_LIBRARIES := libcutils
LOCAL_COPY_HEADERS_TO := libhellod
LOCAL_COPY_HEADERS := hellod.h
include $(BUILD_SHARED_LIBRARY)

BUILD_TEST=true
ifeq ($(BUILD_TEST),true)
#使用静态库
include $(CLEAR_VARS)
LOCAL_MODULE := hellos
LOCAL_STATIC_LIBRARIES := libhellos
LOCAL_SHARED_LIBRARIES :=
LOCAL_LDLIBS += -ldl
LOCAL_CFLAGS := $(L_CFLAGS)
LOCAL_SRC_FILES := mains.c
LOCAL_C_INCLUDES := $(INCLUDES)
include $(BUILD_EXECUTABLE)

#使用动态库
include $(CLEAR_VARS)
LOCAL_MODULE := hellod
LOCAL_MODULE_TAGS := debug
LOCAL_SHARED_LIBRARIES := libc libcutils libhellod
LOCAL_LDLIBS += -ldl
LOCAL_CFLAGS := $(L_CFLAGS)
LOCAL_SRC_FILES := maind.c
LOCAL_C_INCLUDES := $(INCLUDES)
include $(BUILD_EXECUTABLE)
endif # ifeq ($(WPA_BUILD_SUPPLICANT),true)

########################
#local_target_dir := $(TARGET_OUT)/etc/wifi
#include $(CLEAR_VARS)
#LOCAL_MODULE := wpa_supplicant.conf
#LOCAL_MODULE_TAGS := user
#LOCAL_MODULE_CLASS := ETC
#LOCAL_MODULE_PATH := $(local_target_dir)
#LOCAL_SRC_FILES := $(LOCAL_MODULE)
#include $(BUILD_PREBUILT)
########################
系统变量解析
LOCAL_MODULE － 编译的目标对象
LOCAL_SRC_FILES － 编译的源文件
LOCAL_C_INCLUDES － 需要包含的头文件目录
LOCAL_SHARED_LIBRARIES － 链接时需要的外部库
LOCAL_PRELINK_MODULE － 是否需要prelink处理
BUILD_SHARED_LIBRARY － 指明要编译成动态库


LOCAL_PATH - 编译时的目录
$(call 目录，目录….) 目录引入操作符
如该目录下有个文件夹名称 src，则可以这样写 $(call src)，那么就会得到 src 目录的完整路径

include $(CLEAR_VARS) -清除之前的一些系统变量
CLEAR_VARS:= $(BUILD_SYSTEM)/clear_vars.mk
在 build/core/config.mk 定义 CLEAR_VARS:= $(BUILD_SYSTEM)/clear_vars.mk
通过include 包含自定义的.mk文件（即是自定义编译规则）或是引用系统其他的.mk文件（系统定义的编译规则）。

LOCAL_SRC_FILES － 编译的源文件
可以是.c, .cpp, .java, .S（汇编文件）或是.aidl等格式
不同的文件用空格隔开。如果编译目录子目录，采用相对路径，如子目录/文件名。也可以通过$(call 目录)，指明编译某目录
下所有.c/.cpp/.java/.S/ .aidl文件.追加文件 LOCAL_SRC_FILES += 文件

LOCAL_C_INCLUDES － 需要包含的头文件目录
可以是系统定义路径，也可以是相对路径. 如该编译目录下有个include目录，写法是include/*.h

LOCAL_SHARED_LIBRARIES － 链接时需要的外部共享库
LOCAL_STATIC_LIBRA RIES － 链接时需要的外部外部静态
LOCAL_JAVA_LIBRARIES 加入jar包

LOCAL_MODULE － 编译的目标对象
module 是指系统的 native code，通常针对c,c++代码
./system/core/sh/Android.mk:32:LOCAL_MODULE:= sh
./system/core/libcutils/Android.mk:71:LOCAL_MODULE := libcutils
./system/core/cpio/Android.mk:9:LOCAL_MODULE := mkbootfs
./system/core/mkbootimg/Android.mk:8:LOCAL_MODULE := mkbootimg
./system/core/toolbox/Android.mk:61:LOCAL_MODULE:= toolbox
./system/core/logcat/Android.mk:10:LOCAL_MODULE:= logcat
./system/core/adb/Android.mk:65:LOCAL_MODULE := adb
./system/core/adb/Android.mk:125:LOCAL_MODULE := adbd
./system/core/init/Android.mk:20:LOCAL_MODULE:= init
./system/core/vold/Android.mk:24:LOCAL_MODULE:= vold
./system/core/mountd/Android.mk:13:LOCAL_MODULE:= mountd

LOCAL_PACKAGE_NAME
Java 应用程序的名字用该变量定义
./packages/apps/Music/Android.mk:9:LOCAL_PACKAGE_NAME := Music
./packages/apps/Browser/Android.mk:14:LOCAL_PACKAGE_NAME := Browser
./packages/apps/Settings/Android.mk:8:LOCAL_PACKAGE_NAME := Settings
./packages/apps/Stk/Android.mk:10:LOCAL_PACKAGE_NAME := Stk
./packages/apps/Contacts/Android.mk:10:LOCAL_PACKAGE_NAME := Contacts
./packages/apps/Mms/Android.mk:8:LOCAL_PACKAGE_NAME := Mms
./packages/apps/Camera/Android.mk:8:LOCAL_PACKAGE_NAME := Camera
./packages/apps/Phone/Android.mk:11:LOCAL_PACKAGE_NAME := Phone
./packages/apps/VoiceDialer/Android.mk:8:LOCAL_PACKAGE_NAME := VoiceDialer


BUILD_SHARED_LIBRARY － 指明要编译成动态库。
编译的目标，用include 操作符
UILD_STATIC_LIBRARY来指明要编译成静态库。
如果是java文件的话，会用到系统的编译脚本host_java_library.mk，用BUILD_PACKAGE来指明。三个编译
－－－－－－－－－－－－－－－－－－－
include $(BUILD_STATIC_LIBRARY)
BUILD_STATIC_LIBRARY:= $(BUILD_SYSTEM)/static_library.mk
－－－－－－－－－－－－－－－－－－－
include $(BUILD_SHARED_LIBRARY)
./build/core/config.mk:50:BUILD_SHARED_LIBRARY:= $(BUILD_SYSTEM)/shared_library.mk
－－－－－－－－－－－－－－－－－－－
include $(BUILD_HOST_SHARED_LIBRARY)
BUILD_HOST_SHARED_LIBRARY:= $(BUILD_SYSTEM)/host_shared_library.mk
－－－－－－－－－－－－－－－－－－－
include $(BUILD_EXECUTABLE)
build/core/config.mk:51:BUILD_EXECUTABLE:= $(BUILD_SYSTEM)/executable.mk
－－－－－－－－－－－－－－－－－－－
include $(BUILD_HOST_EXECUTABLE)
./build/core/config.mk:53:BUILD_HOST_EXECUTABLE:= $(BUILD_SYSTEM)/host_executable.mk
－－－－－－－－－－－－－－－－－－－
BUILD_HOST_JAVA_LIBRARY:= $(BUILD_SYSTEM)/host_java_library.mk
－－－－－－－－－－－－－－－－－－－
BUILD_JAVA_LIBRARY
./build/core/config.mk:58:BUILD_JAVA_LIBRARY:= $(BUILD_SYSTEM)/java_library.mk
－－－－－－－－－－－－－－－－－－
BUILD_STATIC_JAVA_LIBRARY 编译静态JAVA库
./build/core/config.mk:59:BUILD_STATIC_JAVA_LIBRARY:= $(BUILD_SYSTEM)/static_java_library.mk
－－－－－－－－－－－－－－－－－－
BUILD_HOST_JAVA_LIBRARY 编译本机用的JAVA库
./build/core/config.mk:60:BUILD_HOST_JAVA_LIBRARY:= $(BUILD_SYSTEM)/host_java_library.mk
－－－－－－－－－－－－－－－－－－

BUILD_HOST_STATIC_LIBRARY:= $(BUILD_SYSTEM)/host_static_library.mk
BUILD_HOST_SHARED_LIBRARY:= $(BUILD_SYSTEM)/host_shared_library.mk
BUILD_STATIC_LIBRARY:= $(BUILD_SYSTEM)/static_library.mk
BUILD_RAW_STATIC_LIBRARY := $(BUILD_SYSTEM)/raw_static_library.mk
BUILD_SHARED_LIBRARY:= $(BUILD_SYSTEM)/shared_library.mk
BUILD_EXECUTABLE:= $(BUILD_SYSTEM)/executable.mk
BUILD_RAW_EXECUTABLE:= $(BUILD_SYSTEM)/raw_executable.mk
BUILD_HOST_EXECUTABLE:= $(BUILD_SYSTEM)/host_executable.mk
BUILD_PACKAGE:= $(BUILD_SYSTEM)/package.mk
BUILD_HOST_PREBUILT:= $(BUILD_SYSTEM)/host_prebuilt.mk
BUILD_PREBUILT:= $(BUILD_SYSTEM)/prebuilt.mk
BUILD_MULTI_PREBUILT:= $(BUILD_SYSTEM)/multi_prebuilt.mk
BUILD_JAVA_LIBRARY:= $(BUILD_SYSTEM)/java_library.mk
BUILD_STATIC_JAVA_LIBRARY:= $(BUILD_SYSTEM)/static_java_library.mk
BUILD_HOST_JAVA_LIBRARY:= $(BUILD_SYSTEM)/host_java_library.mk
BUILD_DROIDDOC:= $(BUILD_SYSTEM)/droiddoc.mk
BUILD_COPY_HEADERS := $(BUILD_SYSTEM)/copy_headers.mk
BUILD_KEY_CHAR_MAP := $(BUILD_SYSTEM)/key_char_map.mk

＝＝＝＝＝＝＝＝＝＝＝＝
LOCAL_PRELINK_MODULE
Prelink利用事先链接代替运行时链接的方法来加速共享库的加载，它不仅可以加快起动速度，还可以减少部分内存开销，
是各种Linux架构上用于减少程序加载时间、缩短系统启动时间和加快应用程序启动的很受欢迎的一个工具。程序运行时的
动态链接尤其是重定位(relocation)的开销对于大型系统来说是很大的。
动态链接和加载的过程开销很大，并且在大多数的系统上, 函数库并不会常常被更动, 每次程序被执行时所进行的链接
动作都是完全相同的，对于嵌入式系统来说尤其如此。因此，这一过程可以改在运行时之前就可以预先处理好，即花一些时间
利用Prelink工具对动态共享库和可执行文件进行处理，修改这些二进制文件并加入相应的重定位等信息，节约了本来在程序
启动时的比较耗时的查询函数地址等工作，这样可以减少程序启动的时间，同时也减少了内存的耗用。
Prelink的这种做法当然也有代价：每次更新动态共享库时，相关的可执行文件都需要重新执行一遍Prelink才能保
证有效，因为新的共享库中的符号信息、地址等很可能与原来的已经不同了，这就是为什么 android framework代码一改动，
这时候就会导致相关的应用程序重新被编译。
这种代价对于嵌入式系统的开发者来说可能稍微带来一些复杂度，不过好在对用户来说几乎是可以忽略的。
－－－－－－－－－－－－－－－－－－－－
变量设置为false那么将不做prelink操作
LOCAL_PRELINK_MODULE := false
默认是需要prlink的，同时需要在 build/core/prelink-linux-arm.map 中加入
libhellod.so 0x96000000
这个map文件好像是制定动态库的地址的，在前面注释上面有一些地址范围的信息，注意库与库之间的间隔数，
如果指定不好的话编译的时候会提示说地址空间冲突的问题。另外，注意排序，这里要把数大的放到前面去，
按照大小降序排序。
解析 LOCAL_PRELINK_MODULE 变量
build/core/dynamic_binary.mk:94:ifeq ($(LOCAL_PRELINK_MODULE),true)
ifeq ($(LOCAL_PRELINK_MODULE),true)
$(prelink_output): $(prelink_input) $(TARGET_PRELINKER_MAP) $(APRIORI)
$(transform-to-prelinked)
transform-to-prelinked定义：
./build/core/definitions.mk:1002:define transform-to-prelinked
define transform-to-prelinked
@mkdir -p $(dir $@)
@echo "target Prelink: $(PRIVATE_MODULE) ($@)"
$(hide) $(APRIORI) /
--prelinkmap $(TARGET_PRELINKER_MAP) /
--locals-only /
--quiet /
$< /
--output $@
endef
./build/core/config.mk:183:APRIORI := $(HOST_OUT_EXECUTABLES)/apriori$(HOST_EXECUTABLE_SUFFIX)
prelink工具不是常用的prelink而是apriori，其源代码位于” <your_android>/build/tools/apriori”
参考文档：
动态库优化——Prelink（预连接）技术
http://www.eefocus.com/article/09-04/71629s.html


＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
LOCAL_ARM_MODE := arm
目前Android大部分都是基于Arm处理器的，Arm指令用两种模式Thumb(每条指令两个字节)和arm指令（每条指令四个字节）

LOCAL_CFLAGS += -O3 -fstrict-aliasing -fprefetch-loop-arrays
通过设定编译器操作，优化级别，-O0表示没有优化,-O1为缺省值，-O3优化级别最高
LOCAL_CFLAGS += -W -Wall
LOCAL_CFLAGS += -fPIC -DPIC
LOCAL_CFLAGS += -O2 -g -DADB_HOST=1 -Wall -Wno-unused-parameter
LOCAL_CFLAGS += -D_XOPEN_SOURCE -D_GNU_SOURCE -DSH_HISTORY
LOCAL_CFLAGS += -DUSEOVERLAY2
根据条件选择相应的编译参数
ifeq ($(TARGET_ARCH),arm)
LOCAL_CFLAGS += -DANDROID_GADGET=1
LOCAL_CFLAGS := $(PV_CFLAGS)
endif
ifeq ($(TARGET_BUILD_TYPE),release)
LOCAL_CFLAGS += -O2
endif

LOCAL_LDLIBS := -lpthread
LOCAL_LDLIBS += -ldl

ifdef USE_MARVELL_MVED
LOCAL_WHOLE_STATIC_LIBRARIES += lib_il_mpeg4aspdecmved_wmmx2lnx lib_il_h264decmved_wmmx2lnx
LOCAL_SHARED_LIBRARIES += libMrvlMVED
else
LOCAL_WHOLE_STATIC_LIBRARIES += lib_il_h264dec_wmmx2lnx lib_il_mpeg4aspdec_wmmx2lnx
endif

转自http://blog.csdn.net/yili_xie/archive/2009/11/30/4906865.aspx


三，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
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主要包含如下几个部分的内容

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的编译。