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 plain copy
 
 
  1. target: dependency  
  2. 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 plain copy
 
 
  1. 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
 
  1. function help()                  # 显示帮助信息  
  2. function get_abs_build_var()           # 获取绝对变量  
  3. function get_build_var()             # 获取绝对变量  
  4. function check_product()             # 检查product  
  5. function check_variant()             # 检查变量  
  6. function setpaths()                # 设置文件路径  
  7. function printconfig()              # 打印配置  
  8. function set_stuff_for_environment()        # 设置环境变量  
  9. function set_sequence_number()            # 设置序号  
  10. function settitle()                # 设置标题  
  11. function choosetype()               # 设置type  
  12. function chooseproduct()              # 设置product  
  13. function choosevariant()              # 设置variant  
  14. function tapas()                  # 功能同choosecombo  
  15. function choosecombo()               # 设置编译参数  
  16. function add_lunch_combo()             # 添加lunch项目  
  17. function print_lunch_menu()            # 打印lunch列表  
  18. function lunch()                 # 配置lunch  
  19. function m()                   # make from top  
  20. function findmakefile()              # 查找makefile  
  21. function mm()                   # make from current directory  
  22. function mmm()                   # make the supplied directories  
  23. function croot()                 # 回到根目录  
  24. function cproj()  
  25. function pid()  
  26. function systemstack()  
  27. function gdbclient()  
  28. function jgrep()                 # 查找java文件  
  29. function cgrep()                  # 查找c/cpp文件  
  30. function resgrep()  
  31. function tracedmdump()  
  32. function runhat()  
  33. function getbugreports()  
  34. function startviewserver()  
  35. function stopviewserver()  
  36. function isviewserverstarted()  
  37. function smoketest()  
  38. function runtest()  
  39. function godir ()                 # 跳到指定目录 405  
  40.   
  41.  # add_lunch_combo函数被多次调用,就是它来添加Android编译选项  
  42.  # Clear this variable.  It will be built up again when the vendorsetup.sh  
  43.  # files are included at the end of this file.  
  44.  # 清空LUNCH_MENU_CHOICES变量,用来存在编译选项  
  45.  unset LUNCH_MENU_CHOICES  
  46. function add_lunch_combo()     
  47. {  
  48.      local new_combo=$1         # 获得add_lunch_combo被调用时的参数  
  49.      local c  
  50.      # 依次遍历LUNCH_MENU_CHOICES里的值,其实该函数第一次调用时,该值为空  
  51.      for c in ${LUNCH_MENU_CHOICES[@]} ; do   
  52.          if [ "$new_combo" = "$c" ] ; then    # 如果参数里的值已经存在于LUNCH_MENU_CHOICES变量里,则返回  
  53.              return  
  54.          fi  
  55.      done  
  56.      # 如果参数的值不存在,则添加到LUNCH_MENU_CHOICES变量里  
  57.      LUNCH_MENU_CHOICES=(${LUNCH_MENU_CHOICES[@]} $new_combo)  
  58. }  
  59.   
  60.   
  61. # 这是系统自动增加了一个默认的编译项 generic-eng  
  62. # add the default one here  
  63. add_lunch_combo generic-eng    # 调用上面的add_lunch_combo函数,将generic-eng作为参数传递过去  
  64.    
  65. # if we're on linux, add the simulator.  There is a special case  
  66. # in lunch to deal with the simulator  
  67. if [ "$(uname)" = "Linux" ] ; then  
  68.      add_lunch_combo simulator  
  69. fi  
  70.   
  71. # 下面的代码很重要,它要从vendor目录下查找vendorsetup.sh文件,如果查到了,就加载它  
  72. # Execute the contents of any vendorsetup.sh files we can find.  
  73. for f in `/bin/ls vendor/*/vendorsetup.sh vendor/*/build/vendorsetup.sh 2> /dev/null`  
  74.    do  
  75.      echo "including $f"  
  76.      . $f       # 执行找到的脚本,其实里面就是厂商自己定义的编译选项  
  77.    done  
  78. 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,在里面添加上自己的产品编译项

 

