覺得很值得越讀的好文章，備份一下。
來源:https://www.ibm.com/developerworks/cn/opensource/os-cn-android-build/
2018/3/5: 新增部分敘述不完整或錯誤敘述
2018/3/21: 新增快速build指定的image

前言

Android Build 系統是 Android 源碼的一部分。關於如何獲取 Android 源碼，請參照 Android Source 官方網站：

http://source.android.com/source/downloading.html。

Android Build 系統用來編譯 Android 系統，Android SDK 以及相關文檔。該系統主要由 Make 文件，Shell 腳本以及 Python 腳本組成，其中最主要的是 Make 文件。

眾所周知，Android 是一個開源的操作系統。Android 的源碼中包含了大量的開源項目以及許多的模塊。不同產商的不同設備對於 Android 系統的定製都是不一樣的。

如何將這些項目和模塊的編譯統一管理起來，如何能夠在不同的操作系統上進行編譯，如何在編譯時能夠支持面向不同的硬件設備，不同的編譯類型，且還要提供面向各個產商的定製擴展，是非常有難度的。

但 Android Build 系統很好的解決了這些問題，這裡面有很多值得我們開發人員學習的地方。

對於 Android 平台開發人員來說，本文可以幫助你熟悉你每天接觸到的構建環境。

對於其他開發人員來說，本文可以作為一個 GNU Make 的使用案例，學習這些成功案例，可以提升我們的開發經驗。

概述

Build 系統中最主要的處理邏輯都在 Make 文件中，而其他的腳本文件只是起到一些輔助作用，由於篇幅所限，本文只探討 Make 文件中的內容。

整個 Build 系統中的 Make 文件可以分為三類：

第一類是 Build 系統核心文件，此類文件定義了整個 Build 系統的框架，而其他所有 Make 文件都是在這個框架的基礎上編寫出來的。

圖 1 是 Android 源碼樹的目錄結構，Build 系統核心文件全部位於 /build/core（本文所提到的所有路徑都是以 Android 源碼樹作為背景的，「/」指的是源碼樹的根目錄，與文件系統無關）目錄下。

圖 1. Android 源碼樹的目錄結構

第二類是針對某個產品（一個產品可能是某個型號的手機或者平板電腦）的 Make 文件，這些文件通常位於 device 目錄下，該目錄下又以公司名以及產品名分為兩級目錄，圖 2 是 device 目錄下子目錄的結構。對於一個產品的定義通常需要一組文件，這些文件共同構成了對於這個產品的定義。例如，/device/sony/it26 目錄下的文件共同構成了對於 Sony LT26 型號手機的定義。

圖 2. device 目錄下子目錄的結構

第三類是針對某個模塊（關於模塊後文會詳細討論）的 Make 文件。整個系統中，包含了大量的模塊，每個模塊都有一個專門的 Make 文件，這類文件的名稱統一為「Android.mk」，該文件中定義了如何編譯當前模塊。Build 系統會在整個源碼樹中掃瞄名稱為「Android.mk」的文件並根據其中的內容執行模塊的編譯。

編譯 Android 系統

執行編譯

Android 系統的編譯環境目前只支持 Ubuntu 以及 Mac OS 兩種操作系統。關於編譯環境的構建方法請參見以下路徑：http://source.android.com/source/initializing.html

在完成編譯環境的準備工作以及獲取到完整的 Android 源碼之後，想要編譯出整個 Android 系統非常的容易：

打開控制台之後轉到 Android 源碼的根目錄，然後執行如清單 1 所示的三條命令即可（"$"是命令提示符，不是命令的一部分。）：

完整的編譯時間依賴於編譯主機的配置，在筆者的 Macbook Pro（OS X 10.8.2, i7 2G CPU，8G RAM, 120G SSD）上使用 8 個 Job 同時編譯共需要一個半小時左右的時間。

清單 1. 編譯 Android 系統

這三行命令的說明如下：

第一行命令「source build/envsetup.sh」引入了 build/envsetup.sh腳本。該腳本的作用是初始化編譯環境，並引入一些輔助的 Shell 函數，這其中就包括第二步使用 lunch 函數。

