接下來(lái)準(zhǔn)備把以前寫的Android編譯系統(tǒng)方面的資料整理成MarkDown.
這次Android編譯系統(tǒng)的代碼基于Android 6.0.
在整體來(lái)看Android編譯系統(tǒng)的時(shí)候，有兩個(gè)概念必須要十分清楚：Product和Device.
Product產(chǎn)品
不同的人對(duì)于產(chǎn)品的理解不一樣，對(duì)于設(shè)計(jì)人員來(lái)講，不同的產(chǎn)品對(duì)應(yīng)著不同的外觀，不同的尺寸，不同的材質(zhì)。但是對(duì)于Android來(lái)講，產(chǎn)品就是不同模塊的組合。每一個(gè)模塊由一個(gè)Android.mk編譯。模塊分為三類：
- 基礎(chǔ)模塊
比如AMS，PMS和Binder等都是基礎(chǔ)模塊，這些模塊都是必須要編譯的，否則Android無(wú)法啟動(dòng)
-
可選的基礎(chǔ)模塊
比如packages/apps下面的應(yīng)用
項(xiàng)目私有模塊
大部分是和硬件特性相關(guān)的模塊，比如雙攝像頭，指紋識(shí)別等。
我們一般都是根據(jù)足以讓用戶區(qū)分的硬件特性來(lái)定義產(chǎn)品，比如小米5和小米6是兩款產(chǎn)品，他們擁有不同的外觀設(shè)計(jì)，不同的硬件規(guī)格，比如小米5是單攝像頭，小米6是雙攝像頭，他們的CPU也不一樣，他們的外觀和材質(zhì)也不一樣。這些不同的硬件feature軟件上就對(duì)應(yīng)不同的模塊，模塊的不同構(gòu)成了產(chǎn)品的不同。
Device設(shè)備
同一個(gè)產(chǎn)品可能有不同的設(shè)備，比如小米5會(huì)有全網(wǎng)通版本，移動(dòng)版本，電信版本等。這些不同的版本在軟件概念上就對(duì)應(yīng)不同的Device。雖然他們都叫小米5，但是由于硬件板級(jí)上的不同，造成了不同的Device.
我們編譯出來(lái)的img，最終都要燒到對(duì)應(yīng)的板子上，也就是對(duì)應(yīng)的Device上。那么我們?cè)诰幾g過(guò)程中怎么確定我們正在編譯的這個(gè)Rom是對(duì)應(yīng)哪個(gè)Device呢？答案就是Target_Device這個(gè)變量，這是在編譯過(guò)程中非常重要的一個(gè)變量，該變量決定了我們的img最終可以燒寫到哪個(gè)Device上。
所以總結(jié)如下：
- Product決定了這編譯過(guò)程中都有哪些模塊需要編譯
- Device決定了我們編譯出來(lái)的img可以燒寫到哪些設(shè)備上。
既然Target_Device這么重要，我們就來(lái)看一下編譯系統(tǒng)是如何確定Target_Device的值得。
根據(jù)Android編譯規(guī)范，我們的編譯過(guò)程是從 source build/envsteup.sh開(kāi)始的。
我們看一下這個(gè)envsetup.sh都做了哪些事情：
定義了很多函數(shù)，比如mm，lunch等，也就是說(shuō)只有在執(zhí)行完這一步之后，這些函數(shù)才可以使用
-
然后執(zhí)行
for f in `test -d device && find -L device -maxdepth 4 -name 'vendorsetup.sh' 2> /dev/null | sort` \ `test -d vendor && find -L vendor -maxdepth 4 -name 'vendorsetup.sh' 2> /dev/null | sort`
去device和vendor目錄下的4層文件夾之內(nèi)尋找vendorsetup.sh這個(gè)文件。
這個(gè)vendorsetup.sh這個(gè)文件是做什么用的呢？
所有的vendorsetup.sh幾乎都有這么一句類似的話
add_lunch_combo aosp_deb-userdebug,這句話的作用是把a(bǔ)osp_deb-userdebug加入到lunch菜單中。
我們?cè)谳斎雔unch命令之后，會(huì)出現(xiàn)一個(gè)編譯菜單，比如：
- aosp_x86_64-eng
- aosp_deb-userdebug
- aosp_flo-userdebug
一般這個(gè)編譯菜單格式固定：ProductName_DeviceName-BuildVarient
比如aosp_deb-userdebug,ProductName是aosp,DeviceName是deb，BuildVarient是userdebug。
在我印象中，在2.3之前必須按照這種格式定義lunch菜單，系統(tǒng)會(huì)根據(jù)這個(gè)這里的定義來(lái)推斷Target_Device的值。但是由于現(xiàn)在我們可以在Makefile中指定Product_Device這個(gè)變量的值，然后會(huì)根據(jù)Product_Device的值去推斷Target_Device的值，所以現(xiàn)在也可以不按照這種格式來(lái)定義lunch菜單了。
還有一個(gè)tips就是:
在Makefile中，類似Target_XXX這種格式的變量，都是編譯框架根據(jù)別的變量自動(dòng)生成的，所以一般我們不要再M(fèi)akefile中更改Target_XXX這種形式的變量
Product_XXX這種形式的變量是編譯系統(tǒng)提供給我們來(lái)修改的，我們可以對(duì)Prodcut_XXX這種形式的變量賦值。比如Product_Device := flo,編譯框架會(huì)根據(jù)Product_Device的值來(lái)生成Target_Device的值。
