Android编译系统详解(二)——命令执行流程

http://www.cloudchou.com/android/post-261.html

编译Rom的第一步是source build/envsetup.sh,该步骤将envsetup.sh里的函数声明为当前终端可用的命令，并将所有产品添加至变量LUNCH_MENU_CHOICES里。

编译Rom的第二步是让用户选择他想编译的产品，用户可以使用在source build/envsetup.sh后设置的breakfast或者lunch命令进行选择，接下来我们将详细分析这些命令的执行流程以及执行完breakfast命令或者lunch命令后在会话终端设置的变量

1. 命令执行流程

1.1 breakfast执行流程

流程：

• 1) 从github上下载cm支持的产品，并添加至产品列表
• 2) 如果命令参数为空，那么调用lunch函数，让用户选择产品
• 3) 如果命令参数为1个且$target格式为$product-$build_variant，那么调用lunch $target，这样不需要用户选择产品
• 4) 如果命令参数为1个且$target格式为$product，那么将其扩展为带build_variant格式的产品，然后调用lunch cm_$target-userdebug，这样不需要用户选择产品

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32

target=$1 CM_DEVICES_ONLY="true" #只编译CM支持的设备 unset LUNCH_MENU_CHOICES add_lunch_combo full-eng #vendor/cm/vendorsetup.sh 该脚本会从github上下载cm支持的产品， #并添加至LUNCH_MENU_CHOICES变量 ，该变量表示产品列表 for f in `/bin/ls vendor/cm/vendorsetup.sh 2> /dev/null` do echo "including $f" . $f done unset f   #如果没有带任何参数，那么调用lunch函数，让用户选择产品 if [ $# -eq 0 ]; then lunch else #target格式：$product-$build_variant 或者 $product # 示例 cm_i9100-userdebug 或 i9100 echo "z$target" | grep -q "-" #如果用户输入的产品格式是$product-$build_variant 那么直接调用lunch if [ $? -eq 0 ]; then # A buildtype was specified, assume a full device name lunch $target else #如果用户输入的产品格式是$product， #那么扩展该变量为cm_$target-userdebug格式 # This is probably just the CM model name lunch cm_$target-userdebug fi fi return $?

1.2 lunch执行流程

流程：

• 1) 获取用户指定的产品或者让用户选择产品，并提取$product和$variant
• 2) 检查是否支持产品
• 3) 若不支持该产品，从网上下载该产品的相关配置到本地device目录，并再次检查是否支持该产品
• 4) 若支持该产品，下载产品的最新配置到本地device目录
• 5) 若还是不支持，告诉用户不支持并退出
• 6) 设置环境变量export TARGET_PRODUCT，TARGET_BUILD_VARIANT，TARGET_BUILD_TYPE
• 7) 建立$(OUT_DIR)/target/common目录
• 8) 设置PROMPT_COMMAND变量，java_home，PATH目录，set_sequence_number
• 9) 打印选择产品后对应的一些编译配置变量

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84

local answer if [ "$1" ] ; then answer=$1 else #若调用者没有指定产品，那么打印产品列表，让用户选择 print_lunch_menu echo -n "Which would you like? [full-eng] " read answer fi local selection= if [ -z "$answer" ] #默认产品为full-eng then selection=full-eng elif (echo -n $answer | grep -q -e "^[0-9][0-9]*$")#用户如输入的是数字 then if [ $answer -le ${#LUNCH_MENU_CHOICES[@]} ] then selection=${LUNCH_MENU_CHOICES[$(($answer-1))]} fi #选择的产品为$product-$build_variant格式 elif (echo -n $answer | grep -q -e "^[^\-][^\-]*-[^\-][^\-]*$") then selection=$answer fi   if [ -z "$selection" ]#selection格式为$product-$build_variant then echo echo "Invalid lunch combo: $answer" return 1 fi   export TARGET_BUILD_APPS=   #提取product变量 product示例cm_i9100 local product=$(echo -n $selection | sed -e "s/-.*$//") check_product $product #检查产品是否支持 if [ $? -ne 0 ]#若产品不支持 then #if we can't find a product, try to grab it off the CM github T=$(gettop) pushd $T > /dev/null #下载prouct的配置 放在device/$vendor/$product目录 build/tools/roomservice.py $product popd > /dev/null check_product $product #再次检查产品是否支持 else #获取最新配置 更新device/$vendor/$product build/tools/roomservice.py $product true fi 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-$build_variant里提取$variant local variant=$(echo -n $selection | sed -e "s/^[^\-]*-//") 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_BUILD_TYPE=release   fixup_common_out_dir #建立$(OUT_DIR)/target/common目录   #设置PROMPT_COMMAND变量，java_home，PATH目录，set_sequence_number set_stuff_for_environment # 打印选择产品后的重要环境变量 printconfig

1.3 check_product执行流程

流程：

• 1) export CM_BUILD CM_BUILD示例：若$1是cm_i9100，则CM_BUILD是i9100
• 2) 调用get_build_var TARGET_DEVICE

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

