Android7.0 编译系统流程分析
来源:互联网 发布:淘宝部分退款在哪 编辑:程序博客网 时间:2024/06/08 09:30
本文按照Android编译三部曲(source,lunch和make)的步骤来分析查看每个环节的主要流程,由于编译系统太过庞大,这里只是从关键的主干流程上做一个分析,不可能做到每个细节都剖析清楚,由于水平有限,如果有描述不够正确的地方,欢迎大家毫无保留的指正错误,在此先谢过。
1,source流程
当我们在终端执行命令source build/envsetup.sh时,其实是完整的加载了脚本envsetup.sh中的变量和方法,其中最重要的函数比如lunch就是在这一步加载到shell环境变量中去的,比较常用的函数有:
croot
切换到源码树的根目录
lunch
选择编译板型
m
在源码树的根目录执行 make
mm
build 当前目录下的模块
mmm
build 指定目录下的模块
cgrep
在所有 C/C++ 文件上执行 grep
jgrep
在所有 Java 文件上执行 grep
resgrep
在所有 res/*.xml 文件上执行 grep
godir
转到包含某个文件的目录路径
printconfig
显示当前 Build 的配置信息
add_lunch_combo
在 lunch 函数的菜单中添加一个条目
除了加载上述函数,还执行了以下初始化和动作:
1> 提前定义3种编译模式,供后面使用:
139 VARIANT_CHOICES=(user userdebug eng)
说明:数字139是这行代码在文件中的行号,下面的也是如此。
2> 使用变量LUNCH_MENU_CHOICES之前,先将它清空:
503 unset LUNCH_MENU_CHOICES
3> 默认会加载如下6个板型选项,这样后续的lunch菜单中就可以看到这几个板型:
517 add_lunch_combo aosp_arm-eng 518 add_lunch_combo aosp_arm64-eng 519 add_lunch_combo aosp_mips-eng 520 add_lunch_combo aosp_mips64-eng 521 add_lunch_combo aosp_x86-eng 522 add_lunch_combo aosp_x86_64-eng
下面就看看函数add_lunch_combo的实现:
504 function add_lunch_combo() 505 { 506 local new_combo=$1 507 local c 508 for c in ${LUNCH_MENU_CHOICES[@]} ; do 509 if [ "$new_combo" = "$c" ] ; then 510 return 511 fi 512 done 513 LUNCH_MENU_CHOICES=(${LUNCH_MENU_CHOICES[@]} $new_combo) //这里把板型添加到数组中去了 514 }
处理逻辑就是先从LUNCH_MENU_CHOICES中循环查找,看存不存在要添加的板型,如果存在就直接返回,如果不存在就添加到LUNCH_MENU_CHOICES中;除了上述添加的aosp的6个板型外,在device/actions/目录中还有大量的add_lunch_combo的调用,部分摘录如下:
./device/actions/s900_evb/vendorsetup.sh:add_lunch_combo s900_evb-eng./device/actions/s900_evb/vendorsetup.sh:add_lunch_combo s900_evb-userdebug./device/actions/s900_evb/vendorsetup.sh:add_lunch_combo s900_evb-user./device/actions/v700_gb7_nibiru/vendorsetup.sh:add_lunch_combo v700_gb7_nibiru-eng./device/actions/v700_gb7_nibiru/vendorsetup.sh:add_lunch_combo v700_gb7_nibiru-userdebug./device/actions/v700_gb7_nibiru/vendorsetup.sh:add_lunch_combo v700_gb7_nibiru-user./device/actions/v700_cxvr/vendorsetup.sh:add_lunch_combo v700_cxvr-eng./device/actions/v700_cxvr/vendorsetup.sh:add_lunch_combo v700_cxvr-userdebug./device/actions/v700_cxvr/vendorsetup.sh:add_lunch_combo v700_cxvr-user./device/actions/s900_96board/vendorsetup.sh:add_lunch_combo s900_96board-eng./device/actions/s900_96board/vendorsetup.sh:add_lunch_combo s900_96board-userdebug./device/actions/s900_96board/vendorsetup.sh:add_lunch_combo s900_96board-user
这些全部都是在板型目录中的vendorsetup.sh脚本中写明的,脚本何时被调用的呢?【留个问题在此】
4> 下面这行的意思是,当敲入lunch命令后用Tab键进行补全时,会执行_lunch()函数:
630 complete -F _lunch lunch
马上实践一下,发现敲完lunch后按Tab键补全果然会有东西打印出来:
aosp_angler-userdebug gt9_ebox-user s900_96board_sd0_boot-eng s900_evb_sd0_boot-eng s900vr_ys_2k-engaosp_arm-eng gt9_ebox-userdebug s900_96board_sd0_boot-user s900_evb_sd0_boot-user s900vr_ys_2k-useraosp_arm64-eng hikey-userdebug s900_96board_sd0_boot-userdebug s900_evb_sd0_boot-userdebug s900vr_ys_2k-userdebugaosp_bullhead-userdebug m_e_arm-userdebug s900_RY_VR-eng s900_qcb-eng v700_cxvr-engaosp_dragon-eng m_e_mips-userdebug s900_RY_VR-user s900_qcb-user v700_cxvr-useraosp_dragon-userdebug m_e_mips64-eng s900_RY_VR-userdebug s900_qcb-userdebug v700_cxvr-userdebugaosp_flounder-userdebug mini_emulator_arm64-userdebug s900_evb-eng s900_tpe-eng v700_gb7_nibiru-eng
那就看看函数_lunch的实现:
620 function _lunch() 621 { 622 local cur prev opts 623 COMPREPLY=() 624 cur="${COMP_WORDS[COMP_CWORD]}" 625 prev="${COMP_WORDS[COMP_CWORD-1]}" 627 COMPREPLY=( $(compgen -W "${LUNCH_MENU_CHOICES[*]}" -- ${cur}) ) 628 return 0 629 }
这个函数的代码几乎是固定的,除了627行中的${LUNCH_MENU_CHOICES[*]}是可变的,其他部分都必须这么写,否则无法实现补全。所以数组LUNCH_MENU_CHOICES的内容就是补全时打印出来的内容,而数组的内容其实就是上面提到的调用函数add_lunch_combo增加进来的。
5> shell检查和警告,这里只支持bash,如果是其他的shell会发出这个WARNING:
1612 if [ "x$SHELL" != "x/bin/bash" ]; then1613 case `ps -o command -p $$` in1614 *bash*)1615 ;;1616 *)1617 echo "WARNING: Only bash is supported, use of other shell would lead to erroneous results"1618 ;;1619 esac1620 fi
6> 这一步是整个source过程中最重要的步骤:
1622 # Execute the contents of any vendorsetup.sh files we can find.1623 for f in `test -d device && find -L device -maxdepth 4 -name 'vendorsetup.sh' 2> /dev/null | sort` \1624 `test -d vendor && find -L vendor -maxdepth 4 -name 'vendorsetup.sh' 2> /dev/null | sort` \1625 `test -d product && find -L product -maxdepth 4 -name 'vendorsetup.sh' 2> /dev/null | sort`1626 do1627 echo "including $f"1628 . $f1629 done1630 unset f
这里可以分解为3个动作:
第一, 搜索所有vendorsetup.sh脚本;
第二, 打印所有找到的vendorsetup.sh文件路径;
第三, 加载所有找到的vendorsetup.sh脚本。【这里回答了上面留的问题】
那就看看vendorsetup.sh的内容,以板型v700_cxvr为例:
17 add_lunch_combo v700_cxvr-eng 18 add_lunch_combo v700_cxvr-userdebug 19 add_lunch_combo v700_cxvr-user
其实就是调用函数add_lunch_combo把板型v700_cxvr增加到LUNCH_MENU_CHOICES数组中去。
注意:查找的目录层级为4层,如果添加的vendorsetup.sh脚本的目录层级太深,会发生找不到的情况。
7> 看看source的最后一步:
1632 addcompletions
直接看函数addcompletions的实现:
311 function addcompletions() 312 { 313 local T dir f 314 315 # Keep us from trying to run in something that isn't bash. 316 if [ -z "${BASH_VERSION}" ]; then 317 return 318 fi 319 320 # Keep us from trying to run in bash that's too old. 321 if [ ${BASH_VERSINFO[0]} -lt 3 ]; then 322 return 323 fi 324 325 dir="sdk/bash_completion" 326 if [ -d ${dir} ]; then 327 for f in `/bin/ls ${dir}/[a-z]*.bash 2> /dev/null`; do 328 echo "including $f" 329 . $f 330 done 331 fi 332 }
如果BASH的版本为空或者小于3都直接返回,否则打印android/sdk/bash_completion/目录下的以.bash结尾的所有文件,目前看来只有这一个:
including sdk/bash_completion/adb.bash
至此, source build/envsetup.sh的过程就分析完了。
2,lunch流程
在source流程之后,紧接着就是执行lunch操作,lunch操作执行的其实就是build/envsetup.sh脚本中的lunch函数,下面看看lunch函数都做了哪些事情。
1> 获取用户编译目标到answer变量:
545 local answer 546 547 if [ "$1" ] ; then 548 answer=$1 549 else 550 print_lunch_menu 551 echo -n "Which would you like? [aosp_arm-eng] " 552 read answer 553 fi
如果lunch命令后跟有参数,则直接赋给answer变量;
如果lunch命令后没有参数,则调用函数print_lunch_menu打印出板型列表供用户选择,并将用户的选择存储在answer变量中。
看看print_lunch_menu函数的实现:
524 function print_lunch_menu() 525 { 526 local uname=$(uname) 527 echo 528 echo "You're building on" $uname 529 echo 530 echo "Lunch menu... pick a combo:" 531 532 local i=1 533 local choice 534 for choice in ${LUNCH_MENU_CHOICES[@]} 535 do 536 echo " $i. $choice" 537 i=$(($i+1)) 538 done 539 540 echo 541 }
函数的作用就是打印数组LUNCH_MENU_CHOICES的内容。
2> 从answer变量到selection变量:
555 local selection= 556 557 if [ -z "$answer" ] 558 then 559 selection=aosp_arm-eng 560 elif (echo -n $answer | grep -q -e "^[0-9][0-9]*$") 561 then 562 if [ $answer -le ${#LUNCH_MENU_CHOICES[@]} ] 563 then 564 selection=${LUNCH_MENU_CHOICES[$(($answer-1))]} 565 fi 566 elif (echo -n $answer | grep -q -e "^[^\-][^\-]*-[^\-][^\-]*$") 567 then 568 selection=$answer 569 fi 570 571 if [ -z "$selection" ] 572 then 573 echo 574 echo "Invalid lunch combo: $answer" 575 return 1 576 fi
如果answer为空,则selection默认赋值为aosp_arm-eng;
如果answer是纯数字,则将answer作为数组下标从LUNCH_MENU_CHOICES数组中取出板型名称;
如果anwser是字符串,并且字符串使用”-”连接,而且”-”连接的前后两个子串中都没有”-”,则认为是板型名称字符串,直接赋给selection。
经过上述3步,如果发现selection仍然为空,则直接报错并退出。
3> 从selection变量到variant变量
580 local variant=$(echo -n $selection | sed -e "s/^[^\-]*-//") 581 check_variant $variant 582 if [ $? -ne 0 ] 583 then 584 echo 585 echo "** Invalid variant: '$variant'" 586 echo "** Must be one of ${VARIANT_CHOICES[@]}" 587 variant= 588 fi
从selection中取出“-”后面的字符串到variant,类似从字符串"aosp_arm-eng"中取出"eng",然后调用函数check_variant判断variant是否符合要求。check_variant函数很简单,主要就是用到前文source流程中初始化为"user userdebug eng"的VARIANT_CHOICES数组,判断variant是否是数组成员之一,是则返回0,不是则返回1。
4> 从selection变量到product变量
590 local product=$(echo -n $selection | sed -e "s/-.*$//") 591 TARGET_PRODUCT=$product \ 592 TARGET_BUILD_VARIANT=$variant \ 593 build_build_var_cache 594 if [ $? -ne 0 ] 595 then 596 echo 597 echo "** Don't have a product spec for: '$product'" 598 echo "** Do you have the right repo manifest?" 599 product= 600 fi
再从selection中取出“-”前面的字符串到product,类似从字符串"aosp_arm-eng"中取出"aosp_arm",然后将product赋值给TARGET_PRODUCT,将variant赋值给TARGET_BUILD_VARIANT,然后再调用函数build_build_var_cache对编译时所必需的环境变量进行赋值和处理,并根据函数返回结果做对应处理。
5> 对关键变量做最终处理:
602 if [ -z "$product" -o -z "$variant" ] 603 then 604 echo 605 return 1 606 fi 607 608 export TARGET_PRODUCT=$product 609 export TARGET_BUILD_VARIANT=$variant 610 export TARGET_BUILD_TYPE=release
如果到这里仍然发现product或者variant为空,那肯定是出错了,直接退出;否则导出以下准备好的宏变量供整个shell环境使用:
TARGET_PRODUCT
TARGET_BUILD_VARIANT
TARGET_BUILD_TYPE
6> 最后三个函数调用:
614 set_stuff_for_environment 615 printconfig 616 destroy_build_var_cache
函数set_stuff_for_environment主要就是设置PROMPT_COMMAND,ANDROID_BUILD_PATHS,JAVA_HOME和BUILD_ENV_SEQUENCE_NUMBER等等环境变量;
函数printconfig用来打印最终准备好的环境变量,通常如下:
============================================PLATFORM_VERSION_CODENAME=RELPLATFORM_VERSION=7.0TARGET_PRODUCT=s900_RY_VRTARGET_BUILD_VARIANT=userdebugTARGET_BUILD_TYPE=releaseTARGET_BUILD_APPS=TARGET_ARCH=armTARGET_ARCH_VARIANT=armv7-a-neonTARGET_CPU_VARIANT=cortex-a53TARGET_2ND_ARCH=TARGET_2ND_ARCH_VARIANT=TARGET_2ND_CPU_VARIANT=HOST_ARCH=x86_64HOST_2ND_ARCH=x86HOST_OS=linuxHOST_OS_EXTRA=Linux-3.2.0-29-generic-x86_64-with-Ubuntu-12.04-preciseHOST_CROSS_OS=windowsHOST_CROSS_ARCH=x86HOST_CROSS_2ND_ARCH=x86_64HOST_BUILD_TYPE=releaseBUILD_ID=NRD90MOUT_DIR=out============================================
函数destroy_build_var_cache用来清除不再需要的中间环节产生的变量的值。
至此,lunch流程就分析完了。
3,make流程
3.1 编译入口
当我们在Android源码根目录下执行make的时候,会查找当前目录下的Makefie文件或者makefile文件并且执行,在android/Makefile文件中,它只有一行有用的内容:
1 ### DO NOT EDIT THIS FILE ### 2 include build/core/main.mk 3 ### DO NOT EDIT THIS FILE ###
因此,执行make时真正的入口是android/build/core/main.mk文件。
3.2 整体依赖
我们在Android源码根目录下执行make命令的时候,并没有传入目标,那么就会执行默认的目标。那默认的目标是什么呢?在android/build/core/main.mk中有这样几行:
63 # This is the default target. It must be the first declared target. 64 .PHONY: droid 65 DEFAULT_GOAL := droid 66 $(DEFAULT_GOAL): droid_targets
从63行注释可以看出,默认编译的就是droid这个伪目标,make工具遇到伪目标以后,会检查解析伪目标的依赖,如果伪目标存在依赖,就会检查这些依赖,如果这些依赖是伪目标,就继续检查这个伪目标的依赖,如果不是伪目标,就会生成这个目标,如此一层一层递归下去。
另外,在android/build/core/main.mk中还有这样几行:
1046 # Building a full system-- the default is to build droidcore1047 droid_targets: droidcore dist_files
这就说明droid这个伪目标依赖droidcore和dist_files两大部分(整体编译时TARGET_BUILD_APPS为空),然后再将这两个依赖逐步解析下去,可以得到编译droid的整体依赖关系如下图:
有必要说明两点:
1)有些依赖(比如INSTALLED_BOOTIMAGE_TARGET)在android/build/core/main.mk中没有定义,而是在android/build/core/Makefile中定义的;
2)上面dist_files也是个伪目标,并且它没有任何依赖,利用dist-for-goals方法来拷贝库文件,可忽略。
3.3 编译主流程
3.3.1 加载板型配置
首先各mk文件调用关系如下:
下面就来看看product_config.mk文件,首先调用方法get-all-product-makefiles找出所有的AndoridProducts.mk文件:
182 ifneq ($(strip $(TARGET_BUILD_APPS)),)183 # An unbundled app build needs only the core product makefiles.184 all_product_configs := $(call get-product-makefiles,\185 $(SRC_TARGET_DIR)/product/AndroidProducts.mk)186 else187 # Read in all of the product definitions specified by the AndroidProducts.mk188 # files in the tree.189 all_product_configs := $(get-all-product-makefiles)190 endif
(方法get-all-product-makefiles的定义在文件product.mk中,实现细节可自行研究)
然后从all_product_configs中找出我们当前产品的AndoridProducts.mk文件:
192 # Find the product config makefile for the current product.193 # all_product_configs consists items like:194 # <product_name>:<path_to_the_product_makefile>195 # or just <path_to_the_product_makefile> in case the product name is the196 # same as the base filename of the product config makefile.197 current_product_makefile :=198 all_product_makefiles :=199 $(foreach f, $(all_product_configs),\200 $(eval _cpm_words := $(subst :,$(space),$(f)))\201 $(eval _cpm_word1 := $(word 1,$(_cpm_words)))\202 $(eval _cpm_word2 := $(word 2,$(_cpm_words)))\203 $(if $(_cpm_word2),\204 $(eval all_product_makefiles += $(_cpm_word2))\205 $(if $(filter $(TARGET_PRODUCT),$(_cpm_word1)),\206 $(eval current_product_makefile += $(_cpm_word2)),),\207 $(eval all_product_makefiles += $(f))\208 $(if $(filter $(TARGET_PRODUCT),$(basename $(notdir $(f)))),\209 $(eval current_product_makefile += $(f)),)))210 _cpm_words :=211 _cpm_word1 :=212 _cpm_word2 :=213 current_product_makefile := $(strip $(current_product_makefile))
比如我们在执行lunch时选择的板型是v700_cxvr,则current_product_makefile的值就是:android/device/actions/v700_cxvr/AndroidProducts.mk,而这个AndroidProducts.mk的内容其实就是指定板型配置信息文件android/device/actions/v700_cxvr/v700_cxvr.mk
接着调用import-products导入产品配置信息:
239 $(call import-products, $(current_product_makefile))
(方法import-products的定义也在文件android/build/core/product.mk中,实现细节可自行研究)
接着设置TARGET_DEVICE的值,其实就是v700_cxvr:
268 # Find the device that this product maps to.269 TARGET_DEVICE := $(PRODUCTS.$(INTERNAL_PRODUCT).PRODUCT_DEVICE)
接着设置PRODUCT_COPY_FILES,这个变量指定了需要拷贝的文件:
346 PRODUCT_COPY_FILES := \347 $(strip $(PRODUCTS.$(INTERNAL_PRODUCT).PRODUCT_COPY_FILES))
接着设置PRODUCT_PROPERTY_OVERRIDES属性:
351 PRODUCT_PROPERTY_OVERRIDES := \352 $(strip $(PRODUCTS.$(INTERNAL_PRODUCT).PRODUCT_PROPERTY_OVERRIDES))
接着回到android/build/core/envsetup.mk中,include了板型配置文件BoardConfig.mk
144 board_config_mk := \145 $(strip $(sort $(wildcard \146 $(SRC_TARGET_DIR)/board/$(TARGET_DEVICE)/BoardConfig.mk \147 $(shell test -d device && find -L device -maxdepth 4 -path '*/$(TARGET_DEVICE)/BoardConfig.mk') \148 $(shell test -d vendor && find -L vendor -maxdepth 4 -path '*/$(TARGET_DEVICE)/BoardConfig.mk') \149 )))150 ifeq ($(board_config_mk),)151 $(error No config file found for TARGET_DEVICE $(TARGET_DEVICE))152 endif153 ifneq ($(words $(board_config_mk)),1)154 $(error Multiple board config files for TARGET_DEVICE $(TARGET_DEVICE): $(board_config_mk))155 endif156 include $(board_config_mk)
至此,板型配置基本加载完毕。
3.3.2 加载所有模块
加载完板型配置信息后,回到main.mk文件中,很快发现了ONE_SHOT_MAKEFILE的使用。如果这个变量被定义了,那么就是编译一个模块,如果没有被定义,就说明是编译整个系统。MAKECMDGOALS是make的一个环境变量,当我们执行make的时候并没有设置它,因此它为空。所以dont_bother不等于true,因此会加载所有的Android.mk,这里是调用一个python脚本android/build/tools/findleaves.py来查找系统中所有的Android.mk,然后循环include进来:
542 # Include all of the makefiles in the system 543 # 544 545 # Can't use first-makefiles-under here because 546 # --mindepth=2 makes the prunes not work. 547 subdir_makefiles := \ 548 $(shell build/tools/findleaves.py $(FIND_LEAVES_EXCLUDES) $(subdirs) Android.mk) 549 550 ifeq ($(USE_SOONG),true) 551 subdir_makefiles := $(SOONG_ANDROID_MK) $(call filter-soong-makefiles,$(subdir_makefiles)) 552 endif 553 554 $(foreach mk, $(subdir_makefiles),$(info including $(mk) ...)$(eval include $(mk))) //这里循环include进来
3.4 JACK调用
JACK是Android7.0默认使用的编译器,在config.mk中,有JACK的定义,其实JACK的值为:out/host/linux-x86/bin/jack
499 # Generic tools.500 JACK := $(HOST_OUT_EXECUTABLES)/jack
在definitions.mk中,有call-jack的定义:
2015 # Call jack2016 #2017 define call-jack2018 JACK_VERSION=$(PRIVATE_JACK_VERSION) $(JACK) $(DEFAULT_JACK_EXTRA_ARGS)2019 endef
在definitions.mk中,也有jack-java-to-dex的定义,在jack-java-to-dex中会调用call-jack去编译java文件:
2092 define jack-java-to-dex2093 $(hide) rm -f $@2094 $(hide) rm -f $(PRIVATE_CLASSES_JACK)2095 $(hide) rm -rf $(PRIVATE_JACK_INTERMEDIATES_DIR)2096 $(hide) mkdir -p $(dir $@)2097 $(hide) mkdir -p $(dir $(PRIVATE_CLASSES_JACK))2098 $(hide) mkdir -p $(PRIVATE_JACK_INTERMEDIATES_DIR)2099 $(if $(PRIVATE_JACK_INCREMENTAL_DIR),$(hide) mkdir -p $(PRIVATE_JACK_INCREMENTAL_DIR))2100 $(call dump-words-to-file,$(PRIVATE_JAVA_SOURCES),$(PRIVATE_JACK_INTERMEDIATES_DIR)/java-source-list)2101 $(hide) if [ -d "$(PRIVATE_SOURCE_INTERMEDIATES_DIR)" ]; then \2102 find $(PRIVATE_SOURCE_INTERMEDIATES_DIR) -name '*.java' >> $(PRIVATE_JACK_INTERMEDIATES_DIR)/java-source-list; \2103 fi2104 $(hide) tr ' ' '\n' < $(PRIVATE_JACK_INTERMEDIATES_DIR)/java-source-list \2105 | $(NORMALIZE_PATH) | sort -u > $(PRIVATE_JACK_INTERMEDIATES_DIR)/java-source-list-uniq2106 $(if $(PRIVATE_JACK_PROGUARD_FLAGS), \2107 $(hide) echo -basedirectory $(CURDIR) > $@.flags; \2108 echo $(PRIVATE_JACK_PROGUARD_FLAGS) >> $@.flags; \2109 )2110 $(if $(PRIVATE_EXTRA_JAR_ARGS),2111 $(hide) mkdir -p $@.res.tmp2112 $(hide) $(call create-empty-package-at,$@.res.tmp.zip)2113 $(hide) $(call add-java-resources-to,$@.res.tmp.zip)2114 $(hide) unzip -qo $@.res.tmp.zip -d $@.res.tmp2115 $(hide) rm $@.res.tmp.zip)2116 $(hide) if [ -s $(PRIVATE_JACK_INTERMEDIATES_DIR)/java-source-list-uniq ] ; then \2117 export tmpEcjArg="@$(PRIVATE_JACK_INTERMEDIATES_DIR)/java-source-list-uniq"; \2118 else \2119 export tmpEcjArg=""; \2120 fi; \2121 $(call call-jack) \ //这里调用的call-jack2122 $(strip $(PRIVATE_JACK_FLAGS)) \2123 $(strip $(PRIVATE_JACK_COVERAGE_OPTIONS)) \2124 $(if $(NO_OPTIMIZE_DX), \2125 -D jack.dex.optimize="false") \2126 $(if $(PRIVATE_RMTYPEDEFS), \2127 -D jack.android.remove-typedef="true") \2128 $(addprefix --classpath ,$(strip \2129 $(call normalize-path-list,$(PRIVATE_BOOTCLASSPATH_JAVA_LIBRARIES) $(PRIVATE_ALL_JACK_LIBRARIES)))) \2130 $(addprefix --import ,$(call reverse-list,$(PRIVATE_STATIC_JACK_LIBRARIES))) \2131 $(if $(PRIVATE_EXTRA_JAR_ARGS),--import-resource $@.res.tmp) \2132 -D jack.android.min-api-level=$(PRIVATE_JACK_MIN_SDK_VERSION) \2133 -D jack.import.resource.policy=keep-first \2134 -D jack.import.type.policy=keep-first \2135 --output-jack $(PRIVATE_CLASSES_JACK) \2136 $(if $(PRIVATE_JACK_INCREMENTAL_DIR),--incremental-folder $(PRIVATE_JACK_INCREMENTAL_DIR)) \2137 --output-dex $(PRIVATE_JACK_INTERMEDIATES_DIR) \2138 $(addprefix --config-jarjar ,$(strip $(PRIVATE_JARJAR_RULES))) \2139 $(if $(PRIVATE_JACK_PROGUARD_FLAGS),--config-proguard $@.flags) \2140 $$tmpEcjArg \2141 || ( rm -rf $(PRIVATE_CLASSES_JACK); exit 41 )2142 $(hide) mv $(PRIVATE_JACK_INTERMEDIATES_DIR)/classes*.dex $(dir $@)2143 $(hide) rm -f $(PRIVATE_JACK_INTERMEDIATES_DIR)/java-source-list2144 $(if $(PRIVATE_EXTRA_JAR_ARGS),$(hide) rm -rf $@.res.tmp)2145 $(hide) mv $(PRIVATE_JACK_INTERMEDIATES_DIR)/java-source-list-uniq $(PRIVATE_JACK_INTERMEDIATES_DIR).java-source-list2146 $(if $(PRIVATE_JAR_PACKAGES), $(hide) echo unsupported options PRIVATE_JAR_PACKAGES in $@; exit 53)2147 $(if $(PRIVATE_JAR_EXCLUDE_PACKAGES), $(hide) echo unsupported options JAR_EXCLUDE_PACKAGES in $@; exit 53)2148 $(if $(PRIVATE_JAR_MANIFEST), $(hide) echo unsupported options JAR_MANIFEST in $@; exit 53)2149 endef
在java.mk和host_dalvik_java_library.mk中,都有调用jack-java-to-dex来编译java:
上图中,左边浅红色部分这些宏变量在 config.mk文件中有定义,定义如下:
BUILD_STATIC_JAVA_LIBRARY=static_java_library.mk
BUILD_JAVA_LIBRARY=java_library.mk
BUILD_PACKAGE=package.mk
BUILD_HOST_DALVIK_JAVA_LIBRARY=host_dalvik_java_library.mk
这些宏变量将会大量出现在各个模块的Android.mk文件中,而Android.mk文件又被编译系统全部找出并include进来(上面3.3.2有提到),这样编译系统就等于间接调用了jack来编译java文件。
- Android7.0 编译系统流程分析
- Android7.0 编译系统流程分析
- Android7.0 编译系统流程分析
- Android7.0关机流程分析
- Android7.0 startService流程分析
- Android7.0关机流程分析
- android7.0拨号流程分析
- [Android7.0]开启NFC的流程分析
- [Android7.0]NFC初始化的流程分析
- Android7.0 init.rc流程分析
- Android7.0 Vold 进程工作机制分析之整体流程
- Android7.0 Vold 进程工作机制分析之整体流程
- 基于android7.0流程分析anr产生原因
- Android7.0 Activity启动流程调用栈分析
- Android7.0去电流程源码分析(一)
- Android7.0去电流程源码分析(二)
- Android7.0 编译问题
- Android7.0 下载编译
- iOS 应用内跳转到百度地图、苹果地图、谷歌地图、高德地图等
- android性能优化-----TraceView
- sql之left join、right join、inner join的区别
- 字符拆分 邮箱
- 简单的两句话 轻松搞定tableview的高度自适应
- Android7.0 编译系统流程分析
- 如何在一台windows主机上搭建mysql主从配置
- https是如何工作的?
- stevedore简介
- maven学习(2)
- Spring注解@Component、@Repository、@Service、@Controller @Resource、@Autowired、@Qualifier 解析
- 30岁从新开始
- 职场人士如何减压-有效减压六大方法
- lambda表达式: