ANDROID系统编译过程详解
第一部分:概述
在研究Android编译系统之前,我们首先需要了解Linux系统的make命令。在Linux系统中,我们可以通过make命令来编译代码。Make命令在执行的时候,默认会在当前目录找到一个Makefile文件,然后根据Makefile文件中的指令来对代码进行编译。也就是说,make命令执行的是Makefile文件中的指令。Makefile文件中的指令可以是编译命令,例如gcc,也可以是其它命令,例如Linux系统中的shell命令cp、rm等等。理解这一点非常重要,因为虽然通常我们说make命令是可以编译代码的,但是它实际上可以做任何事情。
看到这里,有的小伙伴可能会说,在Linux系统中,直接通过shell命令也可以做很多事情啊,它和make命令有什么区别呢?通过前面的介绍可以知道,make命令事实也是通过shell命令来完成任务的,但是它的神奇之处是可以帮我们处理好文件之间的依赖关系。我们通常都有会这样的一个需求,假设有一个文件T,它依赖于另外一个文件D,要求只有当文件D的内容发生变化,才重新生成文件T。这种需求在编译系统中表现得尤其典型,当一个*.c文件include的*.h文件发生变化时,需要重新编译该*.c文件,或者当一个模块A所引用的模块B发生变化时,重新编译模块B。正是由于编译系统中存在这种典型的文件依赖需求,而make命令又是专门用来解决这种文件依赖问题的,因此我们通常认为make命令是用来编译代码的。
Make命令是怎么知道两个文件之间存在依赖关系,以及当被依赖文件发生变化时如何处理目标文件的呢?答案就在前面提到的Makefile文件。Makefile文件实际上是一个脚本文件,就像普通的shell脚本文件一样,只不过它遵循的是Makefile语法。Makefile文件最基础的功能就是描述文件之间的依赖关系,以及怎么处理这些依赖关系。例如,假设有一个目录文件target,它依赖于文件dependency,并且当文件dependency发生变化时,需要通过command命令来重新生成文件T,这时候我们就可以在Makefile编写以下语句:
[plain] view plaincopy
- target: dependency
- <tab>command -o target -i dependency
我们假设命令command的-o选项指定的是输出文件,而-i选项指定的是输入文件。此外,命令command必须是另起一行,并且以tab键开头。
这就是最基础也是最主要的Makefile文件语法。当然,Makefile文件还有很多其它的语法,这里不可能一一描述。推荐一本书《GNU make中文手册》,里面非常详细地介绍了make以及Makefile文件语法。
整个工程只有一个Makefile,听起来似乎是一件很疯狂的事情,因为这个Makefile可能会变得无比庞大和复杂。其实不用担心,我们可以按照模块来将这个Makefile划分成一个个Makefile片段(fragement),然后通过Makefile的include指令来将这些Makefile片段组装在一个Makefile中。与递归Makefile相比,每一个模块现在拥有的是一个Makefile片段,而不是一个Makefile文件。这正是Android编译系统的设计思想和原则,也就是说,我们平时所编写的Android.mk编译脚本都只不过是整个Android编译系统的一个Makefile片段。
明白了Android编译系统的设计思想和原则之后,我们就可以通过图5来观察一下Android编译系统的整体架构了:
图5 Android编译系统架构
在使用Android编译系统之前,我们需要打开一个shell进入到Android源码根目录中,并且在该shell中将build/envsetup.sh脚本文件source进来。脚本文件build/envsetup.sh被source到当前shell的过程中,会在vendor和device两个目录将厂商指定的envsetup.sh也source到当前shell当中,这样就可以获得厂商提供的产品配置信息。此外,脚本文件build/envsetup.sh还提供了以下几个重要的命令来帮助我们编译Android源码:
1. lunch
用来初始化编译环境,例如设置环境变量和指定目标产品型号。Lunch命令在执行的时候,主要做两件事情。第一件事情是设置TARGET_PRODUCT、TARGET_BUILD_VARIANT、TARGET_BUILD_TYPE和TARGET_BUILD_APPS等环境变量,用来指定目标产品类型和编译类型。第二件事情是通过make命令执行build/core/config.mk脚本,并且通过加载另外一个脚本build/core/dumpvar.mk打印出当前的编译环境配置信息。注意,build/core/config.mk和build/core/dumpvar.mk均为Makefile脚本,因此它们可以通过make命令来执行。另外,build/core/config.mk脚本还会加载一个名称为BoradConfig.mk的脚本以及build/core/envsetup.mk脚本来配置目标产品型号的相关信息。
2. m
相当于是在执行make命令。对整个Android源码进行编译。
3. mm
如果是在Android源码根目录下执行,那么就相当于是执行make命令对整个源码进行编译。如果是在Android源码根目录下的某一个子目录执行,那么就在会在从该子目录开始,一直往上一个目录直至到根目录,寻找是否存在一个Android.mk文件。如果存在的话,那么就通过make命令对该Android.mk文件描述的模块进行编译。
4. mmm
后面可以跟一个或者若干个目录。如果指定了多个目录,那么目录之间以空格分隔,并且每一个目录下都必须存在一个Android,mk文件。如果没有在目录后面通过冒号指定模块名称,那么在Android.mk文件中描述的所有模块都会被编译,否则只有指定的模块会被编译。如果需要同时指定多个模块,那么这些模块名称必须以逗号分隔。它的语法如下所示:
[html] view plaincopy
- mmm <dir-1> <dir-2> ... <dir-N>[:module-1,module-2,...,module-M]
该命令会通过make命令来执行Android源码根目录下的Makefile文件,该Makefile文件又会将build/core/main.mk加载进来。文件build/core/main.mk在加载的过程中,还会加载以下几个主要的文件:
(1). build/core/config.mk
该文件根据lunch命令所配置的产品信息在build/target/board、vendor或者device目录中找到对应的BoradConfig.mk文件,以及通过加载build/core/product_config.mk文件在build/target/product、vendor或者device目录中找到对应的AndroidProducts.mk文件,来进一步对编译环境进行配置,以便接下来编译指定模块时可以获得必要的信息。
(2). build/core/definitions.mk
该文件定义了在编译过程需要调用到的各种自定义函数。
(3). 指定的Android.mk
这些指定的Android.mk环境是由mmm命令通过环境变量ONE_SHOT_MAKEFILE传递给build/core/main.mk文件使用的。这些Android.mk文件一般还会通过环境变量BUILD_PACKAGE、BUILD_JAVA_LIBRARY、BUILD_STATIC_JAVA_LIBRARY、BUILD_SHARED_LIBRARY、BUILD_STATIC_LIBRARY、BUILD_EXECUTABLE和BUILD_PREBUILT将build/core/package.mk、build/core/java_library.mk、build/core/static_java_library.mk、build/core/shared_library.mk、build/core/static_library.mk、build/core/executable.mk和build/core/prebuilt.mk等编译片段模板文件加载进来,来表示要编译是APK、Java库、Linux动态库/静态库/可执行文件或者预先编译好的文件等等。
(4). build/core/Makefile
该文件包含了用来制作system.img、ramdisk.img、boot.img和recovery.img等镜像文件的脚本。
第二部分:Android编译环境初始化
对编译环境进行初始化,其中最主要就是指定编译的类型和目标设备的型号。Android的编译类型主要有eng、userdebug和user三种,而支持的目标设备型号则是不确定的,它们由当前的源码配置情况所决定。为了确定源码支持的所有目标设备型号,Android编译系统在初始化的过程中,需要在特定的目录中加载特定的配置文件。
Android的优势就在于其开源,
我们在对Android的源码进行定制的时候,很有必要了解下,Android的编译过程。
如果你从来没有做过Android代码的编译,那么最官方的编译过程就是查看Android的官方网站:http://source.android.com/source/building.html
但是,这儿只是告诉你了如何去编译一个通用的系统,并没有详细告诉你细节,我们跟着编译过程来了解下。
按照google给出的编译步骤如下:
1> source build/envsetup.sh:加载命令
2> lunch:选择平台编译选项
3> make:执行编译
我们按照编译步骤来分析编译过程的细节,最终添加自己的平台编译选项。
1. source build/envsetup.sh
这个命令是用来将envsetup.sh里的所有用到的命令加载到环境变量里去,我们来分析下它。
envsetup.sh里的主要命令如下:
[html] view plain copy
- function help() # 显示帮助信息
- function get_abs_build_var() # 获取绝对变量
- function get_build_var() # 获取绝对变量
- function check_product() # 检查product
- function check_variant() # 检查变量
- function setpaths() # 设置文件路径
- function printconfig() # 打印配置
- function set_stuff_for_environment() # 设置环境变量
- function set_sequence_number() # 设置序号
- function settitle() # 设置标题
- function choosetype() # 设置type
- function chooseproduct() # 设置product
- function choosevariant() # 设置variant
- function tapas() # 功能同choosecombo
- function choosecombo() # 设置编译参数
- function add_lunch_combo() # 添加lunch项目
- function print_lunch_menu() # 打印lunch列表
- function lunch() # 配置lunch
- function m() # make from top
- function findmakefile() # 查找makefile
- function mm() # make from current directory
- function mmm() # make the supplied directories
- function croot() # 回到根目录
- function cproj()
- function pid()
- function systemstack()
- function gdbclient()
- function jgrep() # 查找java文件
- function cgrep() # 查找c/cpp文件
- function resgrep()
- function tracedmdump()
- function runhat()
- function getbugreports()
- function startviewserver()
- function stopviewserver()
- function isviewserverstarted()
- function smoketest()
- function runtest()
- function godir () # 跳到指定目录 405
- # add_lunch_combo函数被多次调用,就是它来添加Android编译选项
- # Clear this variable. It will be built up again when the vendorsetup.sh
- # files are included at the end of this file.
- # 清空LUNCH_MENU_CHOICES变量,用来存在编译选项
- unset LUNCH_MENU_CHOICES
- function add_lunch_combo()
- {
- local new_combo=$1 # 获得add_lunch_combo被调用时的参数
- local c
- # 依次遍历LUNCH_MENU_CHOICES里的值,其实该函数第一次调用时,该值为空
- for c in ${LUNCH_MENU_CHOICES[@]} ; do
- if [ "$new_combo" = "$c" ] ; then # 如果参数里的值已经存在于LUNCH_MENU_CHOICES变量里,则返回
- return
- fi
- done
- # 如果参数的值不存在,则添加到LUNCH_MENU_CHOICES变量里
- LUNCH_MENU_CHOICES=(${LUNCH_MENU_CHOICES[@]} $new_combo)
- }
- # 这是系统自动增加了一个默认的编译项 generic-eng
- # add the default one here
- add_lunch_combo generic-eng # 调用上面的add_lunch_combo函数,将generic-eng作为参数传递过去
- # if we're on linux, add the simulator. There is a special case
- # in lunch to deal with the simulator
- if [ "$(uname)" = "Linux" ] ; then
- add_lunch_combo simulator
- fi
- # 下面的代码很重要,它要从vendor目录下查找vendorsetup.sh文件,如果查到了,就加载它
- # Execute the contents of any vendorsetup.sh files we can find.
- for f in `/bin/ls vendor/*/vendorsetup.sh vendor/*/build/vendorsetup.sh 2> /dev/null`
- do
- echo "including $f"
- . $f # 执行找到的脚本,其实里面就是厂商自己定义的编译选项
- done
- unset f
envsetup.sh其主要作用如下:
1. 加载了编译时使用到的函数命令,如:help,lunch,m,mm,mmm等
2. 添加了两个编译选项:generic-eng和simulator,这两个选项是系统默认选项
3. 查找vendor/<-厂商目录>/和vendor/<厂商目录>/build/目录下的vendorsetup.sh,如果存在的话,加载执行它,添加厂商自己定义产品的编译选项
其实,上述第3条是向编译系统添加了厂商自己定义产品的编译选项,里面的代码就是:add_lunch_combo xxx-xxx。
根据上面的内容,可以推测出,如果要想定义自己的产品编译项,简单的办法是直接在envsetup.sh最后,添加上add_lunch_combo myProduct-eng,当然这么做,不太符合上面代码最后的本意,我们还是老实的在vendor目录下创建自己公司名字,然后在公司目录下创建一个新的vendorsetup.sh,在里面添加上自己的产品编译项
|
这样,当我们在执行source build/envsetup.sh命令的时候,可以在shell上看到下面的信息:
|
2. 按照android官网的步骤,开始执行lunch full-eng
当然如果你按上述命令执行,它编译的还是通用的eng版本系统,不是我们个性系统,我们可以执行lunch命令,它会打印出一个选择菜单,列出可用的编译选项
如果你按照第一步中添加了vendorsetup.sh那么,你的选项中会出现:
|
其中第3项是我们自己添加的编译项。
lunch命令是envsetup.sh里定义的一个命令,用来让用户选择编译项,来定义Product和编译过程中用到的全局变量。
我们一直没有说明前面的fs100-eng是什么意思,现在来说明下,fs100是我定义的产品的名字,eng是产品的编译类型,除了eng外,还有user, userdebug,分别表示:
eng: 工程机,
user:最终用户机
userdebug:调试测试机
tests:测试机
由此可见,除了eng和user外,另外两个一般不能交给最终用户的,记得m8出来的时候,先放出了一部分eng工程机,然后出来了user机之后,可以用工程机换。
那么这四个类型是干什么用的呢?其实,在main.mk里有说明,在Android的源码里,每一个目标(也可以看成工程)目录都有一个Android.mk的makefile,每个目标的Android.mk中有一个类型声明:LOCAL_MODULE_TAGS,这个TAGS就是用来指定,当前的目标编译完了属于哪个分类里。
PS:Android.mk和Linux里的makefile不太一样,它是Android编译系统自己定义的一个makefile来方便编译成:c,c++的动态、静态库或可执行程序,或java库或android的程序,
好了,我们来分析下lunch命令干了什么?
[html] view plain copy
- function lunch()
- {
- local answer
- if [ "$1" ] ; then
- # lunch后面直接带参数
- answer=$1
- else
- # lunch后面不带参数,则打印处所有的target product和variant菜单提供用户选择
- print_lunch_menu
- echo -n "Which would you like? [generic-eng] "
- read answer
- fi
- local selection=
- if [ -z "$answer" ]
- then
- # 如果用户在菜单中没有选择,直接回车,则为系统缺省的generic-eng
- selection=generic-eng
- elif [ "$answer" = "simulator" ]
- then
- # 如果是模拟器
- selection=simulator
- elif (echo -n $answer | grep -q -e "^[0-9][0-9]*$")
- then
- # 如果answer是选择菜单的数字,则获取该数字对应的字符串
- if [ $answer -le ${#LUNCH_MENU_CHOICES[@]} ]
- then
- selection=${LUNCH_MENU_CHOICES[$(($answer-$_arrayoffset))]}
- fi
- # 如果 answer字符串匹配 *-*模式(*的开头不能为-)
- elif (echo -n $answer | grep -q -e "^[^\-][^\-]*-[^\-][^\-]*$")
- then
- selection=$answer
- fi
- if [ -z "$selection" ]
- then
- echo
- echo "Invalid lunch combo: $answer"
- return 1
- fi
- # special case the simulator
- if [ "$selection" = "simulator" ]
- then
- # 模拟器模式
- export TARGET_PRODUCT=sim
- export TARGET_BUILD_VARIANT=eng
- export TARGET_SIMULATOR=true
- export TARGET_BUILD_TYPE=debug
- else
- # 将 product-variant模式中的product分离出来
- local product=$(echo -n $selection | sed -e "s/-.*$//")
- # 检查之,调用关系 check_product()->get_build_var()->build/core/config.mk比较罗嗦,不展开了
- check_product $product
- if [ $? -ne 0 ]
- then
- echo
- echo "** Don't have a product spec for: '$product'"
- echo "** Do you have the right repo manifest?"
- product=
- fi
- # 将 product-variant模式中的variant分离出来
- local variant=$(echo -n $selection | sed -e "s/^[^\-]*-//")
- # 检查之,看看是否在 (user userdebug eng) 范围内
- check_variant $variant
- if [ $? -ne 0 ]
- then
- echo
- echo "** Invalid variant: '$variant'"
- echo "** Must be one of ${VARIANT_CHOICES[@]}"
- variant=
- fi
- if [ -z "$product" -o -z "$variant" ]
- then
- echo
- return 1
- fi
- # 导出环境变量,这里很重要,因为后面的编译系统都是依赖于这里定义的几个变量的
- export TARGET_PRODUCT=$product
- export TARGET_BUILD_VARIANT=$variant
- export TARGET_SIMULATOR=false
- export TARGET_BUILD_TYPE=release
- fi # !simulator
- echo
- # 设置到环境变量,比较多,不再一一列出,最简单的方法 set >env.txt 可获得
- set_stuff_for_environment
- # 打印一些主要的变量, 调用关系 printconfig()->get_build_var()->build/core/config.mk->build/core/envsetup.mk 比较罗嗦,不展开了
- printconfig
- }
由上面分析可知,lunch命令可以带参数和不带参数,最终导出一些重要的环境变量,从而影响编译系统的编译结果。导出的变量如下(以实际运行情况为例)
|
执行完上述两个步骤,就该执行:make命令了,下篇来分析。
1. make
执行make命令的结果就是去执行当前目录下的Makefile文件,我们来看下它的内容:
|
呵呵,看到上面 的内容,我们都会笑,这是我见过最简单的Makefile了,我们再看下build/core/main.mk
main.mk文件里虽然脚本不多,但是却定义了整个Android的编译关系,它主要引入了下列几个重要的mk文件:
49 include $(BUILD_SYSTEM)/config.mk
55 include $(BUILD_SYSTEM)/cleanbuild.mk
142 include $(BUILD_SYSTEM)/definitions.mk
当然每个mk文件都有自己独特的意义,我们一并将主线流程相关mk文件都列出来,大概来介绍下,先有个整体的概念,然后再细化了解。
所有的Makefile都通过build/core/main.mk这个文件组织在一起,它定义了一个默认goals:droid,当我们在TOP目录下,敲Make实际上就等同于我们执行make droid。
当Make include所有的文件,完成对所有make我文件的解析以后就会寻找生成droid的规则,依次生成它的依赖,直到所有满足的模块被编译好,然后使用相应的工具打包成相应的img。其中,config.mk,envsetup.mk,product_config.mk文件是编译用户指定平台系统的关键文件。上图中红色部分是用户指定平台产品的编译主线,我们先来看下config.mk的主要作用。
2. build/core/config.mk
该文件被main.mk包含。
定义了以下环境变量:
|
[plain] view plain copy
- 上述命令变量其实是对应的mk文件名,所有的Android.mk文件里基本上都包含上述命令变量,如:
CLEAR_VARS:用来清除之前定义的环境变量
BUILD_SHARED_LIBRARY:用来指定编译动态库过程
|
112行又包含了另外一个重要的mk文件envsetup.mk,我们来看一下。
3. envsetup.mk
25 ifeq ($(TARGET_PRODUCT),) #判断TARGET_PRODUCT是否为空,
26 ifeq ($(TARGET_SIMULATOR),true)
27 TARGET_PRODUCT := sim
28 else
29 TARGET_PRODUCT := generic
30 endif
31 endif
第25行,判断TARGET_PRODUCT是否为空,根据上一节分析可知,TARGET_PRODUCT=fs100
34 # the variant -- the set of files that are included for a build
35 ifeq ($(strip $(TARGET_BUILD_VARIANT)),)
36 TARGET_BUILD_VARIANT := eng
37 endif
38
39 # Read the product specs so we an get TARGET_DEVICE and other
40 # variables that we need in order to locate the output files.
41 include $(BUILD_SYSTEM)/product_config.mk
在41行又包含了product_config.mk文件,等会我们再分析它,先看下面的
148 # ---------------------------------------------------------------
149 # figure out the output directories
150
151 ifeq (,$(strip $(OUT_DIR)))
152 OUT_DIR := $(TOPDIR)out
153 endif
154
155 DEBUG_OUT_DIR := $(OUT_DIR)/debug
156
157 # Move the host or target under the debug/ directory
158 # if necessary.
159 TARGET_OUT_ROOT_release := $(OUT_DIR)/target
160 TARGET_OUT_ROOT_debug := $(DEBUG_OUT_DIR)/target
161 TARGET_OUT_ROOT := $(TARGET_OUT_ROOT_$(TARGET_BUILD_TYPE))
162
...
184 PRODUCT_OUT := $(TARGET_PRODUCT_OUT_ROOT)/$(TARGET_DEVICE)
187
188 HOST_OUT_EXECUTABLES:= $(HOST_OUT)/bin
189 HOST_OUT_SHARED_LIBRARIES:= $(HOST_OUT)/lib
190 HOST_OUT_JAVA_LIBRARIES:= $(HOST_OUT)/framework
191 HOST_OUT_SDK_ADDON := $(HOST_OUT)/sdk_addon
...
200 TARGET_OUT_INTERMEDIATES := $(PRODUCT_OUT)/obj
201 TARGET_OUT_HEADERS:= $(TARGET_OUT_INTERMEDIATES)/include
202 TARGET_OUT_INTERMEDIATE_LIBRARIES := $(TARGET_OUT_INTERMEDIATES)/lib
203 TARGET_OUT_COMMON_INTERMEDIATES := $(TARGET_COMMON_OUT_ROOT)/obj
204
205 TARGET_OUT := $(PRODUCT_OUT)/system
206 TARGET_OUT_EXECUTABLES:= $(TARGET_OUT)/bin
207 TARGET_OUT_OPTIONAL_EXECUTABLES:= $(TARGET_OUT)/xbin
208 TARGET_OUT_SHARED_LIBRARIES:= $(TARGET_OUT)/lib
209 TARGET_OUT_JAVA_LIBRARIES:= $(TARGET_OUT)/framework
210 TARGET_OUT_APPS:= $(TARGET_OUT)/app
211 TARGET_OUT_KEYLAYOUT := $(TARGET_OUT)/usr/keylayout
212 TARGET_OUT_KEYCHARS := $(TARGET_OUT)/usr/keychars
213 TARGET_OUT_ETC := $(TARGET_OUT)/etc
214 TARGET_OUT_STATIC_LIBRARIES:= $(TARGET_OUT_INTERMEDIATES)/lib
215 TARGET_OUT_NOTICE_FILES:=$(TARGET_OUT_INTERMEDIATES)/NOTICE_FILES
216
217 TARGET_OUT_DATA := $(PRODUCT_OUT)/data
218 TARGET_OUT_DATA_EXECUTABLES:= $(TARGET_OUT_EXECUTABLES)
219 TARGET_OUT_DATA_SHARED_LIBRARIES:= $(TARGET_OUT_SHARED_LIBRARIES)
220 TARGET_OUT_DATA_JAVA_LIBRARIES:= $(TARGET_OUT_JAVA_LIBRARIES)
221 TARGET_OUT_DATA_APPS:= $(TARGET_OUT_DATA)/app
222 TARGET_OUT_DATA_KEYLAYOUT := $(TARGET_OUT_KEYLAYOUT)
223 TARGET_OUT_DATA_KEYCHARS := $(TARGET_OUT_KEYCHARS)
224 TARGET_OUT_DATA_ETC := $(TARGET_OUT_ETC)
225 TARGET_OUT_DATA_STATIC_LIBRARIES:= $(TARGET_OUT_STATIC_LIBRARIES)
226
227 TARGET_OUT_UNSTRIPPED := $(PRODUCT_OUT)/symbols
228 TARGET_OUT_EXECUTABLES_UNSTRIPPED := $(TARGET_OUT_UNSTRIPPED)/system/bin
229 TARGET_OUT_SHARED_LIBRARIES_UNSTRIPPED := $(TARGET_OUT_UNSTRIPPED)/system/lib
230 TARGET_ROOT_OUT_UNSTRIPPED := $(TARGET_OUT_UNSTRIPPED)
231 TARGET_ROOT_OUT_SBIN_UNSTRIPPED := $(TARGET_OUT_UNSTRIPPED)/sbin
232 TARGET_ROOT_OUT_BIN_UNSTRIPPED := $(TARGET_OUT_UNSTRIPPED)/bin
233
234 TARGET_ROOT_OUT := $(PRODUCT_OUT)/root
235 TARGET_ROOT_OUT_BIN := $(TARGET_ROOT_OUT)/bin
236 TARGET_ROOT_OUT_SBIN := $(TARGET_ROOT_OUT)/sbin
237 TARGET_ROOT_OUT_ETC := $(TARGET_ROOT_OUT)/etc
238 TARGET_ROOT_OUT_USR := $(TARGET_ROOT_OUT)/usr
239
240 TARGET_RECOVERY_OUT := $(PRODUCT_OUT)/recovery
241 TARGET_RECOVERY_ROOT_OUT := $(TARGET_RECOVERY_OUT)/root
242
243 TARGET_SYSLOADER_OUT := $(PRODUCT_OUT)/sysloader
244 TARGET_SYSLOADER_ROOT_OUT := $(TARGET_SYSLOADER_OUT)/root
245 TARGET_SYSLOADER_SYSTEM_OUT := $(TARGET_SYSLOADER_OUT)/root/system
246
247 TARGET_INSTALLER_OUT := $(PRODUCT_OUT)/installer
248 TARGET_INSTALLER_DATA_OUT := $(TARGET_INSTALLER_OUT)/data
249 TARGET_INSTALLER_ROOT_OUT := $(TARGET_INSTALLER_OUT)/root
250 TARGET_INSTALLER_SYSTEM_OUT := $(TARGET_INSTALLER_OUT)/root/system
上面的代码是指定了目标输出代码的位置和主机输出代码的位置,重要的几个如下:PRODUCT_OUT = 这个的结果要根据product_config.mk文件内容来决定,其实是out/target/product/fs100/
TARGET_OUT = $(PRODUCT_OUT)/system
TARGET_OUT_EXECUTABLES = $(PRODUCT_OUT)/system/bin
TARGET_OUT_SHARED_LIBRARIES = $(PRODUCT_OUT)/system/lib
TARGET_OUT_JAVA_LIBRARIES = $(PRODUCT_OUT)/system/framework
TARGET_OUT_APPS = $(PRODUCT_OUT)/system/app
TARGET_OUT_ETC = $(PRODUCT_OUT)/system/etc
TARGET_OUT_STATIC_LIBRARIES = $(PRODUCT_OUT)/obj/lib
TARGET_OUT_DATA = $(PRODUCT_OUT)/data
TARGET_OUT_DATA_APPS = $(PRODUCT_OUT)/data/app
TARGET_ROOT_OUT = $(PRODUCT_OUT)/root
TARGET_ROOT_OUT_BIN = $(PRODUCT_OUT)/bin
TARGET_ROOT_OUT_SBIN = $(PRODUCT_OUT)/system/sbin
TARGET_ROOT_OUT_ETC = $(PRODUCT_OUT)/system/etc
TARGET_ROOT_OUT_USR = $(PRODUCT_OUT)/system/usr
总结下:
envsetup.mk文件主要包含了product_config.mk文件,然后指定了编译时要输出的所有文件的OUT目录。
4. build/core/product_config.mk157 include $(BUILD_SYSTEM)/product.mk
...
160 # Read in all of the product definitions specified by the AndroidProducts.mk
161 # files in the tree.
162 #
163 #TODO: when we start allowing direct pointers to product files,
164 # guarantee that they're in this list.
165 $(call import-products, $(get-all-product-makefiles))
166 $(check-all-products)
...
170 # Convert a short name like "sooner" into the path to the product
171 # file defining that product.
172 #
173 INTERNAL_PRODUCT := $(call resolve-short-product-name, $(TARGET_PRODUCT))
...
176 # Find the device that this product maps to.
177 TARGET_DEVICE := $(PRODUCTS.$(INTERNAL_PRODUCT).PRODUCT_DEVICE)
157行,我靠,又包含了product.mk文件
165行,调用函数import-products, $(get-all-product-makefiles),这儿我们看上面的注释:
Read in all of the product definitions specified by the AndroidProducts.mk files in the tree.
TODO: when we start allowing direct pointers to product files, guarantee that they're in this list.
意思是说:读取指定的目录下所有的AndrodProducts.mk文件中定义的产品信息
其实get-all-product-makefiles返回所有的产品文件xxx.mk
import-products函数去验证这些产品配置文件是否都包含有必须的配置信息,细节后面分析。
173行调用了resolve-short-product-name函数,它将返回TARGET_PRODUCT产品的配置文件目录,并赋给INTERNAL_PRODUCT
也就是说:
INTERNAL_PRODUCT = vendor/farsight/products/fs100.mk
TARGET_DEVICE = fs100
如果调试看其结果,可以在167行,将#$(dump-product)取消注释
然后在175行添加: $(info $(INTERNAL_PRODUCT))
在178行添加: $(info $(TARGET_DEVICE )),查看调试结果。
总结一下:
接合前面的图,product_config.mk主要读取vendor目录下不同厂商自己定义的AndrodProducts.mk文件,从该文件里取得所有产品的配置文件,然后再根据lunch选择的编译项TARGET_PRODUCT,找到与之对应的配置文件,然后设置TARGET_DEVICE变量,用于后续编译。
5. build/core/product.mk17 #
18 # Functions for including AndroidProducts.mk files
19 #
20
21 #
22 # Returns the list of all AndroidProducts.mk files.
23 # $(call ) isn't necessary.
24 #
25 define _find-android-products-files
26 $(shell test -d vendor && find vendor -maxdepth 6 -name AndroidProducts.mk) \
27 $(SRC_TARGET_DIR)/product/AndroidProducts.mk
28 endef
29
30 #
31 # Returns the sorted concatenation of all PRODUCT_MAKEFILES
32 # variables set in all AndroidProducts.mk files.
33 # $(call ) isn't necessary.
34 #
35 define get-all-product-makefiles
36 $(sort \
37 $(foreach f,$(_find-android-products-files), \
38 $(eval PRODUCT_MAKEFILES :=) \
39 $(eval LOCAL_DIR := $(patsubst %/,%,$(dir $(f)))) \
40 $(eval include $(f)) \
41 $(PRODUCT_MAKEFILES) \
42 ) \
43 $(eval PRODUCT_MAKEFILES :=) \
44 $(eval LOCAL_DIR :=) \
45 )
46 endef
[plain] view plain copy
- 通过注释可知,本文件中主要是一些用来处理AndroidProduct.mk的函数<br style="box-sizing: border-box;" /><span style="box-sizing: border-box;">_find-android-products-files:</span>
用来获得vendor目录下,所有名字为AndroidProduct.mk的文件列表。
get-all-product-makefiles:
用来获得所有AndroidProduct.mk文件里定义的PRODUCT_MAKEFILES的值(其实是产品文件路径名)。
在vendor目录下,每个公司目录下都会存在一个AndroidProduct.mk文件,这个文件是用来定义这个公司的产品列表,每个产品用<product_name>.mk来表示
如Android给的示例:
[plain] view plain copy
- vendor/sample/products/AndroidProduct.mk
其内容如下:1 #
2 # This file should set PRODUCT_MAKEFILES to a list of product makefiles
3 # to expose to the build system. LOCAL_DIR will already be set to
4 # the directory containing this file.
5 #
6 # This file may not rely on the value of any variable other than
7 # LOCAL_DIR; do not use any conditionals, and do not look up the
8 # value of any variable that isn't set in this file or in a file that
9 # it includes.
10 #
11
12 PRODUCT_MAKEFILES := \
13 $(LOCAL_DIR)/sample_addon.mk
[plain] view plain copy
- 里面只定义了一个产品配置文件,即当前目录下的sample_addon.mk:
1 # List of apps and optional libraries (Java and native) to put in the add-on system image.
2 PRODUCT_PACKAGES := \
3 PlatformLibraryClient \
4 com.example.android.platform_library \
5 libplatform_library_jni
上述文件里定义了产品相关个性化信息,如,PRODUCT_PACKAGES表示要在当前产品里添加一些安装包。
由此可见,get-all-product-makefiles函数,其实就是返回了当前公司里全部的产品对应的mk文件列表。
总结:
如果用户想个性定制自己的产品,应该有以下流程,包含上一节内容:
1. 创建公司目录
#mkdir vendor/farsight
2. 创建一个vendorsetup.sh文件,将当前产品编译项添加到lunch里,让lunch能找到用户个性定制编译项
#echo "add_lunch_combo fs100-eng" > vendor/farsight/vendorsetup.sh
3. 仿着Android示例代码,在公司目录下创建products目录
#mkdir -p vendor/farsight/products
4. 仿着Android示例代码,在products目录下创建两个mk文件
#touch vendor/farsight/products/AndroidProduct.mk vendor/farsight/products/fs100.mk
在AndroidProduct.mk里添加如下内容:
[plain] view plain copy
- PRODUCT_MAKEFILES := $(LOCAL_DIR)/fs100.mk
表示只有一个产品fs100,它对应的配置文件在当前目录下的fs100.mk。
5. 在产品配置文件里添加最基本信息
1
2 PRODUCT_PACKAGES := \
3 IM \
4 VoiceDialer
5
6 $(call inherit-product, build/target/product/generic.mk) ##从某一默认配置开始派生余下内容参考派生起点
7
8 # Overrides
9 PRODUCT_MANUFACTURER := farsight
10 PRODUCT_NAME := fs100
11 PRODUCT_DEVICE := fs100
前面两节讲解了自定义Android编译项和创建Product产品配置文件,除了编译和定义产品相关环境变量外,还需要定义Board相关环境变量。
1. build/core/config.mk
109 # ---------------------------------------------------------------
110 # Define most of the global variables. These are the ones that
111 # are specific to the user's build configuration.
112 include $(BUILD_SYSTEM)/envsetup.mk
113
114 # Boards may be defined under $(SRC_TARGET_DIR)/board/$(TARGET_DEVICE)
115 # or under vendor/*/$(TARGET_DEVICE). Search in both places, but
116 # make sure only one exists.
117 # Real boards should always be associated with an OEM vendor.
118 board_config_mk := \
119 $(strip $(wildcard \
120 $(SRC_TARGET_DIR)/board/$(TARGET_DEVICE)/BoardConfig.mk \
121 vendor/*/$(TARGET_DEVICE)/BoardConfig.mk \
122 ))
123 ifeq ($(board_config_mk),)
124 $(error No config file found for TARGET_DEVICE $(TARGET_DEVICE))
125 endif
126 ifneq ($(words $(board_config_mk)),1)
127 $(error Multiple board config files for TARGET_DEVICE $(TARGET_DEVICE): $(board_config_mk))
128 endif
129 include $(board_config_mk)
130 TARGET_DEVICE_DIR := $(patsubst %/,%,$(dir $(board_config_mk)))
131 board_config_mk :=
[plain] view plain copy
- <span style="box-sizing: border-box;">上述代码在上一节已经见到过,只是分析了112行的envsetup.mk,根据上一节内容可知,</span>envsetup.mk设置了很多OUT变量,最终在build/core/product_config.mk文件里,设置了TARGET_DEVICE = fs100。
我们从114行继续分析。
从114~117行解释大意可知:
Board相关配置文件会存在于$(SRC_TARGET_DIR)/board/$(TARGET_DEVICE)/或vendor/*/$(TARGET_DEVICE)/目录中,一个Vendor厂商只能有一个对应的Board配置文件。
118行定义board_config_mk变量:
$(wildcard xxx)函数就是找到与xxx的匹配项放到空格列表里,前面定义TARGET_DEVICE变量 = fs100,所以$(SRC_TARGET_DIR)/board/fs100/BoardConfig.mk不存在,必须要存在vendor/*/fs100/BoardConfig.mk文件来定义开发板配置信息。
129行,通过include将vendor/*/fs100/BoardConfig.mk包含进来,
130行,TARGET_DEVICE_DIR为board_config_mk的路径,即:vendor/*/fs100
总结:
一个vendor厂商必须要有一个对应的Board配置文件,即:vendor/*/fs100/BoardConfig.mk
定义了TARGET_DEVICE_DIR变量,为board_config_mk的路径,即:vendor/*/fs100
指定board 相关特性,一定要包含:
TARGET_CPU_ABI := armeabi/...
其他属性参见其他board样例.(build/target/board/XXX
2. build/core/main.mk141 # Bring in standard build system definitions.
142 include $(BUILD_SYSTEM)/definitions.mk
...
347 ifeq ($(SDK_ONLY),true)
348
349 # ----- SDK for Windows ------
350 # These configure the build targets that are available for the SDK under Cygwin.
351 # The first section defines all the C/C++ tools that can be compiled under Cygwin,
352 # the second section defines all the Java ones (assuming javac is available.)
353
354 subdirs := \
355 prebuilt \
356 build/libs/host \
357 build/tools/zipalign \
...
382 # The following can only be built if "javac" is available.
383 # This check is used when building parts of the SDK under Cygwin.
384 ifneq (,$(shell which javac 2>/dev/null))
385 $(warning sdk-only: javac available.)
386 subdirs += \
387 build/tools/signapk \
388 dalvik/dx \
389 dalvik/libcore \
...
414 else # !SDK_ONLY
415 ifeq ($(BUILD_TINY_ANDROID), true)
416
417 # TINY_ANDROID is a super-minimal build configuration, handy for board
418 # bringup and very low level debugging
419
420 subdirs := \
421 bionic \
422 system/core \
423 build/libs \
424 build/target \
...
433 else # !BUILD_TINY_ANDROID
434
435 #
436 # Typical build; include any Android.mk files we can find.
437 #
438 subdirs := $(TOP)
439
440 FULL_BUILD := true
441
442 endif # !BUILD_TINY_ANDROID
443
444 endif # !SDK_ONLY
...
464 #
465 # Include all of the makefiles in the system
466 #
467
468 # Can't use first-makefiles-under here because
469 # --mindepth=2 makes the prunes not work.
470 subdir_makefiles := \
471 $(shell build/tools/findleaves.py --prune=out --prune=.repo --prune=.git $(subdirs) Android.mk)
472
473 include $(subdir_makefiles)
上一节只是讲了main.mk第49行中包含了config.mk,我们继续分析。
142行包含了:build/core/definitions.mk,该文件定义了很多全局变量与函数。
如下列常见函数:
my-dir:返回当前路径
all-java-files-under:获得指定目录及子目录一所有java文件
all-subdir-c-files:获得当前目录下及子目录下所有c文件
354~444行,定义了subdirs变量,依据不同的用户编译条件,而包含Android源码中不同的目录。
470行,定义了subdir_makefile变量,其值为subdirs定义的目录中的Android.mk文件。
473行,将所有编译目录中的Android.mk文件包含进来。
3. build/target/board/Android.mk 26 ifeq (,$(wildcard $(TARGET_DEVICE_DIR)/AndroidBoard.mk))
27 ifeq (,$(wildcard $(TARGET_DEVICE_DIR)/Android.mk))
28 $(error Missing "$(TARGET_DEVICE_DIR)/AndroidBoard.mk")
29 else
30 # TODO: Remove this check after people have had a chance to switch,
31 # after April 2009.
32 $(error Please rename "$(TARGET_DEVICE_DIR)/Android.mk" to "$(TARGET_DEVICE_DIR)/AndroidBoard.mk")
33 endif
34 endif
35 include $(TARGET_DEVICE_DIR)/AndroidBoard.mk
[plain] view plain copy
- 由于将所有目录中Android.mk文件include进来,build/target/board/Android.mk自然被包含进来,根据前面分析,TARGET_DEVICE_DIR = </span>vendor/*/fs100,<span style="box-sizing: border-box;">其中26~35行用来判断对应的产品目录下是否存在AndrodiBoard.mk,如果不存在,提示出错退出,如果存在,将其包含到编译脚本中。
由此可见:我们必须要在产品目录下创建AndrodiBoard.mk文件,来描述开发板相关配置项,我们可以借鉴:build/target/board/generic/AndroidBoard.mk内容,同时根据前面所分析,还要创建BoardConfig.mk文件。
$cp build/target/board/generic/AndroidBoard.mk build/target/board/generic/BoardConfig.mk vendor/farsight/fs100/
[plain] view plain copy
- <span style="box-sizing: border-box;">至此,自定义Android编译选项基本步骤已经分部分析完,细节还需要针对不同开发板具体分析。</span>
总结:
build/core/main.mk包含了config.mk,它主要定义了编译全部代码的依赖关系
build/core/config.mk 定义了大量的编译脚本命令,编译时用到的环境变量,引入了envsetup.mk 文件,加载board相关配置文件。
build/core/envsetup.mk 定义了编译时用到的大量OUT输出目录,加载product_config.mk文件
build/core/product_config.mk 定义了Vendor目录下Product相关配置文件解析脚本,读取AndrodProducts.mk生成TARGET_DEVICE变量
build/target/product product config
build/target/board board config
build/core/combo build flags config
这里解释下这里的board和product。borad主要是设计到硬件芯片的配置,比如是否提供硬件的某些功能,比如说GPU等等,或者芯片支持浮 点运算等等。product是指针对当前的芯片配置定义你将要生产产品的个性配置,主要是指APK方面的配置,哪些APK会包含在哪个product中, 哪些APK在当前product中是不提供的。
config.mk是一个总括性的东西,它里面定义了各种module编译所需要使用的HOST工具以及如何来编译各种模块,比如说 BUILT_PREBUILT就定义了如何来编译预编译模块。envsetup.mk主要会读取由envsetup.sh写入环境变量中的一些变量来配置编译过程中的输出目录,combo里面主要定义了各种Host和Target结合的编译器和编译选项。
1. 在vendor目录下创建自己公司目录,然后在公司目录下创建一个新的vendorsetup.sh,在里面添加上自己的产品编译项
$mkdir vendor/farsight/
$touch vendor/farsight/vendorsetup.sh
$echo "add_lunch_combo fs100-eng" > vendor/farsight/vendorsetup.sh
[plain] view plain copy
- <span style="box-sizing: border-box;">2. </span>仿着Android示例代码,在公司目录下创建products目录
$mkdir -p vendor/farsight/products
[plain] view plain copy
- <span style="box-sizing: border-box;">3. </span>仿着Android示例代码,在products目录下创建两个mk文件
$touch vendor/farsight/products/AndroidProduct.mk vendor/farsight/products/fs100.mk
[plain] view plain copy
- 在AndroidProduct.mk里添加如下内容:
PRODUCT_MAKEFILES := $(LOCAL_DIR)/fs100.mk
[plain] view plain copy
- 在产品配置文件里添加最基本信息
PRODUCT_PACKAGES := \
IM \
VoiceDialer
$(call inherit-product, build/target/product/generic.mk)
# Overrides
PRODUCT_MANUFACTURER := farsight
PRODUCT_NAME := fs100
PRODUCT_DEVICE := fs100
[plain] view plain copy
- 借鉴build/target/board/generic/AndroidBoard.mk和BoardConfig.mk,创建对应文件。
$cp build/target/board/generic/AndroidBoard.mk build/target/board/generic/BoardConfig.mk vendor/farsight/fs100/
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/huangxiaominglipeng/article/details/41745199