除此之外，該文件中還定義了其他一些常用的函數，它們如表 1 所示：

表 1. build/envsetup.sh 中定義的常用函數

第二行命令「lunch full-eng」是調用 lunch 函數，並指定參數為「full-eng」。lunch 函數的參數用來指定此次編譯的目標設備以及編譯類型。在這裡，這兩個值分別是「full」和「eng」。「full」是 Android 源碼中已經定義好的一種產品，是為模擬器而設置的。而編譯類型會影響最終系統中包含的模塊，關於編譯類型將在表 7 中詳細講解。

如果調用 lunch 函數的時候沒有指定參數，那麼該函數將輸出列表以供選擇，該列表類似圖 3 中的內容（列表的內容會根據當前 Build 系統中包含的產品配置而不同，具體參見後文「添加新的產品」），此時可以通過輸入編號或者名稱進行選擇。

圖 3. lunch 函數的輸出

第三行命令「make -j8」才真正開始執行編譯。make 的參數「-j」指定了同時編譯的 Job 數量，這是個整數，該值通常是編譯主機 CPU 支持的並發線程總數的 1 倍或 2 倍（例如：在一個 4 核，每個核支持兩個線程的 CPU 上，可以使用 make -j8 或 make -j16）。在調用 make 命令時，如果沒有指定任何目標，則將使用默認的名稱為「droid」目標，該目標會編譯出完整的 Android 系統鏡像。

Build 結果的目錄結構

所有的編譯產物都將位於 /out 目錄下，該目錄下主要有以下幾個子目錄：

• /out/host/：該目錄下包含了針對主機的 Android 開發工具的產物。即 SDK 中的各種工具，例如：emulator，adb，aapt 等。
• /out/target/common/：該目錄下包含了針對設備的共通的編譯產物，主要是 Java 應用代碼和 Java 庫。
• /out/target/product/<product_name>/：包含了針對特定設備的編譯結果以及平台相關的 C/C++ 庫和二進制文件。其中，<product_name>是具體目標設備的名稱。
• /out/dist/：包含了為多種分發而準備的包，通過「make disttarget」將文件拷貝到該目錄，默認的編譯目標不會產生該目錄。

Build 生成的鏡像文件

Build 的產物中最重要的鏡像文件，它們都位於 /out/target/product/<product_name>/ 目錄下。

這些鏡像文件是：

• system.img：包含了 Android OS 的系統文件，庫，可執行文件以及預置的應用程序，將被掛載到根分區，描述的是設備上的system分區，即/system目錄。
• ramdisk.img：在啟動時將被 Linux 內核掛載為只讀分區，它包含了 /init 文件和一些配置文件。它用來掛載其他系統鏡像、文件系統，並啟動 init 進程。
• userdata.img：將被掛載為 /data，包含了應用程序相關的數據以及和用戶相關的數據。
• boot.img：包含有Kernel及其啟動參數、Ramdisk，以及可選的BootLoader第二階段。
• recovery.img：設備進入recovery模式時所加載的鏡像，相當於除正常啟動系統的第二系統，此系統用來更新正常系統，即刷機。

簡單來講就是：
BOOT： boot.img，Linux kernel (within normal ramdisk)
MISC： bootloader message struct
RECOVERY： recovery.img，Linux kernel (within recovery ramdisk)
SYSTEM： system.img
DATA： userdata.img
CACHE： some cache files

Recovery的工作需要整個軟件平台的配合，從架構角度看，有三個部分：
1) Main system：用boot.img啟動的Linux系統，Android的正常工作模式。
2) Recovery：用recovery.img啟動的Linux系統，主要是運行Recovery程序。
3) Bootloader：除了加載、啟動系統，還會通過讀取flash的MISC分區獲得來自Main system和Recovery的消息，並以此決定做何種操作

快速Build指定的img

快速編譯system.img，可以使用這個命令：
#make systemimage

快速編譯boot.img，可以使用以下命令:
#make bootimage

快速編譯userdata.img，可以使用以下命令:
# make userdataimage-nodeps

Make 文件說明