#mkdir vendor/farsight/
#touch vendor/farsight/vendorsetup.sh
#echo "add_lunch_combo fs100-eng" > vendor/farsight/vendorsetup.sh

 

这样,当我们在执行source build/envsetup.sh命令的时候,可以在shell上看到下面的信息:

 

including vendor/farsight/vendorsetup.sh

 
2. 按照android官网的步骤,开始执行lunch full-eng

 

当然如果你按上述命令执行,它编译的还是通用的eng版本系统,不是我们个性系统,我们可以执行lunch命令,它会打印出一个选择菜单,列出可用的编译选项

如果你按照第一步中添加了vendorsetup.sh那么,你的选项中会出现:

 

You're building on Linux
 
generic-eng simulator fs100-eng
Lunch menu... pick a combo:
      1. generic-eng
      2. simulator
      3. fs100-eng

 

其中第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
 
  1. function lunch()  
  2. {  
  3.     local answer  
  4.   
  5.     if [ "$1" ] ; then  
  6.        # lunch后面直接带参数  
  7.         answer=$1  
  8.     else  
  9.        # lunch后面不带参数,则打印处所有的target product和variant菜单提供用户选择  
  10.         print_lunch_menu     
  11.         echo -n "Which would you like? [generic-eng] "  
  12.         read answer  
  13.     fi  
  14.   
  15.     local selection=  
  16.   
  17.     if [ -z "$answer" ]  
  18.     then  
  19.            # 如果用户在菜单中没有选择,直接回车,则为系统缺省的generic-eng  
  20.         selection=generic-eng  
  21.     elif [ "$answer" = "simulator" ]  
  22.     then  
  23.         # 如果是模拟器  
  24.         selection=simulator  
  25.     elif (echo -n $answer | grep -q -e "^[0-9][0-9]*$")  
  26.     then  
  27.         # 如果answer是选择菜单的数字,则获取该数字对应的字符串  
  28.         if [ $answer -le ${#LUNCH_MENU_CHOICES[@]} ]  
  29.         then  
  30.             selection=${LUNCH_MENU_CHOICES[$(($answer-$_arrayoffset))]}  
  31.         fi  
  32.         # 如果 answer字符串匹配 *-*模式(*的开头不能为-)  
  33.     elif (echo -n $answer | grep -q -e "^[^\-][^\-]*-[^\-][^\-]*$")  
  34.     then  
  35.         selection=$answer  
  36.     fi  
  37.   
  38.     if [ -z "$selection" ]  
  39.     then  
  40.         echo  
  41.         echo "Invalid lunch combo: $answer"  
  42.         return 1  
  43.     fi  
  44.   
  45.     # special case the simulator  
  46.     if [ "$selection" = "simulator" ]  
  47.     then  
  48.         # 模拟器模式  
  49.         export TARGET_PRODUCT=sim  
  50.         export TARGET_BUILD_VARIANT=eng  
  51.         export TARGET_SIMULATOR=true  
  52.         export TARGET_BUILD_TYPE=debug  
  53.     else  
  54.   
  55.         # 将 product-variant模式中的product分离出来  
  56.         local product=$(echo -n $selection | sed -e "s/-.*$//")  
  57.   
  58.         # 检查之,调用关系 check_product()->get_build_var()->build/core/config.mk比较罗嗦,不展开了  
  59.         check_product $product  
  60.         if [ $? -ne 0 ]  
  61.         then  
  62.             echo  
  63.             echo "** Don't have a product spec for: '$product'"  
  64.             echo "** Do you have the right repo manifest?"  
  65.             product=  
  66.         fi  
  67.   
  68.         # 将 product-variant模式中的variant分离出来  
  69.         local variant=$(echo -n $selection | sed -e "s/^[^\-]*-//")  
  70.   
  71.         # 检查之,看看是否在 (user userdebug eng) 范围内  
  72.         check_variant $variant  
  73.         if [ $? -ne 0 ]  
  74.         then  
  75.             echo  
  76.             echo "** Invalid variant: '$variant'"  
  77.             echo "** Must be one of ${VARIANT_CHOICES[@]}"  
  78.             variant=  
  79.         fi  
  80.   
  81.         if [ -z "$product" -o -z "$variant" ]  
  82.         then  
  83.             echo  
  84.             return 1  
  85.         fi  
  86.  #  导出环境变量,这里很重要,因为后面的编译系统都是依赖于这里定义的几个变量的  
  87.         export TARGET_PRODUCT=$product  
  88.         export TARGET_BUILD_VARIANT=$variant  
  89.         export TARGET_SIMULATOR=false  
  90.         export TARGET_BUILD_TYPE=release  
  91.     fi # !simulator  
  92.   
  93.     echo  
  94.   
  95.     # 设置到环境变量,比较多,不再一一列出,最简单的方法 set >env.txt 可获得  
  96.     set_stuff_for_environment  
  97.     # 打印一些主要的变量, 调用关系 printconfig()->get_build_var()->build/core/config.mk->build/core/envsetup.mk 比较罗嗦,不展开了  
  98.     printconfig  
  99. }  



 

 

由上面分析可知,lunch命令可以带参数和不带参数,最终导出一些重要的环境变量,从而影响编译系统的编译结果。导出的变量如下(以实际运行情况为例)

 

TARGET_PRODUCT=fs100
TARGET_BUILD_VARIANT=eng
TARGET_SIMULATOR= false
TARGET_BUILD_TYPE=release

 
执行完上述两个步骤,就该执行:make命令了,下篇来分析。


 

 

1. make 

执行make命令的结果就是去执行当前目录下的Makefile文件,我们来看下它的内容:

### DO NOT EDIT THIS FILE ###
include build/core/main.mk
### DO NOT EDIT THIS FILE ###


呵呵,看到上面 的内容,我们都会笑,这是我见过最简单的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包含。

定义了以下环境变量:

16 SRC_HEADERS := \
  17     $(TOPDIR) system /core/include \
  18     $(TOPDIR)hardware/libhardware/include \
  19     $(TOPDIR)hardware/libhardware_legacy/include \
  20     $(TOPDIR)hardware/ril/include \
  21     $(TOPDIR)dalvik/libnativehelper/include \
  22     $(TOPDIR)frameworks/base/include \
  23     $(TOPDIR)frameworks/base/opengl/include \
  24     $(TOPDIR)external/skia/include
  25 SRC_HOST_HEADERS:=$(TOPDIR)tools/include
  26 SRC_LIBRARIES:= $(TOPDIR)libs
  27 SRC_SERVERS:= $(TOPDIR)servers
  28 SRC_TARGET_DIR := $(TOPDIR)build/target
  29 SRC_API_DIR := $(TOPDIR)frameworks/base/api
.....然后定义了下面几个重要的编译命令 43 CLEAR_VARS:= $(BUILD_SYSTEM)/clear_vars.mk
  44 BUILD_HOST_STATIC_LIBRARY:= $(BUILD_SYSTEM)/host_static_library.mk
  45 BUILD_HOST_SHARED_LIBRARY:= $(BUILD_SYSTEM)/host_shared_library.mk
  46 BUILD_STATIC_LIBRARY:= $(BUILD_SYSTEM)/static_library.mk
  47 BUILD_RAW_STATIC_LIBRARY := $(BUILD_SYSTEM)/raw_static_library.mk
  48 BUILD_SHARED_LIBRARY:= $(BUILD_SYSTEM)/shared_library.mk
  49 BUILD_EXECUTABLE:= $(BUILD_SYSTEM)/executable.mk
  50 BUILD_RAW_EXECUTABLE:= $(BUILD_SYSTEM)/raw_executable.mk
  51 BUILD_HOST_EXECUTABLE:= $(BUILD_SYSTEM)/host_executable.mk
  52 BUILD_PACKAGE:= $(BUILD_SYSTEM)/package.mk
  53 BUILD_HOST_PREBUILT:= $(BUILD_SYSTEM)/host_prebuilt.mk
  54 BUILD_PREBUILT:= $(BUILD_SYSTEM)/prebuilt.mk
  55 BUILD_MULTI_PREBUILT:= $(BUILD_SYSTEM)/multi_prebuilt.mk
  56 BUILD_JAVA_LIBRARY:= $(BUILD_SYSTEM)/java_library.mk
  57 BUILD_STATIC_JAVA_LIBRARY:= $(BUILD_SYSTEM)/static_java_library.mk
  58 BUILD_HOST_JAVA_LIBRARY:= $(BUILD_SYSTEM)/host_java_library.mk
  59 BUILD_DROIDDOC:= $(BUILD_SYSTEM)/droiddoc.mk
  60 BUILD_COPY_HEADERS := $(BUILD_SYSTEM)/copy_headers.mk
  61 BUILD_KEY_CHAR_MAP := $(BUILD_SYSTEM)/key_char_map.mk

 

[plain]  view plain  copy
 
  1. 上述命令变量其实是对应的mk文件名,所有的Android.mk文件里基本上都包含上述命令变量,如:  

CLEAR_VARS:用来清除之前定义的环境变量

BUILD_SHARED_LIBRARY:用来指定编译动态库过程

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 :=

 

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.mk

 

复制代码
复制代码
157 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.mk

 

复制代码
复制代码
17 #
 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
 
  1. 通过注释可知,本文件中主要是一些用来处理AndroidProduct.mk的函数_find-android-products-files:  

    用来获得vendor目录下,所有名字为AndroidProduct.mk的文件列表。
get-all-product-makefiles:

    用来获得所有AndroidProduct.mk文件里定义的PRODUCT_MAKEFILES的值(其实是产品文件路径名)。


在vendor目录下,每个公司目录下都会存在一个AndroidProduct.mk文件,这个文件是用来定义这个公司的产品列表,每个产品用.mk来表示
如Android给的示例:

[plain]  view plain  copy
 
  1. 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
 
  1. 里面只定义了一个产品配置文件,即当前目录下的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
 
  1. 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
 
  1. 上述代码在上一节已经见到过,只是分析了112行的envsetup.mk,根据上一节内容可知,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.mk

 

复制代码
复制代码
141 # 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
 
  1. 由于将所有目录中Android.mk文件include进来,build/target/board/Android.mk自然被包含进来,根据前面分析,TARGET_DEVICE_DIR = vendor/*/fs100,其中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
 
  1. 至此,自定义Android编译选项基本步骤已经分部分析完,细节还需要针对不同开发板具体分析。  

 

总结:

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
 
  1. 2. 仿着Android示例代码,在公司目录下创建products目录  
 $mkdir -p vendor/farsight/products
[plain]  view plain  copy
 
  1. 3. 仿着Android示例代码,在products目录下创建两个mk文件  
$touch vendor/farsight/products/AndroidProduct.mk vendor/farsight/products/fs100.mk
[plain]  view plain  copy
 
  1.     在AndroidProduct.mk里添加如下内容:  
PRODUCT_MAKEFILES := $(LOCAL_DIR)/fs100.mk  
[plain]  view plain  copy
 
  1.     在产品配置文件里添加最基本信息  
复制代码
复制代码
 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
 
  1. 借鉴build/target/board/generic/AndroidBoard.mk和BoardConfig.mk,创建对应文件。  
$cp build/target/board/generic/AndroidBoard.mk build/target/board/generic/BoardConfig.mk  vendor/farsight/fs100/

 


 

 

 

 

 

 

 

 

你可能感兴趣的:(ANDROID系统编译过程详解)