android编译系统

来源:互联网 发布:iphone47.12优化 编辑:程序博客网 时间:2024/05/02 20:53

Android Makefile 文件讲解

android编译系统的makefile文件Android.mk写法如下

(1)   Android.mk文件首先需要指定LOCAL_PATH变量,用于查找源文件。由于一般情况下
Android.mk和需要编译的源文件在同一目录下,宏函数“my-dir”由编译系统提供的,用于返回当前路径。所以定义成如下形式:
LOCAL_PATH:=$(call my-dir)
上面的语句的意思是将LOCAL_PATH变量定义成本文件所在目录路径。


(2)   Android.mk中可以定义多个编译模块,每个编译模块都是以include $(CLEAR_VARS)开始
以include $(BUILD_XXX)结束。
include $(CLEAR_VARS)
CLEAR_VARS由编译系统提供,指定让GNUMAKEFILE为你清除除LOCAL_PATH以外的所有LOCAL_XXX变量,
如LOCAL_MODULE,LOCAL_SRC_FILES,LOCAL_SHARED_LIBRARIES,LOCAL_STATIC_LIBRARIES等。
include $(BUILD_STATIC_LIBRARY)表示编译成静态库
include $(BUILD_SHARED_LIBRARY)表示编译成动态库
include $(BUILD_EXECUTABLE)表示编译成可执行程序

include $(BUILD_PREBUILT)

对于Android系统集成有源码的第三方库和程序,只需要提供Android.mk文件,把源码集成到 Android编译系统中就可以了,并且有很多例子可以参考。但是对于没有源码的pre-build第三方库和程序,采用include $(BUILD_PREBUILT)或者include $(BUILD_MULTI_PREBUILT),参考文章: 

http://blog.csdn.net/zhangchiytu/article/details/6424910


include $(BUILD_JAVA_LIBRARY)表示生成JAR包

include $(BUILD_PACKAGE)表示编译成APK

include $(BUILD_STATIC_LIBRARY)表示编译成静态库,include $(BUILD_SHARED_LIBRARY)表示编译成动态库,include $(BUILD_EXECUTABLE)表示编译成可执行程序”之前必须要定义LOCAL_MODULE变量,这样编译系统才会知道要生成的静态库、动态库、可执行程序的名称,编译系统会根据类型自动加载后缀。


(3)   LOCAL_MODULE_TAGS:= optional

      LOCAL_MODULE_TAGS :=user eng tests optional

      user: 指该模块只在user版本下才编译

      eng: 指该模块只在eng版本下才编译

      tests: 指该模块只在tests版本下才编译

      optional:指该模块在所有版本下都编译


(4)   LOCAL_SRC_FILES: 编译的源代码文件列表 

      添加src目录下所有的java 源文件:LOCAL_SRC_FILES:= $(call all-java-files-under, src)


(5)   LOCAL_SDK_VERSION := current


(6)   LOCAL_MODULE:= 模块名称,见(2)中描述。


(7)   LOCAL_PACKAGE_NAME :=APK 包的名称


(8)   LOCAL_JAVA_LIBRARIES :=platform core ext 依赖的共享jar


(9)   LOCAL_STATIC_JAVA_LIBRARIES := 依赖的静态jar包 (jar包是使用 include $(BUILD_STATIC_JAVA_LIBRARY)生成的。)


(10) LOCAL_CERTIFICATE: 签名认证   1.系统中所有使用android.uid.system作为共享UID的APK,都会首先在manifest节点中增加android:sharedUserId="android.uid.system",然后在Android.mk中增加LOCAL_CERTIFICATE:= platform。  2. 系统中所有使用android.uid.shared作为共享UID的APK,都会在manifest节点中增加android:sharedUserId="android.uid.shared",然后在Android.mk中增加LOCAL_CERTIFICATE:= shared。  3.系统中所有使用android.media作为共享UID的APK,都会在manifest节点中增加android:sharedUserId="android.media",然后在Android.mk中增加LOCAL_CERTIFICATE:= media


(11)  编译一个应用程序(APK)
  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
   
  # Tell it to build an APK
  include $(BUILD_PACKAGE)


(12)  编译静态库

#清除java环境变量

include$(CLEAR_VARS)

LOCAL_MODULE_TAGS:= user

#添加aidl文件

LOCAL_SRC_FILES+= src/net/sunniwell/download/aidl/IDownload.aidl

# SDK 版本                

LOCAL_SDK_VERSION:= current

#jar包的名字

LOCAL_MODULE:=DownLoadServerapi               

#编译 DownLoadServerapi  jar 包

include $(BUILD_STATIC_JAVA_LIBRARY)


(13) 编译一个依赖于静态Java库(static.jar)的应用程序
  LOCAL_PATH := $(call my-dir)
  include $(CLEAR_VARS)
   
  # List of static libraries to include in the package
  LOCAL_STATIC_JAVA_LIBRARIES := DownLoadServerapi  第三方jar包
   
  # 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
   
  # Tell it to build an APK
  include $(BUILD_PACKAGE)


(14) 编译一个需要用平台的key签名的应用程序
  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)