整個 Build 系統的入口文件是源碼樹根目錄下名稱為「Makefile」的文件，當在源代碼根目錄上調用 make 命令時，make 命令首先將讀取該文件。

Makefile 文件的內容只有一行：「include build/core/main.mk」。該行代碼的作用很明顯：包含 build/core/main.mk 文件。在 main.mk 文件中又會包含其他的文件，其他文件中又會包含更多的文件，這樣就引入了整個 Build 系統。

這些 Make 文件間的包含關係是相當複雜的，圖 3 描述了這種關係，該圖中黃色標記的文件（且除了 $開頭的文件）都位於 build/core/ 目錄下。

圖 4. 主要的 Make 文件及其包含關係

表 2 總結了圖 4 中提到的這些文件的作用：

表 2. 主要的 Make 文件的說明

Android 源碼中包含了許多的模塊，模塊的類型有很多種，例如：Java 庫，C/C++ 庫，APK 應用，以及可執行文件等 。並且，Java 或者 C/C++ 庫還可以分為靜態的或者動態的，庫或可執行文件既可能是針對設備（本文的「設備」指的是 Android 系統將被安裝的設備，例如某個型號的手機或平板）的也可能是針對主機（本文的「主機」指的是開發 Android 系統的機器，例如裝有 Ubuntu 操作系統的 PC 機或裝有 MacOS 的 iMac 或 Macbook）的。不同類型的模塊的編譯步驟和方法是不一樣，為了能夠一致且方便的執行各種類型模塊的編譯，在 config.mk 中定義了許多的常量，這其中的每個常量描述了一種類型模塊的編譯方式，這些常量有：

• BUILD_HOST_STATIC_LIBRARY
• BUILD_HOST_SHARED_LIBRARY
• BUILD_STATIC_LIBRARY
• BUILD_SHARED_LIBRARY
• BUILD_EXECUTABLE
• BUILD_HOST_EXECUTABLE
• BUILD_PACKAGE
• BUILD_PREBUILT
• BUILD_MULTI_PREBUILT
• BUILD_HOST_PREBUILT
• BUILD_JAVA_LIBRARY
• BUILD_STATIC_JAVA_LIBRARY
• BUILD_HOST_JAVA_LIBRARY

通過名稱大概就可以猜出每個變量所對應的模塊類型。（在模塊的 Android.mk 文件中，只要包含進這裡對應的常量便可以執行相應類型模塊的編譯。對於 Android.mk 文件的編寫請參見後文：「添加新的模塊」。）

這些常量的值都是另外一個 Make 文件的路徑，詳細的編譯方式都是在對應的 Make 文件中定義的。這些常量和 Make 文件的是一一對應的，對應規則也很簡單：常量的名稱是 Make 文件的文件名除去後綴全部改為大寫然後加上「BUILD_」作為前綴。例如常量 BUILD_HOST_PREBUILT 的值對應的文件就是 host_prebuilt.mk。

這些 Make 文件的說明如表 3 所示：

表 3. 各種模塊的編譯方式的定義文件

不同類型的模塊的編譯過程會有一些相同的步驟，例如：編譯一個 Java 庫和編譯一個 APK 文件都需要定義如何編譯 Java 文件。因此，表 3 中的這些 Make 文件的定義中會包含一些共同的代碼邏輯。為了減少代碼冗餘，需要將共同的代碼復用起來，復用的方式是將共同代碼放到專門的文件中，然後在其他文件中包含這些文件的方式來實現的。這些包含關係如圖 5 所示。由於篇幅關係，這裡就不再對其他文件做詳細描述（其實這些文件從文件名稱中就可以大致猜出其作用）。

圖 5. 模塊的編譯方式定義文件的包含關係

Make 目標說明

make /make droid

如果在源碼樹的根目錄直接調用「make」命令而不指定任何目標，則會選擇默認目標：「droid」（在 main.mk 中定義）。因此，這和執行「make droid」效果是一樣的。

droid 目標將編譯出整個系統的鏡像。從源代碼到編譯出系統鏡像，整個編譯過程非常複雜。這個過程並不是在 droid 一個目標中定義的，而是 droid 目標會依賴許多其他的目標，這些目標的互相配合導致了整個系統的編譯。

