Android 编译系统分析(三)
自Android開源以來，引起了嵌入式行業一股熱潮，很多嵌入式開發者表示對Android有很強的興趣，并下載Android源碼進行編譯和移植。Android源碼的巨大（repo下來，大概2G）給人以Android相當復雜的錯覺。本文從Android編譯系統的角度，讓大家了解Android其實也是很純真的。
Android編譯系統（build system）集中于Android源碼下的build/core下，在Android2.2中，共有56個*.mk文件。另外還有一些shell腳本。可謂相當龐大，為什么google將它的編譯系統弄的如此復雜龐大呢？在build/core下的build-system.html中有以下講述：
1.???? Multiple Targets
2.???? Non-Recursive Make
3.???? Rapid Compile-Test Cycles
4.???? Both Environment and Config File Based Settings
5.???? Object File Directory / make clean
基于以上目標，google Android開發人員將Android build system做成了現在的樣子。在android.git.kernel.org上可以看到android build system作為一個項目一直在更新，因此，對于其編譯系統的維護也是一個相當復雜的項目。為了實現Android在除ARM平臺（x86、mips甚至一個全新的架構）上移植，必須深入了解Android編譯系統。
Makefile的規則：
target … : prerequisites …
command
…
…
target也就是一個目標文件，可以是Object File，也可以是執行文件。還可以是一個標簽（Label），對于標簽這種特性，在后續的“偽目標”章節中會有敘述。
prerequisites就是，要生成那個target所需要的文件或是目標。
command也就是make需要執行的命令。（任意的Shell命令）
這是一個文件的依賴關?系，也就是說，target這一個或多個的?目標文件依賴于prerequisites中的文件，其生成規則定義在command中。?說白一點就是說，prerequisites中如果有一個以上的文件比target文件要新的話，command所定義的命令就會被執行。這就是?Makefile的規則。也就是Makefile中最核心的內容。
正如上面作者所述，上面是Makefile中最核心的內容，Android編譯系統符合GNU make的標準，當然這也是Android?編譯系統最核心的內容。
Android編譯系統的架構：
分析Android編譯系統，你會發現，Android編譯系統完成的并不僅僅是對目標（主機）系統二進制文件、java應用程序的編譯、鏈接、打包等，而且還有包括生成各種依賴關系、確保某個模塊的修改引起相依賴的文件的重新編譯鏈接，甚至還包括目標文件系統的生成，配置文件的生成等，因此Android編譯系統具有支持多架構（linux-x86、windows、arm等）、多語言（匯編、C、C++、Java等）、多目標、多編譯方式。這些目標和結構決定其架構也很重要。
Android編譯系統集中于build/core下，幾個很重要的*.mk文件如下：
main.mk(主控Makefile)
base_rules.mk(對一些Makefile的變量規則化)
config.mk（關于編譯參數、編譯命令的一些配置）
definations.mk（定義了很多編譯系統中用到的宏，相當于函數庫）
Makefile（這個Makefile特指build/core下的Makefile，此文件主要控制生成system.img,ramdisk.img,userdata.img,以及recorvery image，sdk等）
Binary.mk(控制如何生成目標文件)
Clear_vars.mk（清除編譯系統中用到的臨時變量）
Combo/linux-arm.mk(控制如何生成linux-arm二進制文件，包括ARM相關的編譯器，編譯參數等的設置)
Copy_headers.mk（將頭文件拷貝到指定目錄）
分散于各個目錄下的Android.mk(控制生成局部模塊的源碼，名稱所需頭文件路徑，依賴庫等特殊選項)
Build/envsetup.mk(編譯環境初始化，定義一些實用的shell函數，方便編譯使用)
以上幾個主要的文件，可以按照社會分工打一個比方：
Main.mk是總統，是老大，承擔了很多工作。
Makefile是副總統，輔佐老大Main.mk
Base_rules.mk是交警，讓不規則的東西，變得規則。
Config.mk是省長，規定了各個人民群眾該如何行事
Definations.mk是圖書館管理員
Binary.mk應該屬于村長了，規定每個人該如何行事
Clear_vars.mk應該屬于保潔公司的工人吧
Combo/linux-arm.mk應該屬于社會公民了，他決定自己該如何去做
Main.mk分析
Main.mk主要包含如下幾個部分的內容
1.?????? SHELL設置
2.???????編譯環境配置
3.???????編譯環境檢查
4.???????包含必要的宏
5.???????根據make參數設置編譯時的變量
6.???????包含需要編譯的Android.mk
7.???????設置編譯系統Target：prerequisites?控制整個編譯流程
下面對上面幾點進行必要解釋：
有了前面小節對Android編譯系統架構的分析，如果需要修改Android編譯系統，就可以不至于盲目找問題，修改代碼了。今天分析下main.mk，看它能為我們Android編譯提供什么有價值的信息，以及如何自己定制我們的Android編譯系統。
Main.mk的第一句就根據ANDROID_BUILD_SHELL來包裹編譯系統用到的Shell，如果我們不想使用bash，而想使用sh，那么就可以在它前面寫上ANDROID_BUILD_SHELL := /bin/sh，或者在build/envsetup.sh中添加相關定義。
定義完SHELL之后，就是對MAKE_VERSION的檢查，然后定義了默認的編譯目標droid!
如果我們敲入make之后，不加任何參數，默認的目標就是droid。注意雖然后面的include $(BUILD_SYSTEM)/config.mk寫在默認目標droid依賴之后，但其和之后的語句都是要執行的，這是Makefile的語法決定的。
后面會include config.mk cleanbuild.mk對編譯系統進行必要的配置。后面就是對編譯環境的檢查，包括是否大小寫敏感、路徑檢查、java版本檢查、javac版本檢查。Android對編譯環境的檢查如果符合條件，在下次編譯的時候，不會再次進行檢查。
檢查完版本之后，會包含進definations.mk，如前所述，definations.mk中定義了很多編譯系統中用到的宏，這些宏在編譯時需要經常調用，因此在編譯的很靠前的階段，就將之包含了進來。
然后就是針對make時傳入的編譯類型（eng user userdebug showcommands等）進行編譯配置，這些配置會影響到最終編譯目標所包括的模塊。對于eng user userdebug sdk win_sdk tests等編譯目標的區別，讀者可以通過查看main.mk的代碼找出其中到底有什么不同。
此處略去部分部分不重要的內容，直接跳到
Ifeq($(SDK_ONLY),true)處，大概368行附近，這個判斷語句一直到這個語句塊結束，都是對subdirs變量的設置，subdirs變量決定了哪些子文件夾最終被編譯。
在后面的subdir_makefiles變量的設置，決定了哪些Android.mk被編譯。緊接著include $(subdir_makefiles)就會添加所有這些Android.mk文件的依賴。這其中包含了droid的依賴，后面我們會發現。
然后就會根據這些Makefile，找出所有需要編譯的模塊（module），以及進行必要的分類（eng_MODULES/debug_MODULES/tests_MODULES等、modules_to_check/modules_to_install等），用以區別對待。
緊接著是定義了一系列的隱含目標：prebuilt、all_copied_headers、files、checkbuild、ramdisk、systemtallball、userdataimage、userdatatarball、bootimg、droidcore等。最重要的一點，是會發現droid依賴于droidcore,而droidcore依賴于
droidcore: files /
systemimage /
$(INSTALLED_BOOTIMAGE_TARGET) /
$(INSTALLED_RECOVERYIMAGE_TARGET) /
$(INSTALLED_USERDATAIMAGE_TARGET) /
$(INSTALLED_FILES_FILE)
正是這幾個依賴項，控制著整個android的編譯
總結
以上是生活随笔為你收集整理的Android 编译系统分析(三)的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Android 编译系统分析(二)
- 下一篇： android sina oauth2.