Android 編譯系統分析

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編譯系統。

Android 架構

這幾天又惡補了一下Makefile的規則，以下是摘自http://www.360doc.com/content/10/0409/13/502243_22235679.shtml

的一段，強烈推薦對Makefile感興趣的同學讀一下，好像有PDF下，叫做《跟我一起寫Makefile》可以加深對編譯過程的瞭解。Linux有了make工具，就可以藐視Windows的Visual Studio的IDE了。

     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分析

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的編譯。

下一篇博文會講述一個system.img的整個產生過程。