圖 6 描述了 droid 目標所依賴的其他目標：

圖 6. droid 目標所依賴的其他 Make 目標

圖 6 中這些目標的說明如表 4 所示：

表 4. droid 所依賴的其他 Make 目標的說明

其他目標

Build 系統中包含的其他一些 Make 目標說明如表 5 所示：

表 5. 其他主要 Make 目標

在 Build 系統中添加新的內容

添加新的產品

當我們要開發一款新的 Android 產品的時候，我們首先就需要在 Build 系統中添加對於該產品的定義。

在 Android Build 系統中對產品定義的文件通常位於 device 目錄下（另外還有一個可以定義產品的目錄是 vender 目錄，這是個歷史遺留目錄，Google 已經建議不要在該目錄中進行定義，而應當選擇 device 目錄）。device 目錄下根據公司名以及產品名分為二級目錄，這一點我們在概述中已經提到過。

通常，對於一個產品的定義通常至少會包括四個文件：AndroidProducts.mk，產品版本定義文件，BoardConfig.mk 以及 verndorsetup.sh。下面我們來詳細說明這幾個文件。

• AndroidProducts.mk：該文文件中的內容很簡單，其中只需要定義一個變量，名稱為「PRODUCT_MAKEFILES」，該變量的值為產品版本定義文件名的列表，例如：

• 產品版本定義文件：顧名思義，該文件中包含了對於特定產品版本的定義。該文件可能不只一個，因為同一個產品可能會有多種版本（例如，面向中國地區一個版本，面向美國地區一個版本）。該文件中可以定義的變量以及含義說明如表 6 所示：

表 6. 產品版本定義文件中的變量及其說明

通常情況下，我們並不需要定義所有這些變量。Build 系統的已經預先定義好了一些組合，它們都位於 /build/target/product 下，每個文件定義了一個組合，我們只要繼承這些預置的定義，然後再覆蓋自己想要的變量定義即可。例如：

• BoardConfig.mk：該文件用來配置硬件主板，它其中定義的都是設備底層的硬件特性。例如：該設備的主板相關信息，Wifi 相關信息，還有 bootloader，內核，radioimage 等信息。對於該文件的示例，請參看 Android 源碼樹已經有的文件。
• vendorsetup.sh：該文件中作用是通過 add_lunch_combo 函數在 lunch 函數中添加一個菜單選項。該函數的參數是產品名稱加上編譯類型，中間以「-」連接，例如：add_lunch_combo full_lt26-userdebug。/build/envsetup.sh 會掃瞄所有 device 和 vender 二 級目 錄下的名稱 為"vendorsetup.sh"文件，並根據其中的內容來確定 lunch 函數的 菜單選項。

在配置了以上的文件之後，便可以編譯出我們新添加的設備的系統鏡像了。

首先，調用「source build/envsetup.sh」該命令的輸出中會看到 Build 系統已經引入了剛剛添加的 vendorsetup.sh 文件。

然後再調用「lunch」函數，該函數輸出的列表中將包含新添加的 vendorsetup.sh 中添加的條目。然後通過編號或名稱選擇即可。

最後，調用「make -j8」來執行編譯即可。

添加新的模塊

關於「模塊」的說明在上文中已經提到過，這裡不再贅述。

在源碼樹中，一個模塊的所有文件通常都位於同一個文件夾中。為了將當前模塊添加到整個 Build 系統中，每個模塊都需要一個專門的 Make 文件，該文件的名稱為「Android.mk」。Build 系統會掃瞄名稱為「Android.mk」的文件，並根據該文件中內容編譯出相應的產物。

需要注意的是：在 Android Build 系統中，編譯是以模塊（而不是文件）作為單位的，每個模塊都有一個唯一的名稱，一個模塊的依賴對象只能是另外一個模塊，而不能是其他類型的對象。對於已經編譯好的二進制庫，如果要用來被當作是依賴對象，那麼應當將這些已經編譯好的庫作為單獨的模塊。對於這些已經編譯好的庫使用 BUILD_PREBUILT 或 BUILD_MULTI_PREBUILT。例如：當編譯某個 Java 庫需要依賴一些 Jar 包時，並不能直接指定 Jar 包的路徑作為依賴，而必須首先將這些 Jar 包定義為一個模塊，然後在編譯 Java 庫的時候通過模塊的名稱來依賴這些 Jar 包。

