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 编译系统分析(二)
- 下一篇: error: invalid use o