T=$(gettop) if [ ! "$T" ]; then echo "Couldn't locate the top of the tree. Try setting TOP." >&2 return fi   if (echo -n $1 | grep -q -e "^cm_") ; then CM_BUILD=$(echo -n $1 | sed -e 's/^cm_//g') else CM_BUILD= fi export CM_BUILD CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ TARGET_PRODUCT=$1 \ TARGET_BUILD_VARIANT= \ TARGET_BUILD_TYPE= \ TARGET_BUILD_APPS= \ get_build_var TARGET_DEVICE > /dev/null

1.4 get_build_var执行流程

调用流程：lunch->check_product->get_build_var TARGET_DEVICE

此时的环境变量有

1)TARGET_PRODUCT:cm_i9100

2)CALLED_FROM_SETUP:true

3)BUILD_SYSTEM:build/core

4)export CM_BUILD=i9100

最终调用build/core/config.mk来完成检测是否支持产品$TARGET_PRODUCT

1 2 3 4 5 6 7 8

T=$(gettop) if [ ! "$T" ]; then echo "Couldn't locate the top of the tree. Try setting TOP." >&2 return fi CALLED_FROM_SETUP=true BUILD_SYSTEM=build/core \ #$1的值可能为TARGET_DEVICE make --no-print-directory -C "$T" -f build/core/config.mk dumpvar-$1

选择好产品后，可用get_build_var查看产品对应的编译变量，它依赖于以下环境变量

export TARGET_PRODUCT=cm_i9100

export TARGET_BUILD_VARIANT=userdebug

export TARGET_BUILD_TYPE=release

export CM_BUILD=i9100

因此makefile里定义的变量并未添加至环境变量，每次调用get_build_var时，其实是调用config.mk依赖的dumpvar.mk实时计算出编译变量的值

比如说LEX变量 HOST_ARCH变量

1.5 printconfig执行流程

1 2 3 4 5 6

T=$(gettop) if [ ! "$T" ]; then echo "Couldn't locate the top of the tree. Try setting TOP." >&2 return fi get_build_var report_config

最终调用build/core/dumpvar.mk来完成变量的打印

示例：

PLATFORM_VERSION_CODENAME=REL

PLATFORM_VERSION=4.2.2

CM_VERSION=10.1-20130822-UNOFFICIAL-i9100

TARGET_PRODUCT=cm_i9100

TARGET_BUILD_VARIANT=userdebug

TARGET_BUILD_TYPE=release

TARGET_BUILD_APPS=

TARGET_ARCH=arm

TARGET_ARCH_VARIANT=armv7-a-neon

HOST_ARCH=x86

HOST_OS=linux

HOST_OS_EXTRA=Linux-2.6.32-33-generic-x86_64-with-Ubuntu-10.04-lucid

HOST_BUILD_TYPE=release

BUILD_ID=JDQ39E

OUT_DIR=/home/android/tmp/android_out/CyanogenMod

1.5 mm执行流程

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26

local MM_MAKE=make local ARG= for ARG in $@ ; do #如果参数中有mka，那么利用mka进行编译 if [ "$ARG" = mka ]; then MM_MAKE=mka fi done #如果处在根目录 利用Android根目录的makefile编译选中目标 if [ -f build/core/envsetup.mk -a -f Makefile ]; then $MM_MAKE $@ else T=$(gettop) #找到最近的makfile，即当前目录所在工程的makefile local M=$(findmakefile) # Remove the path to top as the makefilepath needs to be relative local M=`echo $M|sed 's:'$T'/::'` if [ ! "$T" ]; then echo "Couldn't locate the top of the tree. Try setting TOP." elif [ ! "$M" ]; then echo "Couldn't locate a makefile from the current directory." else #使用ONE_SHOT_MAKEFILE关键字确定工程所用的makefile， #并利用Android根目录的makefile进行编译 ONE_SHOT_MAKEFILE=$M $MM_MAKE -C $T all_modules $@ fi fi

1.5 mmm执行流程

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53

local MMM_MAKE=make T=$(gettop) if [ "$T" ]; then local MAKEFILE= local MODULES= local ARGS= local DIR TO_CHOP #提取编译选项(用-指定编译参数) local DASH_ARGS=$(echo "$@" | awk -v RS=" " -v ORS=" " '/^-.*$/') #提取编译目录 local DIRS=$(echo "$@" | awk -v RS=" " -v ORS=" " '/^[^-].*$/') for DIR in $DIRS ; do MODULES=`echo $DIR | sed -n -e 's/.*:\(.*$\)/\1/p' | sed 's/,/ /'` #提取模块 dir格式:dirname:modulename if [ "$MODULES" = "" ]; then MODULES=all_modules fi DIR=`echo $DIR | sed -e 's/:.*//' -e 's:/$::'` #如果指定目录有Android.mk，计算出MAKEFILE变量的值 if [ -f $DIR/Android.mk ]; then TO_CHOP=`(cd -P -- $T && pwd -P) | wc -c | tr -d ' '` TO_CHOP=`expr $TO_CHOP + 1` START=`PWD= /bin/pwd` MFILE=`echo $START | cut -c${TO_CHOP}-` if [ "$MFILE" = "" ] ; then MFILE=$DIR/Android.mk else MFILE=$MFILE/$DIR/Android.mk fi MAKEFILE="$MAKEFILE $MFILE" else #特殊目标 其实是做编译参数 if [ "$DIR" = snod ]; then ARGS="$ARGS snod" elif [ "$DIR" = showcommands ]; then ARGS="$ARGS showcommands" elif [ "$DIR" = dist ]; then ARGS="$ARGS dist" elif [ "$DIR" = incrementaljavac ]; then ARGS="$ARGS incrementaljavac" elif [ "$DIR" = mka ]; then MMM_MAKE=mka else echo "No Android.mk in $DIR." return 1 fi fi done #使用ONE_SHOT_MAKEFILE关键字确定工程所用的makefile， #并利用Android根目录的makefile进行编译 ONE_SHOT_MAKEFILE="$MAKEFILE" $MMM_MAKE -C $T $DASH_ARGS $MODULES $ARGS else echo "Couldn't locate the top of the tree. Try setting TOP." fi

2. breakfast或者lunch命令执行后在会话终端定义的变量

在执行完breakfast或者lunch命令后，会在当前终端设置许多变量，这些变量有些只能在当前shell里使用，有些能继续在子shell里使用(用sh执行某个shell脚本即在子shell里)。根据变量定义位置，将变量分为3类：

• 1) 函数：是在函数定义的变量，但并未用export显示指出，在子shell里不可用，当前shell可用
• 2) export:导出的环境变量，子Shell也可用
• 3) 文件：文件里定义的变量

变量	类型	说明
T	函数	根目录
TARGET_BUILD_TYPE	export	release或者debug
TARGET_PRODUCT	export	示例：cm_find5
TARGET_BUILD_VARIANT	export	可能的值为user,userdebug,eng
TARGET_BUILD_APPS	export	需要编译的App集合
CM_BUILD	export	示例find5
VARIANT_CHOICES	文件	(user userdebug eng)
LUNCH_MENU_CHOICES	函数	产品列表
prebuiltdir	函数	$(getprebuilt)
gccprebuiltdir	函数	$(get_abs_build_var ANDROID_GCC_PREBUILTS)
ANDROID_EABI_TOOLCHAIN	export	工具链所在目录：以下选项之一  $ gccprebuiltdir /x86/i686-linux-android-4.6/bin  $ gccprebuiltdir /arm/arm-linux-androideabi-4.6/bin  $ gccprebuiltdir /mips/mipsel-linux-android-4.6/bin
ANDROID_TOOLCHAIN	export	$ANDROID_EABI_TOOLCHAIN
ANDROID_QTOOLS	export	$T/development/emulator/qtools
ANDROID_DEV_SCRIPTS	export	$T/development/scripts
ANDROID_BUILD_PATHS	export	$(get_build_var ANDROID_BUILD_PATHS):  $ANDROID_QTOOLS:  $ANDROID_TOOLCHAIN:  $ARM_EABI_TOOLCHAIN_PATH:  $CODE_REVIEWS:$ANDROID_DEV_SCRIPTS:
ARM_EABI_TOOLCHAIN	export	$gccprebuiltdir/ arm/arm-eabi-4.6/bin
ARM_EABI_TOOLCHAIN_PATH	函数	$gccprebuiltdir/ arm/arm-eabi-4.6/bin
toolchaindir	函数	以下三个选项之一  x86/i686-linux-android-4.6/bin  arm/arm-linux-androideabi-4.6/bin  mips/mipsel-linux-android-4.6/bin
ANDROID_JAVA_TOOLCHAIN	export	$JAVA_HOME/bin
ANDROID_PRE_BUILD_PATHS	export	$ANDROID_JAVA_TOOLCHAIN
ANDROID_PRODUCT_OUT	export	$(get_abs_build_var PRODUCT_OUT)
OUT	export	$ANDROID_PRODUCT_OUT
ANDROID_HOST_OUT	export	$(get_abs_build_var HOST_OUT)
OPROFILE_EVENTS_DIR	export	$T/external/oprofile/events
BUILD_ENV_SEQUENCE_NUMBER	export	export BUILD_ENV_SEQUENCE_NUMBER=10
PROMPT_COMMAND	export	命令提示符
CM_DEVICES_ONLY	函数	true 表示只支持CM的设备，如果使用breakfast命令会将改变量设置为true
MODVERSION	函数	$(get_build_var CM_VERSION)
ZIPFILE	函数	cm-$MODVERSION.zip
ZIPPATH	函数	$OUT/$ZIPFILE
TOPFILE	函数	build/core/envsetup.mk

用户下一步将使用mka进行编译，会利用这前两步设置的变量和函数命令，虽然breakfast命令和lunch命令有利用到一些makefile检查选择的产品是否符合要求，但是makefile里的变量都引入到当前shell,仅仅用于检查产品是否符合要求而已。

我们现在了解到breakfast命令会从网上下载产品列表，而lunch命令会下载产品的最新配置，所以我们在使用breakfast命令或者lunch命令时，会觉得时间比较长，如果是本地产品，你可以注释那些检查的代码，这样会很快。