下面，我們就來講解 Android.mk 文件的編寫：

Android.mk 文件通常以以下兩行代碼作為開頭：

這兩行代碼的作用是：

1. 設置當前模塊的編譯路徑為當前文件夾路徑。
2. 清理（可能由其他模塊設置過的）編譯環境中用到的變量。

為了方便模塊的編譯，Build 系統設置了很多的編譯環境變量。要編譯一個模塊，只要在編譯之前根據需要設置這些變量然後執行編譯即可。它們包括：

• LOCAL_SRC_FILES：當前模塊包含的所有源代碼文件。
• LOCAL_MODULE：當前模塊的名稱，這個名稱應當是唯一的，模塊間的依賴關係就是通過這個名稱來引用的。
• LOCAL_C_INCLUDES：C 或 C++ 語言需要的頭文件的路徑。
• LOCAL_STATIC_LIBRARIES：當前模塊在靜態鏈接時需要的庫的名稱。
• LOCAL_SHARED_LIBRARIES：當前模塊在運行時依賴的動態庫的名稱。
• LOCAL_CFLAGS：提供給 C/C++ 編譯器的額外編譯參數。
• LOCAL_JAVA_LIBRARIES：當前模塊依賴的 Java 共享庫。
• LOCAL_STATIC_JAVA_LIBRARIES：當前模塊依賴的 Java 靜態庫。
• LOCAL_PACKAGE_NAME：當前 APK 應用的名稱。
• LOCAL_CERTIFICATE：簽署當前應用的證書名稱。
• LOCAL_MODULE_TAGS：當前模塊所包含的標籤，一個模塊可以包含多個標籤。標籤的值可能是 debug, eng, user，development 或者 optional。其中，optional 是默認標籤。標籤是提供給編譯類型使用的。不同的編譯類型會安裝包含不同標籤的模塊，關於編譯類型的說明如表 7 所示：

表 7. 編譯類型的說明

表 3 中的文件已經定義好了各種類型模塊的編譯方式。所以要執行編譯，只需要引入表 3 中對應的 Make 文件即可（通過常量的方式）。例如，要編譯一個 APK 文件，只需要在 Android.mk 文件中，加入「include $(BUILD_PACKAGE)

除此以外，Build 系統中還定義了一些便捷的函數以便在 Android.mk 中使用，包括：

• $(call my-dir)：獲取當前文件夾路徑。
• $(call all-java-files-under, <src>)：獲取指定目錄下的所有 Java 文件。
• $(call all-c-files-under, <src>)：獲取指定目錄下的所有 C 語言文件。
• $(call all-Iaidl-files-under, <src>) ：獲取指定目錄下的所有 AIDL 文件。
• $(call all-makefiles-under, <folder>)：獲取指定目錄下的所有 Make 文件。
• $(call intermediates-dir-for, <class>, <app_name>, <host or target>, <common?> )：獲取 Build 輸出的目標文件夾路徑。

清單 2 和清單 3 分別是編譯 APK 文件和編譯 Java 靜態庫的 Make 文件示例：

清單 2. 編譯一個 APK 文件

清單 3. 編譯一個 Java 的靜態庫

結束語

整個 Build 系統包含了非常多的內容，由於篇幅所限，本文只能介紹其中最主要內容。

由於 Build 系統本身也是在隨著 Android 平台不斷的開發過程中，所以不同的版本其中的內容和定義可能會發生變化。網絡上關於該部分的資料很零碎，並且很多資料中的一些內容已經過時不再適用，再加上缺少官方文檔，所以該部分的學習存在一定的難度。

這就要求我們要有很強的代碼閱讀能力，畢竟代碼是不會說謊的。 要知道，對於我們這些開發人員來說，源代碼就是我們最忠實的朋友。 Use the Source,Luke!