(15) 添加一个静态JAVA库
  LOCAL_PATH := $(call my-dir)
  include $(CLEAR_VARS)
   
  # Build all java files in the java subdirectory
  LOCAL_SRC_FILES := $(call all-subdir-java-files)
   
  # Any libraries that this library depends on
  LOCAL_JAVA_LIBRARIES := android.test.runner
   
  # The name of the jar file to create
  LOCAL_MODULE := sample
   
  # Build a static jar file.
  include $(BUILD_STATIC_JAVA_LIBRARY)


(16) 引用第三方JAR 包方式

#引入第三方包

include $(CLEAR_VARS) 

 

# 表示在当前目录下的lib/iptv.jar进行预处理到android jar包的目录中去

 

#LOCAL_PREBUILT_JAVA_LIBRARIES := libiptv:lib/iptv.jar

LOCAL_PREBUILT_STATIC_JAVA_LIBRARIES := \

libiptv:lib/iptv.jar 

 

include $(BUILD_MULTI_PREBUILT)

 

需要在编译apk 中进行、并添加

LOCAL_STATIC_JAVA_LIBRARIES := libiptv

(17) LOCAL_AIDL_INCLUDES  := <path to aidl files>

        aidl文件所在的目录,关于aidl是Android Interface definition language的缩写,它是一种android内部进程通信接口的描述语言,通过它我们可以定义进程间的通信接口


(18)include $(call all-makefiles-under,$(LOCAL_PATH))

在Android的源代码中的mk文件中,我们经常会看到上面这句话,从字面意思看是,include目录下所有的mk文件,那么这里面有两个坑,

1.只是include Android.mk文件,叫其他名字的mk文件,不include.
2.只是include这个$(LOCAL_PATH)一级目录下的Android.mk文件,而不是所有子目录以及子目录下的Android.mk文件(这个坑掉进去2小时才出来 )。

最后,看一下这个函数的源代码加强一下印象吧:

