Android編譯系統(tǒng)-上

接下來準(zhǔn)備把以前寫的Android編譯系統(tǒng)方面的資料整理成MarkDown.

這次Android編譯系統(tǒng)的代碼基于Android 6.0.

在整體來看Android編譯系統(tǒng)的時候,有兩個概念必須要十分清楚:Product和Device.

Product產(chǎn)品

不同的人對于產(chǎn)品的理解不一樣,對于設(shè)計人員來講,不同的產(chǎn)品對應(yīng)著不同的外觀,不同的尺寸,不同的材質(zhì)。但是對于Android來講,產(chǎn)品就是不同模塊的組合。每一個模塊由一個Android.mk編譯。模塊分為三類:

  1. 基礎(chǔ)模塊
比如AMS,PMS和Binder等都是基礎(chǔ)模塊,這些模塊都是必須要編譯的,否則Android無法啟動
  1. 可選的基礎(chǔ)模塊

    比如packages/apps下面的應(yīng)用

  2. 項目私有模塊

大部分是和硬件特性相關(guān)的模塊,比如雙攝像頭,指紋識別等。

我們一般都是根據(jù)足以讓用戶區(qū)分的硬件特性來定義產(chǎn)品,比如小米5和小米6是兩款產(chǎn)品,他們擁有不同的外觀設(shè)計,不同的硬件規(guī)格,比如小米5是單攝像頭,小米6是雙攝像頭,他們的CPU也不一樣,他們的外觀和材質(zhì)也不一樣。這些不同的硬件feature軟件上就對應(yīng)不同的模塊,模塊的不同構(gòu)成了產(chǎn)品的不同。

Device設(shè)備

同一個產(chǎn)品可能有不同的設(shè)備,比如小米5會有全網(wǎng)通版本,移動版本,電信版本等。這些不同的版本在軟件概念上就對應(yīng)不同的Device。雖然他們都叫小米5,但是由于硬件板級上的不同,造成了不同的Device.

我們編譯出來的img,最終都要燒到對應(yīng)的板子上,也就是對應(yīng)的Device上。那么我們在編譯過程中怎么確定我們正在編譯的這個Rom是對應(yīng)哪個Device呢?答案就是Target_Device這個變量,這是在編譯過程中非常重要的一個變量,該變量決定了我們的img最終可以燒寫到哪個Device上。

所以總結(jié)如下:

  • Product決定了這編譯過程中都有哪些模塊需要編譯
  • Device決定了我們編譯出來的img可以燒寫到哪些設(shè)備上。

既然Target_Device這么重要,我們就來看一下編譯系統(tǒng)是如何確定Target_Device的值得。

根據(jù)Android編譯規(guī)范,我們的編譯過程是從 source build/envsteup.sh開始的。
我們看一下這個envsetup.sh都做了哪些事情:

  • 定義了很多函數(shù),比如mm,lunch等,也就是說只有在執(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這個文件。

這個vendorsetup.sh這個文件是做什么用的呢?
所有的vendorsetup.sh幾乎都有這么一句類似的話
add_lunch_combo aosp_deb-userdebug,這句話的作用是把aosp_deb-userdebug加入到lunch菜單中。

我們在輸入lunch命令之后,會出現(xiàn)一個編譯菜單,比如:

  1. aosp_x86_64-eng
  2. aosp_deb-userdebug
  3. aosp_flo-userdebug

一般這個編譯菜單格式固定:ProductName_DeviceName-BuildVarient
比如aosp_deb-userdebug,ProductName是aosp,DeviceName是deb,BuildVarient是userdebug。

在我印象中,在2.3之前必須按照這種格式定義lunch菜單,系統(tǒng)會根據(jù)這個這里的定義來推斷Target_Device的值。但是由于現(xiàn)在我們可以在Makefile中指定Product_Device這個變量的值,然后會根據(jù)Product_Device的值去推斷Target_Device的值,所以現(xiàn)在也可以不按照這種格式來定義lunch菜單了。

還有一個tips就是:

在Makefile中,類似Target_XXX這種格式的變量,都是編譯框架根據(jù)別的變量自動生成的,所以一般我們不要再Makefile中更改Target_XXX這種形式的變量

Product_XXX這種形式的變量是編譯系統(tǒng)提供給我們來修改的,我們可以對Prodcut_XXX這種形式的變量賦值。比如Product_Device := flo,編譯框架會根據(jù)Product_Device的值來生成Target_Device的值。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容