---

★★★ 友情鏈接 : 個(gè)人博客導(dǎo)讀首頁(yè)—點(diǎn)擊此處 ★★★

1、整編譯
當(dāng)中android根目錄下敲擊make時(shí)候，根目錄下的Makefile就一句話include build/core/main.mk，即調(diào)用main.mk，以下為main.mk的依賴規(guī)則

2、模塊編譯
模塊編譯依賴各個(gè)模塊目標(biāo)。

3、recovery.img

(1)在TARGET_NO_RECOVERY=false,TARGET_NO_KERNEL=false時(shí)候
INSTALLED_RECOVERYIMAGE_TARGET := $(PRODUCT_OUT)/recovery.img
依賴關(guān)系如下，則會(huì)生成revovery.img

(2)在AB分區(qū)功能打開，即TARGET_NO_KERNEL=true時(shí)，INSTALLED_RECOVERYIMAGE_TARGET等于空，則后面的依賴關(guān)系不復(fù)存在，也就不會(huì)生成revovery.img了

4、boot.img
.PHONY: bootimage
bootimage: $(INSTALLED_BOOTIMAGE_TARGET)
INSTALLED_BOOTIMAGE_TARGET := $(PRODUCT_OUT)/boot.img
(1)無AB分區(qū)功能時(shí)的boot.img的依賴規(guī)則如下

（2）啟用AB分區(qū)時(shí)候，BOARD_USES_RECOVERY_AS_BOOT=true，此時(shí)的依賴規(guī)則變成如下：

可以看出，此時(shí)boot.img的生成規(guī)則，與無AB分區(qū)時(shí)生成revovery.img時(shí)候的規(guī)則一樣。即現(xiàn)在的boot.img就是以前的recovery.img

5、system.img
system.img的依賴關(guān)系

build-systemimage-target函數(shù)最終調(diào)用到build_image.py用戶創(chuàng)建鏡像

此前boot.img里面的ramdisk是recovery系統(tǒng)的recovery ramdisk，那之前boot.img里的ramdisk呢？系統(tǒng)如何來掛著system分區(qū)的呢？？？ 看下面代碼，可知，原boot.img里的ramdisk挪到system.img里面了。
build_image.py 調(diào)用了BuildImage函數(shù)
BuildImage函數(shù)部分內(nèi)容如下：

6、userdateimage

7、cache.img
啟用AB分區(qū)時(shí)候，BOARD_CACHEIMAGE_FILE_SYSTEM_TYPE 沒有定義，這里條件不能滿足，所以不會(huì)生成cache.img

8、vendor.img
和BOARD_VENDORIMAGE_FILE_SYSTEM_TYPE宏是否定義相關(guān)。

9、有關(guān)AB分區(qū)的總結(jié)如下：
recovery.img，不再單獨(dú)生成，傳統(tǒng)方式的recovery.img現(xiàn)在叫做boot.img
boot.img，包含kernel和recovery模式的ramdisk
system.img，傳統(tǒng)方式下system.img由$(PRODUC{T}_{O}UT)/system文件夾打包而成，A/B系統(tǒng)下，制作時(shí)將$(PRODUCT_OUT)/root和$(PRODUC{T}_{O}UT)/system合并到一起，生成一個(gè)完整的帶有rootfs的system.imguserdata.img，跟原來一樣，打包$(PRODUCT_OUT)/data文件夾而成
cache.img，A/B系統(tǒng)下不再單獨(dú)生成cache.img
vendor.img，文件的生成跟是否A/B系統(tǒng)無關(guān)，主要有廠家決定

《新程序員》：云原生和全面數(shù)字化實(shí)踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的Android Makefile编译流程的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。