define all-makefiles-under
$(wildcard $(1)/*/Android.mk)
endef


(19)  LOCAL_PRELINK_MODULE 

Prelink利用事先链接代替运行时链接的方法来加速共享库的加载,它不仅可以加快起动速度,还可以减少部分内存开销,是各种Linux架构上用于减少程序加载时间、缩短系统启动时间和加快应用程序启动的很受欢迎的一个工具。程序运行时的动态链接尤其是重定位(relocation)的开销对于大型系统来说是很大的。 

        动态链接和加载的过程开销很大,并且在大多数的系统上, 函数库并不会常常被更动, 每次程序被执行时所进行的链接动作都是完全相同的,对于嵌入式系统来说尤其如此。因此,这一过程可以改在运行时之前就可以预先处理好,即花一些时间利用Prelink工具对动态共享库和可执行文件进行处理,修改这些二进制文件并加入相应的重定位等信息,节约了本来在程序启动时的比较耗时的查询函数地址等工作,这样可以减少程序启动的时间,同时也减少了内存的耗用。 

(20) 



Android编译系统详解(一)

http://blog.csdn.net/mr_raptor/article/details/7539978

Android的优势就在于其开源,手机和平板生产商可以根据自己的硬件进行个性定制自己的手机产品,如小米,LePhone,M9等,因此,在我们在对Android的源码进行定制的时候,很有必要了解下,Android的编译过程。


如果你从来没有做过Android代码的编译,那么最官方的编译过程就是查看Android的官方网站:http://source.android.com/source/building.html

但是,这儿只是告诉你了如何去编译一个通用的系统,并没有详细告诉你细节,我们跟着编译过程来了解下。

+-------------------------------------------------------------------------------------------------+

 本文使用Android版本为2.1,采用开发板为华清远见研发的FS_S5PC100 A8开发板。

+-------------------------------------------------------------------------------------------------+

按照google给出的编译步骤如下:

   1> source build/envsetup.sh:加载命令

   2> lunch:选择平台编译选项

   3> make:执行编译

我们按照编译步骤来分析编译过程的细节,最终添加自己的平台编译选项。

1. source build/envsetup.sh

这个命令是用来将envsetup.sh里的所有用到的命令加载到环境变量里去,我们来分析下它。

envsetup.sh里的主要命令如下:


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 ()  #跳到指定目录

 #add_lunch_combo函数被多次调用,就是它来添加Android编译选项


 # Clear this variable.  It will be built up again when thevendorsetup.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 vendorbuild/vendorsetup.sh 2> /dev/null` #android4.0中也会检查/device/目录下是否有vendorsetup.sh
 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,在里面添加上自己的产品编译项。

 
#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那么,在命令行中执行lunch:

#lunch

那么会显示如下信息:


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

 

其中第3项是我们自己添加的编译项。

因此如果想配置fs100-eng,则执行“lunch fs100-eng”或者“lunch 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命令干了什么?

 

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是选择菜单的数字,则获取该数字对应的字符串  #这个解释了“lunch 3”
        if [ $answer -le ${#LUNCH_MENU_CHOICES[@]} ]
        then
            selection=${LUNCH_MENU_CHOICES[$(($answer-$_arrayoffset))]}
        fi
        #如果 answer字符串匹配 *-*模式(*的开头不能为-),例如“fs100-eng
    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命令可以带参数和不带参数,最终导出一些重要的环境变量,从而影响编译系统的编译结果。导出的变量如下(以实际运行情况为例)

 

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

 

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

Android编译系统详解(二)

http://blog.csdn.net/mr_raptor/article/details/7540066

通过上篇文章,我们分析了编译android时source build/envsetup.sh和lunch命令,在执行完上述两个命令后, 我们就可以进行编译android了。

1. make 

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

[html] view plaincopy
  1. 1 ### DO NOT EDIT THIS FILE ###  
  2. 2 include build/core/main.mk  
  3. 3 ### 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文件都有自己独特的意义,我一并将主线流程通过下面这个图各表现出来,先有个整体的概念,然后再细化了解。

所有的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 plaincopy
  1. 16 SRC_HEADERS := \  
  2. 17     $(TOPDIR)system/core/include \  
  3. 18     $(TOPDIR)hardware/libhardware/include \  
  4. 19     $(TOPDIR)hardware/libhardware_legacy/include \  
  5. 20     $(TOPDIR)hardware/ril/include \  
  6. 21     $(TOPDIR)dalvik/libnativehelper/include \  
  7. 22     $(TOPDIR)frameworks/base/include \  
  8. 23     $(TOPDIR)frameworks/base/opengl/include \  
  9. 24     $(TOPDIR)external/skia/include  
  10. 25 SRC_HOST_HEADERS:=$(TOPDIR)tools/include  
  11. 26 SRC_LIBRARIES:= $(TOPDIR)libs  
  12. 27 SRC_SERVERS:= $(TOPDIR)servers  
  13. 28 SRC_TARGET_DIR := $(TOPDIR)build/target  
  14. 29 SRC_API_DIR := $(TOPDIR)frameworks/base/api  
[plain] view plaincopy
  1. .....然后定义了下面的重要的编译命令  
[plain] view plaincopy
  1.  43 CLEAR_VARS:= $(BUILD_SYSTEM)/clear_vars.mk  
  2.  44 BUILD_HOST_STATIC_LIBRARY:= $(BUILD_SYSTEM)/host_static_library.mk  
  3.  45 BUILD_HOST_SHARED_LIBRARY:= $(BUILD_SYSTEM)/host_shared_library.mk  
  4.  46 BUILD_STATIC_LIBRARY:= $(BUILD_SYSTEM)/static_library.mk  
  5.  47 BUILD_RAW_STATIC_LIBRARY := $(BUILD_SYSTEM)/raw_static_library.mk  
  6.  48 BUILD_SHARED_LIBRARY:= $(BUILD_SYSTEM)/shared_library.mk  
  7.  49 BUILD_EXECUTABLE:= $(BUILD_SYSTEM)/executable.mk  
  8.  50 BUILD_RAW_EXECUTABLE:= $(BUILD_SYSTEM)/raw_executable.mk  
  9.  51 BUILD_HOST_EXECUTABLE:= $(BUILD_SYSTEM)/host_executable.mk  
  10.  52 BUILD_PACKAGE:= $(BUILD_SYSTEM)/package.mk  
  11.  53 BUILD_HOST_PREBUILT:= $(BUILD_SYSTEM)/host_prebuilt.mk  
  12.  54 BUILD_PREBUILT:= $(BUILD_SYSTEM)/prebuilt.mk  
  13.  55 BUILD_MULTI_PREBUILT:= $(BUILD_SYSTEM)/multi_prebuilt.mk  
  14.  56 BUILD_JAVA_LIBRARY:= $(BUILD_SYSTEM)/java_library.mk  
  15.  57 BUILD_STATIC_JAVA_LIBRARY:= $(BUILD_SYSTEM)/static_java_library.mk  
  16.  58 BUILD_HOST_JAVA_LIBRARY:= $(BUILD_SYSTEM)/host_java_library.mk  
  17.  59 BUILD_DROIDDOC:= $(BUILD_SYSTEM)/droiddoc.mk  
  18.  60 BUILD_COPY_HEADERS := $(BUILD_SYSTEM)/copy_headers.mk  
  19.  61 BUILD_KEY_CHAR_MAP := $(BUILD_SYSTEM)/key_char_map.mk  

上述命令变量其实是对应的mk文件名,几乎所有的Android.mk文件里基本上都包含上述命令变量,如:

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

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

[plain] view plaincopy
  1. 109 # ---------------------------------------------------------------  
  2. 110 # Define most of the global variables.  These are the ones that  
  3. 111 # are specific to the user's build configuration.  
  4. ### evnsetup.mk文件里定义了大部分的全局变量,用户使用这些变量来编译系统  
  5. 112 include $(BUILD_SYSTEM)/envsetup.mk  
  6. 113   
  7. 114 # Boards may be defined under $(SRC_TARGET_DIR)/board/$(TARGET_DEVICE)  
  8. 115 # or under vendor/*/$(TARGET_DEVICE).  Search in both places, but  
  9. 116 # make sure only one exists.  
  10. 117 # Real boards should always be associated with an OEM vendor.  
  11. ### 板级配置信息通常定义在$(SRC_TARGET_DIR)/board/$(TARGET_DEVICE)或vendor/*/$(TARGET_DEVICE)下面,从这两个地方搜索,但是只能有一个地方存在板级配置信息(TARGET_DEVICE变量在上面的envsetup.mk里定义)  
  12.   
  13.   
  14. ### wildcard命令用于在某个目录下查找匹配的文件,将找到的文件列表返回  
  15. 118 board_config_mk := \  
  16. 119     $(strip $(wildcard \  
  17. 120         $(SRC_TARGET_DIR)/board/$(TARGET_DEVICE)/BoardConfig.mk \  
  18. 121         vendor/*/$(TARGET_DEVICE)/BoardConfig.mk \  
  19. 122     ))  
  20. ### 如果没有找到,提示出错  
  21. 123 ifeq ($(board_config_mk),)  
  22. 124   $(error No config file found for TARGET_DEVICE $(TARGET_DEVICE))  
  23. 125 endif  
  24. ### 如果找到了1个以上时,提示出错  
  25. 126 ifneq ($(words $(board_config_mk)),1)  
  26. 127   $(error Multiple board config files for TARGET_DEVICE $(TARGET_DEVICE): $(board_config_mk))  
  27. 128 endif  
  28. 129 include $(board_config_mk)  # 将板级配置信息包含进来  
  29. 130 TARGET_DEVICE_DIR := $(patsubst %/,%,$(dir $(board_config_mk)))  
  30. 131 board_config_mk :=  
112行又包含了另外一个重要的mk文件envsetup.mk,我们来看一下。


3. envsetup.mk

[plain] view plaincopy
  1. 25 ifeq ($(TARGET_PRODUCT),)       # 如果TARGET_PRODUCT为空  
  2. 26 ifeq ($(TARGET_SIMULATOR),true) # 编译为模拟器  
  3. 27 TARGET_PRODUCT := sim  
  4. 28 else  
  5. 29 TARGET_PRODUCT := generic       # 默认产品名字为generic  
  6. 30 endif  
  7. 31 endif  
第25行,判断TARGET_PRODUCT是否为空,根据上一节分析可知,TARGET_PRODUCT=fs100 
[plain] view plaincopy
  1. 34 # the variant -- the set of files that are included for a build  
  2. 35 ifeq ($(strip $(TARGET_BUILD_VARIANT)),)  # 如果编译版本型号变量为空  
  3. 36 TARGET_BUILD_VARIANT := eng  
  4. 37 endif  
  5. 38   
  6. 39 # Read the product specs so we an get TARGET_DEVICE and other  
  7. 40 # variables that we need in order to locate the output files.  
  8. ## product_config.mk文件,读取产品配置信息,从而得到目标设备,将其导出到TARGET_DEVICE变量里,后面的定义的OUT变量的值,也依赖于目标设备TARGET_DEVICE,用于指定目标代码的输出目录  
  9. 41 include $(BUILD_SYSTEM)/product_config.mk  
在41行又包含了product_config.mk文件,等会我们再分析它,先看下面的

[plain] view plaincopy
  1. 148 # ---------------------------------------------------------------  
  2. 149 # figure out the output directories  
  3. 150   
  4. 151 ifeq (,$(strip $(OUT_DIR)))  
  5. 152 OUT_DIR := $(TOPDIR)out  
  6. 153 endif  
  7. 154   
  8. 155 DEBUG_OUT_DIR := $(OUT_DIR)/debug  
  9. 156   
  10. 157 # Move the host or target under the debug/ directory  
  11. 158 # if necessary.  
  12. 159 TARGET_OUT_ROOT_release := $(OUT_DIR)/target  
  13. 160 TARGET_OUT_ROOT_debug := $(DEBUG_OUT_DIR)/target  
  14. 161 TARGET_OUT_ROOT := $(TARGET_OUT_ROOT_$(TARGET_BUILD_TYPE))  
  15. 162   
  16. ...  
  17. ### 这个重要的OUT变量,依赖于目标设备名TARGET_DEVICE  
  18. 184 PRODUCT_OUT := $(TARGET_PRODUCT_OUT_ROOT)/$(TARGET_DEVICE)    
  19. 187   
  20. 188 HOST_OUT_EXECUTABLES:= $(HOST_OUT)/bin  
  21. 189 HOST_OUT_SHARED_LIBRARIES:= $(HOST_OUT)/lib  
  22. 190 HOST_OUT_JAVA_LIBRARIES:= $(HOST_OUT)/framework  
  23. 191 HOST_OUT_SDK_ADDON := $(HOST_OUT)/sdk_addon  
  24. ...  
  25. 200 TARGET_OUT_INTERMEDIATES := $(PRODUCT_OUT)/obj  
  26. 201 TARGET_OUT_HEADERS:= $(TARGET_OUT_INTERMEDIATES)/include  
  27. 202 TARGET_OUT_INTERMEDIATE_LIBRARIES := $(TARGET_OUT_INTERMEDIATES)/lib  
  28. 203 TARGET_OUT_COMMON_INTERMEDIATES := $(TARGET_COMMON_OUT_ROOT)/obj  
  29. 204  
  30. ### 后面的OUT变量都要间接依赖于TARGET_DEVICE  
  31. 205 TARGET_OUT := PRODUCT_OUT)/system  
  32. 206 TARGET_OUT_EXECUTABLES:= $(TARGET_OUT)/bin  
  33. 207 TARGET_OUT_OPTIONAL_EXECUTABLES:= $(TARGET_OUT)/xbin  
  34. 208 TARGET_OUT_SHARED_LIBRARIES:= $(TARGET_OUT)/lib  
  35. 209 TARGET_OUT_JAVA_LIBRARIES:= $(TARGET_OUT)/framework  
  36. 210 TARGET_OUT_APPS:= $(TARGET_OUT)/app  
  37. 211 TARGET_OUT_KEYLAYOUT := $(TARGET_OUT)/usr/keylayout  
  38. 212 TARGET_OUT_KEYCHARS := $(TARGET_OUT)/usr/keychars  
  39. 213 TARGET_OUT_ETC := $(TARGET_OUT)/etc  
  40. 214 TARGET_OUT_STATIC_LIBRARIES:= $(TARGET_OUT_INTERMEDIATES)/lib  
  41. 215 TARGET_OUT_NOTICE_FILES:=$(TARGET_OUT_INTERMEDIATES)/NOTICE_FILES  
  42. 216   
  43. 217 TARGET_OUT_DATA := $(<strong>PRODUCT_OUT</strong>)/data  
  44. 218 TARGET_OUT_DATA_EXECUTABLES:= $(TARGET_OUT_EXECUTABLES)  
  45. 219 TARGET_OUT_DATA_SHARED_LIBRARIES:= $(TARGET_OUT_SHARED_LIBRARIES)  
  46. 220 TARGET_OUT_DATA_JAVA_LIBRARIES:= $(TARGET_OUT_JAVA_LIBRARIES)  
  47. 221 TARGET_OUT_DATA_APPS:= $(TARGET_OUT_DATA)/app  
  48. 222 TARGET_OUT_DATA_KEYLAYOUT := $(TARGET_OUT_KEYLAYOUT)  
  49. 223 TARGET_OUT_DATA_KEYCHARS := $(TARGET_OUT_KEYCHARS)  
  50. 224 TARGET_OUT_DATA_ETC := $(TARGET_OUT_ETC)  
  51. 225 TARGET_OUT_DATA_STATIC_LIBRARIES:= $(TARGET_OUT_STATIC_LIBRARIES)  
  52. 226   
  53. 227 TARGET_OUT_UNSTRIPPED := $(<strong>PRODUCT_OUT</strong>)/symbols  
  54. 228 TARGET_OUT_EXECUTABLES_UNSTRIPPED := $(TARGET_OUT_UNSTRIPPED)/system/bin  
  55. 229 TARGET_OUT_SHARED_LIBRARIES_UNSTRIPPED := $(TARGET_OUT_UNSTRIPPED)/system/lib  
  56. 230 TARGET_ROOT_OUT_UNSTRIPPED := $(TARGET_OUT_UNSTRIPPED)  
  57. 231 TARGET_ROOT_OUT_SBIN_UNSTRIPPED := $(TARGET_OUT_UNSTRIPPED)/sbin  
  58. 232 TARGET_ROOT_OUT_BIN_UNSTRIPPED := $(TARGET_OUT_UNSTRIPPED)/bin  
  59. 233   
  60. 234 TARGET_ROOT_OUT := $(<strong>PRODUCT_OUT</strong>)/root  
  61. 235 TARGET_ROOT_OUT_BIN := $(TARGET_ROOT_OUT)/bin  
  62. 236 TARGET_ROOT_OUT_SBIN := $(TARGET_ROOT_OUT)/sbin  
  63. 237 TARGET_ROOT_OUT_ETC := $(TARGET_ROOT_OUT)/etc  
  64. 238 TARGET_ROOT_OUT_USR := $(TARGET_ROOT_OUT)/usr  
  65. 239   
  66. 240 TARGET_RECOVERY_OUT := $(<strong>PRODUCT_OUT</strong>)/recovery  
  67. 241 TARGET_RECOVERY_ROOT_OUT := $(TARGET_RECOVERY_OUT)/root  
  68. 242   
  69. 243 TARGET_SYSLOADER_OUT := $(<strong>PRODUCT_OUT</strong>)/sysloader  
  70. 244 TARGET_SYSLOADER_ROOT_OUT := $(TARGET_SYSLOADER_OUT)/root  
  71. 245 TARGET_SYSLOADER_SYSTEM_OUT := $(TARGET_SYSLOADER_OUT)/root/system  
  72. 246   
  73. 247 TARGET_INSTALLER_OUT := $(<strong>PRODUCT_OUT</strong>)/installer  
  74. 248 TARGET_INSTALLER_DATA_OUT := $(TARGET_INSTALLER_OUT)/data  
  75. 249 TARGET_INSTALLER_ROOT_OUT := $(TARGET_INSTALLER_OUT)/root  
  76. 250 TARGET_INSTALLER_SYSTEM_OUT := $(TARGET_INSTALLER_OUT)/root/system  
上面的代码是指定了目标输出代码的位置和主机输出代码的位置,重要的几个如下:

[plain] view plaincopy
  1. TARGET_OUT = $(<strong>PRODUCT_OUT</strong>)/system  
  2. TARGET_OUT_EXECUTABLES =  $(PRODUCT_OUT)/system/bin  
  3. TARGET_OUT_SHARED_LIBRARIES =  $(PRODUCT_OUT)/system/lib  
  4. TARGET_OUT_JAVA_LIBRARIES = $(PRODUCT_OUT)/system/framework  
  5. TARGET_OUT_APPS = $(PRODUCT_OUT)/system/app  
  6. TARGET_OUT_ETC = $(PRODUCT_OUT)/system/etc  
  7. TARGET_OUT_STATIC_LIBRARIES  = $(PRODUCT_OUT)/obj/lib  
  8. TARGET_OUT_DATA = $(PRODUCT_OUT)/data  
  9. TARGET_OUT_DATA_APPS = $(PRODUCT_OUT)/data/app  
  10. TARGET_ROOT_OUT = $(PRODUCT_OUT)/root  
  11. TARGET_ROOT_OUT_BIN = $(PRODUCT_OUT)/bin  
  12. TARGET_ROOT_OUT_SBIN  = $(PRODUCT_OUT)/system/sbin  
  13. TARGET_ROOT_OUT_ETC = $(PRODUCT_OUT)/system/etc  
  14. TARGET_ROOT_OUT_USR = $(PRODUCT_OUT)/system/usr  

总结下:

envsetup.mk文件主要包含了product_config.mk文件,然后指定了编译时要输出的所有文件的OUT目录,这些OUT目录变量依赖于TARGET_DEVICE变量。


4. build/core/product_config.mk

[plain] view plaincopy
  1. 157 include $(BUILD_SYSTEM)/product.mk  
  2. ...  
  3. 160 # Read in all of the product definitions specified by the AndroidProducts.mk  
  4. 161 # files in the tree.  
  5. 162 #  
  6. 163 #TODO: when we start allowing direct pointers to product files,  
  7. 164 #    guarantee that they're in this list.  
  8. 165 $(call import-products, $(get-all-product-makefiles))  
  9. 166 $(check-all-products)  
  10. ...  
  11. 170 # Convert a short name like "sooner" into the path to the product  
  12. 171 # file defining that product.  
  13. 172 #  
  14. 173 INTERNAL_PRODUCT := $(call resolve-short-product-name, $(TARGET_PRODUCT))  
  15. ...  
  16. 176 # Find the device that this product maps to.  
  17. 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.

    意思是说:读取厂商目录下(vendor/*/products/AndroidProducts.mk)所有的AndrodProducts.mk文件中定义的产品信息

    其实get-all-product-makefiles返回厂商全部产品文件xxx.mk

    import-products函数去验证这些产品配置文件是否都包含有必须的配置信息,细节后面分析。

173行调用了resolve-short-product-name函数,它将根据产品TARGET_PRODUCT,返回该产品配置文件的完整路径,并赋给INTERNAL_PRODUCT

    例如TARGET_PRODUCT=fs100,则:

    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文件(vendor/*/products/AndroidProducts.mk),从该文件里取得所有产品的配置文件,然后再根据lunch选择的编译项TARGET_PRODUCT,找到与之对应的配置文件,然后读取产品配置文件,找到里面的PRODUCT_DEVICE的值,设置给TARGET_DEVICE变量,用于后续编译。


5. build/core/product.mk

[plain] view plaincopy
  1. 17 #  
  2. 18 # Functions for including AndroidProducts.mk files  
  3. 19 #  
  4. 20   
  5. 21 #  
  6. 22 # Returns the list of all AndroidProducts.mk files.  
  7. 23 # $(call ) isn't necessary.  
  8. 24 #  
  9. 25 define <strong>_find-android-products-files</strong>  
  10. 26 $(shell test -d vendor && find vendor -maxdepth 6 -name AndroidProducts.mk) \  
  11. 27   $(SRC_TARGET_DIR)/product/AndroidProducts.mk  
  12. 28 endef  
  13. 29   
  14. 30 #  
  15. 31 # Returns the sorted concatenation of all PRODUCT_MAKEFILES  
  16. 32 # variables set in all AndroidProducts.mk files.  
  17. 33 # $(call ) isn't necessary.  
  18. 34 #  
  19. 35 define <strong>get-all-product-makefiles</strong>  
  20. 36 $(sort \  
  21. 37   $(foreach f,$(_find-android-products-files), \  
  22. 38     $(eval PRODUCT_MAKEFILES :=) \  
  23. 39     $(eval LOCAL_DIR := $(patsubst %/,%,$(dir $(f)))) \  
  24. 40     $(eval include $(f)) \  
  25. 41     $(PRODUCT_MAKEFILES) \  
  26. 42    ) \  
  27. 43   $(eval PRODUCT_MAKEFILES :=) \  
  28. 44   $(eval LOCAL_DIR :=) \  
  29. 45  )  
  30. 46 endef  
通过注释可知,本文件中主要是一些用来处理AndroidProduct.mk的函数
_find-android-products-files:

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

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


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

[plain] view plaincopy
  1. vendor/sample/products/AndroidProduct.mk  
其内容如下:

[plain] view plaincopy
  1.  1 #  
  2.  2 # This file should set PRODUCT_MAKEFILES to a list of product makefiles  
  3.  3 # to expose to the build system.  LOCAL_DIR will already be set to  
  4.  4 # the directory containing this file.   
  5.  5 #  
  6.  6 # This file may not rely on the value of any variable other than  
  7.  7 # LOCAL_DIR; do not use any conditionals, and do not look up the  
  8.  8 # value of any variable that isn't set in this file or in a file that  
  9.  9 # it includes.  
  10. 10 #  
  11. 11   
  12. 12 PRODUCT_MAKEFILES := \  
  13. 13   $(LOCAL_DIR)/sample_addon.mk  
里面只定义了一个产品配置文件,即当前目录下的sample_addon.mk:
[plain] view plaincopy
  1. 1 # List of apps and optional libraries (Java and native) to put in the add-on system image.  
  2. 2 PRODUCT_PACKAGES := \  
  3. 3     PlatformLibraryClient \  
  4. 4     com.example.android.platform_library \  
  5. 5     libplatform_library_jni  
上述文件里(sample_addon.mk)定义了产品相关个性化信息,如,PRODUCT_PACKAGES表示要在当前产品里添加一些安装包。
由此可见,get-all-product-makefiles函数,其实就是返回了当前公司里全部的产品对应的mk文件列表。


总结:

如果用户想个性定制自己的产品,应该有以下流程,包含上一节内容:

注:#表示shell提示符

1. 创建厂商目录

    #mkdir vendor/farsight

2. 创建一个vendorsetup.sh文件,将当前产品编译项添加到lunch里,让lunch能找到用户产品编译项

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

    注:我们增加一个用户产品编译项,fs100-eng

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是当前厂商产品列表文件,fs100.mk表示当前厂商的一款产品配置文件

在AndroidProduct.mk里添加如下内容:

[plain] view plaincopy
  1. PRODUCT_MAKEFILES := $(LOCAL_DIR)/fs100.mk  
   注:表示只有一个产品fs100,它对应的配置文件在当前目录下的fs100.mk。

5. 在产品配置文件里添加最基本信息

[plain] view plaincopy
  1.  1   
  2.  2 PRODUCT_PACKAGES := \  
  3.  3     IM \  
  4.  4     VoiceDialer  
  5.  5   
  6.  6 $(call inherit-product, build/target/product/generic.mk)  ##从某一默认配置开始派生余下内容参考派生起点  
  7.  7   
  8.  8 # Overrides  
  9.  9 PRODUCT_MANUFACTURER := farsight  
  10. 10 PRODUCT_NAME := fs100  
  11. 11 PRODUCT_DEVICE := fs100  

一定要注意:

  PRODUCT_NAME:表示产品名字,它要和最终出现的编译项产品名一致,也就是说fs100-eng

  PRODUCT_DEVICE:表示设备名字,它要和将来创建的设备目录名字一致。


Android编译系统详解(三)

http://blog.csdn.net/mr_raptor/article/details/7540730

前面两节讲解了自定义Android编译项和创建Product产品配置文件,除了编译和定义产品相关环境变量外,还需要定义Board相关环境变量。

1. build/core/config.mk

[plain] view plaincopy
  1. 109 # ---------------------------------------------------------------   
  2. 110 # Define most of the global variables.  These are the ones that   
  3. 111 # are specific to the user's build configuration.   
  4. 112 include $(BUILD_SYSTEM)/envsetup.mk   
  5. 113    
  6. 114 # Boards may be defined under $(SRC_TARGET_DIR)/board/$(TARGET_DEVICE)   
  7. 115 # or under vendor/*/$(TARGET_DEVICE).  Search in both places, but   
  8. 116 # make sure only one exists.   
  9. 117 # Real boards should always be associated with an OEM vendor.   
  10. 118 board_config_mk := \   
  11. 119     $(strip $(wildcard \   
  12. 120         $(SRC_TARGET_DIR)/board/$(TARGET_DEVICE)/BoardConfig.mk \   
  13. 121         vendor/*/$(TARGET_DEVICE)/BoardConfig.mk \   
  14. 122     ))   
  15. 123 ifeq ($(board_config_mk),)   
  16. 124   $(error No config file found for TARGET_DEVICE $(TARGET_DEVICE))   
  17. 125 endif   
  18. 126 ifneq ($(words $(board_config_mk)),1)   
  19. 127   $(error Multiple board config files for TARGET_DEVICE $(TARGET_DEVICE): $(board_config_mk))   
  20. 128 endif   
  21. 129 include $(board_config_mk)   
  22. 130 TARGET_DEVICE_DIR := $(patsubst %/,%,$(dir $(board_config_mk)))   
  23. 131 board_config_mk :=   

上述代码在上一节已经见到过,只是分析了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/*/fs1 00/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

[plain] view plaincopy
  1. 141 # Bring in standard build system definitions.  
  2. 142 include $(BUILD_SYSTEM)/definitions.mk  
  3. ...  
  4. 347 ifeq ($(SDK_ONLY),true)  
  5. 348  
  6. 349 # ----- SDK for Windows ------  
  7. 350 # These configure the build targets that are available for the SDK under Cygwin.  
  8. 351 # The first section defines all the C/C++ tools that can be compiled under Cygwin,  
  9. 352 # the second section defines all the Java ones (assuming javac is available.)  
  10. 353  
  11. 354 subdirs := \  
  12. 355     prebuilt \  
  13. 356     build/libs/host \  
  14. 357     build/tools/zipalign \  
  15. ...  
  16. 382 # The following can only be built if "javac" is available.  
  17. 383 # This check is used when building parts of the SDK under Cygwin.  
  18. 384 ifneq (,$(shell which javac 2>/dev/null))  
  19. 385 $(warning sdk-only: javac available.)  
  20. 386 subdirs += \  
  21. 387     build/tools/signapk \  
  22. 388     dalvik/dx \  
  23. 389     dalvik/libcore \  
  24. ...  
  25. 414 else    # !SDK_ONLY  
  26. 415 ifeq ($(BUILD_TINY_ANDROID), true)  
  27. 416  
  28. 417 # TINY_ANDROID is a super-minimal build configuration, handy for board  
  29. 418 # bringup and very low level debugging  
  30. 419  
  31. 420 subdirs := \  
  32. 421     bionic \  
  33. 422     system/core \  
  34. 423     build/libs \  
  35. 424     build/target \  
  36. ...  
  37. 433 else    # !BUILD_TINY_ANDROID  
  38. 434  
  39. 435 #  
  40. 436 # Typical build; include any Android.mk files we can find.  
  41. 437 #  
  42. 438 subdirs := $(TOP)  
  43. 439  
  44. 440 FULL_BUILD := true  
  45. 441  
  46. 442 endif   # !BUILD_TINY_ANDROID  
  47. 443  
  48. 444 endif   # !SDK_ONLY  
  49. ...  
  50. 464 #  
  51. 465 # Include all of the makefiles in the system  
  52. 466 #  
  53. 467  
  54. 468 # Can't use first-makefiles-under here because  
  55. 469 # --mindepth=2 makes the prunes not work.  
  56. 470 subdir_makefiles := \  
  57. 471     $(shell build/tools/findleaves.py --prune=out --prune=.repo --prune=.git $(subdirs) Android.mk)  
  58. 472  
  59. 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

[plain] view plaincopy
  1. 26 ifeq (,$(wildcard $(TARGET_DEVICE_DIR)/AndroidBoard.mk))  
  2.  27   ifeq (,$(wildcard $(TARGET_DEVICE_DIR)/Android.mk))  
  3.  28     $(error Missing "$(TARGET_DEVICE_DIR)/AndroidBoard.mk")  
  4.  29   else  
  5.  30     # TODO: Remove this check after people have had a chance to switch,  
  6.  31     # after April 2009.  
  7.  32     $(error Please rename "$(TARGET_DEVICE_DIR)/Android.mk" to "$(TARGET_DEVICE_DIR)/AndroidBoard.mk")  
  8.  33   endif  
  9.  34 endif  
  10.  35 include $(TARGET_DEVICE_DIR)/AndroidBoard.mk  
由于将所有目录中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文件。

[plain] view plaincopy
  1. $ cp build/target/board/generic/AndroidBoard.mk build/target/board/generic/BoardConfig.mk  vendor/farsight/fs100/  

至此,自定义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,在里面添加上自己的产品编译项

[plain] view plaincopy
  1. $ mkdir vendor/farsight/   
  2. $ touch vendor/farsight/vendorsetup.sh   
  3. $ echo "add_lunch_combo fs100-eng" > vendor/farsight/vendorsetup.sh   

2. 仿着Android示例代码,在公司目录下创建products目录

[plain] view plaincopy
  1. $ mkdir -p vendor/farsight/products  

3. 仿着Android示例代码,在products目录下创建两个mk文件

[plain] view plaincopy
  1. $ touch vendor/farsight/products/AndroidProduct.mk vendor/farsight/products/fs100.mk  

    在AndroidProduct.mk里添加如下内容:

[plain] view plaincopy
  1. PRODUCT_MAKEFILES := $(LOCAL_DIR)/fs100.mk   

    在产品配置文件里添加最基本信息

[plain] view plaincopy
  1. $(call inherit-product, build/target/product/generic.mk)   
  2.    
  3. # Overrides   
  4. PRODUCT_MANUFACTURER := farsight   
  5. PRODUCT_NAME := fs100   
  6. PRODUCT_DEVICE := fs100   

4. 借鉴build/target/board/generic/AndroidBoard.mk和BoardConfig.mk,创建对应文件。

[plain] view plaincopy
  1. $ cp build/target/board/generic/AndroidBoard.mk build/target/board/generic/BoardConfig.mk  vendor/farsight/fs100/  








0 0