google给出的编译步骤如下:
1、 sourcebuild/envsetup.sh:加载命令
2、 lunch:选择平台编译选项
3、make:执行编译
下面按照编译步骤来分析编译过程的细节
一、source build/envsetup.sh
将envsetup.sh里的所有用到的命令加载到环境变量里去。
envsetup.sh里的主要命令如下:
function m() # make from top
function mm() # make from current directory
function mmm() # make thesupplied directoriesfunction lunch() # 配置lunch
function choosecombo() #设置编译参数
function add_lunch_combo() #添加lunch项目
function print_lunch_menu() # 打印lunch列表
function croot() # 回到根目录
function godir() # 跳到指定目录
function cproj()
function jgrep() # 查找java文件
function cgrep() #查找c/cpp文件
function resgrep()
function findmakefile() # 查找makefile
# add_lunch_combo函数被多次调用,就是它来添加Android编译选项
# Clear this variable. It willbe built up again when the vendorsetup.sh
# files are included at the end of thisfile.
# 清空LUNCH_MENU_CHOICES变量,用来存在编译选项
unset LUNCH_MENU_CHOICES
function add_lunch_combo()
{
localnew_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 thesimulator. 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 canfind.
for f in `/bin/ls vendorbuild/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_comboxxx-xxx。
根据上面的内容,可以推测出,如果要想定义自己的产品编译项,简单的办法是直接在envsetup.sh最后,添加上add_lunch_combomyProduct-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:测试机
那么这四个类型是干什么用的呢?其实,在main.mk里有说明,在Android的源码里,每个工程目录都有一个Android.mk的makefile,每个目标的Android.mk中有一个类型声明:LOCAL_MODULE_TAGS,这个TAGS就是用来指定,当前的目标编译完了属于哪个分类里。
好了,我们来分析下lunch命令干了什么?
function lunch()
{
localanswer 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 localselection=
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 # specialcase 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命令了,下篇来分析。