android44源碼編譯
android源碼中有著許多的源代碼，其中有c和c++編寫的也有java編寫，這些代碼需要通過重新編譯後才能在android機器上運行的！當然你修改源碼，改完源碼後還是需要對源碼進行編譯的編譯的！android系統源碼的整體編譯需要很長時間，所以一般否是分開來編譯的！這樣縮短了編譯的等待時間，而且也實現了不同人對不同板塊代碼的修改和編譯的分工了！
2. 如何定製android源碼的編譯選項
現僅就工作遇到的問題做個總結。所用硬體平台為amlogic stvm3。---------------------------------------------------------------------------關於版本號：文件build/core/version_defaults.mk用來檢查一些跟版本相關的變數是否定義；如果未定義，則使用默認值。這些變數包括 PLATFORM_VERSION # 如 2.2.5 PLATFORM_SDK_VERSION # 8, 對應2.2.5 PLATFORM_VERSION_CODENAME # REL，即發行版 DEFAULT_APP_TARGET_SDK # 同SDK_VERSION或VERSION_CODENAME BUILD_ID # 默認為UNKNOWN BUILD_NUMBER # 默認eng.$(USER).$(shell date +%Y%m%d.%H%M%S)的形式。 version_defaults.mk首先包含進build_id.mk。用戶應當配置build_id.mk，而不應該改動version_defaults.mk文件。然後檢查上述變數，如未定義則賦值默認值。---------------------------------------------------------------------------關於調試功能(adb)的開啟編譯android源碼之前總是要先運行build/envsetup.sh，以初始化一些常用命令（實際上是bash的函數，如add_lunch_combo）。其中也從以下文件中引入了一些編譯設置： device/${CHIPSET_VENDOR}/vendorsetup.sh我們這里使用的CHIPSET_VENDOR為amlogic。比如我們有文件device/amlogic/vendorsetup.sh，內容為"產品名-編譯類型(flavor)"列表（稱為combo），如下： add_lunch_combo m1ref-eng add_lunch_combo m1ref-user add_lunch_combo m2ref-eng add_lunch_combo m2ref-user add_lunch_combo stvm3-eng add_lunch_combo stvm3-user其中，m1ref和stvm3是產品名（作前綴），後面為編譯類型。除此前綴外可選的combo值有： eng, user, userdebug, tests。（參考文件build/core/main.mk中對於變數TARGET_BUILD_VARIANT的篩查條件）我們可以修改vendorsetup.sh文件，來改變為特定設備編譯的結果。以下是各個編譯類型的特點： eng: 工程模式，用於平台級的調試，是默認的編譯類型。
3. 怎麼在ubuntu上編譯android源碼
步驟一：
安裝Ubuntu系統。我們既可以通過虛擬機的方式安裝Ubuntu，也可以直接在電腦上安裝，為了獲得更好的linux操作體驗，我建議直接在電腦上面安裝Ubuntu，我在自己電腦上安裝了win10和Ubunut Server14.04雙系統，使用的時候可以根據自己的需要隨時切換系統，非常方便。關於如何搭建雙系統，網上有很多教程，我就不在此敘述了，但是我想說明的一點是在安裝Ununtu的時候，分配給Ubuntu的磁碟空間一定要盡可能大一點，至少60G，我分配了105G，編譯完成之後還剩下50多G，也就是說差不多用了近50G的空間，所以安裝Ubuntu的時候一定得分配大一點的磁碟空間，不然編譯會因為空間不足而中斷。
步驟二：
搭建好Ubuntu系統之後，我們需要下載一份Android6.0的源碼，網上很多文章都介紹了如何通過repo的方式來下載源碼，但是通過這種方式下載速度可能並不是很理想，直接下載網路雲的Android6.0源碼，
因為Android6.0的源碼所佔空間非常大，所以上傳者把Android源碼分成了很多個文件，待全部下載完畢之後，我們可以通過命令把這些分開的文件合並為一個文件。
步驟三：
如果我們是在Windows上下載的源碼，那麼當我們打開Ubuntu之後，要做的第一件事請就是把Windows中的Android源碼拷貝到Ubuntu系統下面，我直接利用復制粘貼的方式將源碼拷貝到了Ubuntu的Home目錄下面，拷貝之後的目錄結構Home/android6_r1/各個分開的源碼文件。
步驟四：
合並這些被分開的源碼文件。我們按下鍵盤上的ctrl + alt + T打開控制台，通過cd命令進入到Home/android6_r1/目錄下面，然後執行命令：cat Android6_r1_* > M.tgz，不用多久，在Home/android6_r1/目錄下面就會生成一個新的文件——M.tgz，M.tgz就是合並之後的壓縮文件。
步驟五：
解壓步驟四生成的壓縮文件。同樣是在Home/android6_r1/目錄下面，我們在控制台執行命令：tar zxvf M.tgz，開始解壓。解壓的過程大概需要20分鍾左右的時間，請耐心等待。解壓好了之後，在Home/android6_r1/會生成一個mydroid的文件夾，這個文件夾就是Android源碼的根文件夾了，裡面有abi、devices、hardware、packages、sdk、art等文件夾和文件。
步驟六：
安裝編譯源碼所需要的軟體。在控制台中我們通過cd..命令退回到Unbuntu用戶的根目錄下，然後依次執行以下命令：
sudo apt-get update
sudo apt-get install openjdk-7-jdk
sudo update-alternatives --config java
sudo update-alternatives --config javac
以上命令每一條都必須分開單獨執行，目的是為了獲取1.7版本的jdk並設置環境變數。當我們安裝完Ubuntu之後可能會自帶一個jdk，但是如果用自帶的jdk編譯Android源碼很可能會提示jdk版本不符合要求的錯誤，因此我們需要重新下載1.7版本的jdk，我用openjdk-7-jdk編譯未出現任何問題。
接下來繼續執行以下命令，同樣每一行都是分開單獨執行的：
sudo apt-get install git gnupg flex bison gperf build-essential
sudo apt-get install zip curl libc6-dev libncurses5-dev:i386 x11proto-core-dev
sudo apt-get install libx11-dev:i386 libreadline6-dev:i386 libgl1-mesa-glx:i386
sudo apt-get install libgl1-mesa-dev g++-multilib mingw32 tofrodos
sudo apt-get install python-markdown libxml2-utils xsltproc zlib1g-dev:i386
sudo ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 /usr/lib/i386-linux-gnu/libGL.so
以上命令主要是安裝編譯源碼時需要用到的各種軟體，如果沒有安裝這些軟體，編譯的過程中會提示缺少必要的軟體而無法繼續編譯，因此，在正式編譯源碼之前，一定要先安裝這些軟體。
步驟七：
開始編譯。在控制台中通過cd命令進入到Home/android6_r1/mydroid/目錄下，然後執行命令：source build/envsetup.sh，導入編譯Android源碼所需的環境變數和其它參數。
步驟八：
在控制台中執行命令：lunch，運行命令之後會提示我們選擇編譯目標。這里我選擇的的默認目標，即aosp_arm_eng。
步驟九：
在控制台中執行命令：make -j8，開始編譯。注意，make -j8命令中的數字8和我們電腦的CPU核心數以及線程數有關系，一般這個數字的數值最大不能超過CPU線程數的2倍，例如我電腦的處理器是i5 6200U，為雙核四線程，因此編譯Android源碼的時候，我可以設置的最大工作線程數量為4 * 2 = 8。在執行make命令的時候我們應該根據自己的CPU參數設置合理的工作線程數值。
以上步驟執行完之後，就是一段非常漫長的等待了，我從中午十二點多開始編譯，一直到晚上九點多編譯完成，整個編譯過程耗時九個多小時，幸好我的運氣還不錯，編譯過程中沒有出現任何錯誤，只是中途意外中斷了一次，但是Android源碼是可以接著上次中斷的位置繼續編譯的，已經編譯的部分不會重復編譯，因此並未對我造成大的影響。同志們，我想說的是，編譯的過程中一定要有耐心喲！
整個源碼編譯完成之後，如果提示如下信息，那麼Congratulations, you are successful!!!
4. 編譯Android源碼和內核源碼的區別
Android源碼編譯之後生成的是ramdisk.img、system.img和userdata.img。而內核源碼編譯完成之後生成的是ZImage。在一般情況下Android源碼是不帶有內核源碼的，但是帶有一個鏡像，這樣在編譯完Android源碼之後就可以模擬器啟動了，如果要更換系統的內核，此時將高版本的內核源碼進行編譯生成ZImage然後替換Android系統的的鏡像。這樣使用模擬器啟動之後就可以查看內核是否已經被刷新。
請注意，android源碼和kernel源碼是分開下載的
編譯android源碼
進入source目錄下，執行make 即可。
編譯完成後，可以在源碼目錄的out/target/proct/generic/目錄下看到編譯好的ramdisk.img、system.img和userdata.img了。
編譯內核源碼
新建Kernel/goldfish，在這個目錄下進行編譯
5. 自己可以編譯安卓源碼嗎
用最新的Ubuntu 16.04,請首先確保自己已經安裝了Git.沒安裝的同學可以通過以下命令進行安裝:
sudo apt-get install git git config –global user.email 「[email protected]」 git config –global user.name 「test」
其中[email protected]為你自己的郵箱.
簡要說明
android源碼編譯的四個流程:1.源碼下載;2.構建編譯環境;3.編譯源碼;4運行.下文也將按照該流程講述.
源碼下載
由於某牆的原因,這里我們採用國內的鏡像源進行下載.
目前,可用的鏡像源一般是科大和清華的,具體使用差不多,這里我選擇清華大學鏡像進行說明.(參考:科大源,清華源)
repo工具下載及安裝
通過執行以下命令實現repo工具的下載和安裝
mkdir ~/binPATH=~/bin:$PATHcurl https://storage.googleapis.com/git-repo-downloads/repo > ~/bin/repochmod a+x ~/bin/repo
補充說明
這里,我來簡單的介紹下repo工具,我們知道AOSP項目由不同的子項目組成,為了方便進行管理,Google採用Git對AOSP項目進行多倉庫管理.在聊repo工具之前,我先帶你來聊聊多倉庫項目:
我們有個非常龐大的項目Pre,該項目由很多個子項目R1,R2,...Rn等組成,為了方便管理和協同開發,我們為每個子項目創立自己的倉庫,整個項目的結構如下:
這里寫圖片描述
執行完該命令後,再使用make命令繼續編譯.某些情況下,當你執行jack-admin kill-server時可能提示你命令不存在,此時去你去out/host/linux-x86/bin/目錄下會發現不存在jack-admin文件.如果我是你,我就會重新repo sync下,然後從頭來過.
錯誤三:使用emulator時,虛擬機停在黑屏界面,點擊無任何響應.此時,可能是kerner內核問題,解決方法如下:
執行如下命令:
通過使用kernel-qemu-armv7內核 解決模擬器等待黑屏問題.而-partition-size 1024 則是解決警告: system partion siez adjusted to match image file (163 MB >66 MB)
如果你一開始編譯的版本是aosp_arm-eng,使用上述命令仍然不能解決等待黑屏問題時,不妨編譯aosp_arm64-eng試試.
結束吧
到現在為止,你已經了解了整個android編譯的流程.除此之外,我也簡單的說明android源碼的多倉庫管理機制.下面,不妨自己動手嘗試一下.
6. 如何編輯和調試android源碼
在源碼中,存在idegen模塊,該模塊專門用來為idea工具生成系統源碼的project.
在開始編譯該模塊之前,首先確保你已經編譯過Android源碼了,如果沒有,可以參考上篇文章進行編譯.
和編譯普通的模塊一樣,我們用mmm命令編譯idegen.在開始編譯之前,檢查out/host/linux-x86/framework/目錄下是否存在idegen.jar文件,存在則說明你已經編譯過該模塊,否者,則需要編譯.執行如下命令即可:
soruce build/envsetup.sh
mmm development/tools/idegen/
sudo ./development/tools/idegen/idegen.sh123123
其中mmm development/tools/idegen/執行完成後會生成idegen.jar,而sodo ./development/tools/idegen/idegen.sh則會在源碼目錄下生成IEDA工程配置文件:android.ipr,android.iml及android.iws.
簡單的說明一下這三個文件的作用:
android.ipr:通常是保存工程相關的設置,比如編譯器配置,入口,相關的libraries等
android.iml:則是主要是描述了moles,比如moles的路徑,依賴關系等.
android.iws:則主要是包含了一些個人工作區的設置.
7. windows下如何編譯android源碼
如果沒記錯，windows下是沒法編譯android框架源代碼的
因為android是基於linux平台的，因此底層的很多東西都是基於linux系統的
如果只是單純的android應用程序，則可以在windows下開發編譯
只需要用Eclipse的adt插件加上windows下開發的Android SDK就行了。
8. 如何定製android源碼的編譯選項 amp;後期安裝
文件build/core/version_defaults.mk用來檢查一些跟版本相關的變數是否定義；如果未定義，則使用默認值。
這些變數包括
PLATFORM_VERSION # 如 2.2.5
PLATFORM_SDK_VERSION # 8, 對應2.2.5
PLATFORM_VERSION_CODENAME # REL，即發行版
DEFAULT_APP_TARGET_SDK # 同SDK_VERSION或VERSION_CODENAME
BUILD_ID # 默認為UNKNOWN
BUILD_NUMBER # 默認eng.$(USER).$(shell date +%Y%m%d.%H%M%S)的形式。
version_defaults.mk首先包含進build_id.mk。用戶應當配置build_id.mk，而不應該改動version_defaults.mk文件。然後檢查上述變數，如未定義則賦值默認值。
---------------------------------------------------------------------------
關於調試功能(adb)的開啟
編譯android源碼之前總是要先運行build/envsetup.sh，以初始化一些常用命令（實際上是bash的函數，如add_lunch_combo）。
其中也從以下文件中引入了一些編譯設置：
device/${CHIPSET_VENDOR}/vendorsetup.sh
我們這里使用的CHIPSET_VENDOR為amlogic。
比如我們有文件device/amlogic/vendorsetup.sh，內容為"產品名-編譯類型(flavor)"列表（稱為combo），如下：
add_lunch_combo m1ref-eng
add_lunch_combo m1ref-user
add_lunch_combo m2ref-eng
add_lunch_combo m2ref-user
add_lunch_combo stvm3-eng
add_lunch_combo stvm3-user
其中，m1ref和stvm3是產品名（作前綴），後面為編譯類型。
除此前綴外可選的combo值有： eng, user, userdebug, tests。
（參考文件build/core/main.mk中對於變數TARGET_BUILD_VARIANT的篩查條件）
我們可以修改vendorsetup.sh文件，來改變為特定設備編譯的結果。
以下是各個編譯類型的特點：
eng: 工程模式，用於平台級的調試，是默認的編譯類型。
待安裝的模塊tag有: eng, debug, user, development.
安裝不帶tag的非APK模塊；
所安裝應用由產品定義文件給出；
默認屬性: ro.secure=0, ro.deuggable=1, ro.kernel.android.checkjni=1
adbd默認開啟，adb以root身份運行。
user: 即最終用戶版;
待安裝的應用tag有: user
安裝不帶tag的非APK模塊；
所安裝應用由產品定義文件給出；
默認屬性有ro.secure=1, ro.debuggable=0；
默認關閉adbd服務（但可通過應用settings來打開，且adb以shell身份運行）；
userdebug: 與user類似，除了：
支持有限的調試功能；
待安裝的應用tag有:debug；
默認屬性有ro.secure=1, ro.debuggable=1；
默認打開adbd服務，adb以shell身份運行；
例如，由文件build/core/main.mk可以看出，當使用含有userdebug的combo值時，此文件中的臨時變數enable_target_debugging會保持為true，相應地，編譯過程會執行：
ADDITIONAL_DEFAULT_PROPERTIES += ro.debuggable=1 persist.service.adb.enable=1
這意味著目標系統中根目錄下的文件/default.prop文件(對應變數 INSTALLED_DEFAULT_PROP_TARGET )會含有以下行（參考文件build/core/Makefile）：
persist.service.adb.enable=1
由此，目標系統會默認開啟adbd服務，你就可以通過其它PC來連接目標系統了。
所以，如要默認開啟adbd服務，可在設備（如stvm3）定製文件device/amlogic/vendorsetup.sh中增加以下行：
add_lunch_combo stvm3-userdebug
這樣在執行bash的lunch函數時，選擇此combo就可以默認打開adbd服務（adb以shell身份運行）。
但是，即使adbd已經開啟，你仍可能無法通過網路連接到Android進行調試，這涉及到Android的二個屬性:
service.adb.tcp.port (優先順序高)
persist.adb.tcp.port (優先順序低)
註：可查看源碼文件system/core/adb/adb.c。
默認地，這兩個屬性值是5555。有兩種方法來設置此變數：
1）(永久性改變)在Android配置文件/init.rc或/init.$MANUFACTUROR.rc中添加一行：
setprop service.adb.tcp.port 5555
2）(臨時性改變)在命令行上（你可能需要先通過串口開一個終端）執行如下命令：
setprop service.adb.tcp.port 5555
檢查adbd是否支持通過網路鏈接Android：執行命令
netstat -l -n | grep ":5555"
如果有LISTEN狀態的輸出，則表示adbd支持網路模式 :) 。
9. android源碼怎麼編譯生成recovery.img
recovery.img生成過程
L630-L637 依賴關系
(From: build/core/Makefile)630 $(INSTALLED_RECOVERYIMAGE_TARGET): $(MKBOOTFS) $(MKBOOTIMG) $(MINIGZIP) /631 $(INSTALLED_RAMDISK_TARGET) /632 $(INSTALLED_BOOTIMAGE_TARGET) /633 $(recovery_binary) /634 $(recovery_initrc) $(recovery_kernel) /635 $(INSTALLED_2NDBOOTLOADER_TARGET) /636 $(recovery_build_prop) $(recovery_resource_deps) /637 $(RECOVERY_INSTALL_OTA_KEYS)
INSTALLED_RECOVERYIMAGE_TARGET 為我們的編譯目標：
584 INSTALLED_RECOVERYIMAGE_TARGET := $(PRODUCT_OUT)/recovery.img
它依賴很多其它目標：
1．MKBOOTFS, MINIGZIP, MKBOOTIMG，PC端工具軟體：（From build/core/config.mk）265 MKBOOTFS := $(HOST_OUT_EXECUTABLES)/mkbootfs$(HOST_EXECUTABLE_SUFFIX)266 MINIGZIP := $(HOST_OUT_EXECUTABLES)/minigzip$(HOST_EXECUTABLE_SUFFIX)267 MKBOOTIMG := $(HOST_OUT_EXECUTABLES)/mkbootimg$(HOST_EXECUTABLE_SUFFIX)
2．INSTALLED_RAMDISK_TARGET，標准根文件系統 ramdisk.img：
326 BUILT_RAMDISK_TARGET := $(PRODUCT_OUT)/ramdisk.img328 # We just build this directly to the install location.329 INSTALLED_RAMDISK_TARGET := $(BUILT_RAMDISK_TARGET) 3．INSTALLED_BOOTIMAGE_TARGET， 即boot.img,標准內核及標准根文件系統：362 INSTALLED_BOOTIMAGE_TARGET := $(PRODUCT_OUT)/boot.img
4. recovery_binary, Recovery可執行程序，源碼位於：bootable/recovery
590 recovery_binary := $(call intermediates-dir-for,EXECUTABLES,recovery)/recovery
5. recovery_initrc，recovery模式的init.rc, 位於 bootable/recovery/etc/init.rc
586 recovery_initrc := $(call include-path-for, recovery)/etc/init.rc
6. recovery_kernel, recovery 模式的kernel, 同標准內核
587 recovery_kernel := $(INSTALLED_KERNEL_TARGET) # same as a non-recovery system
7.INSTALLED_2NDBOOTLOADER_TARGET，我們不用。
8. recovery_build_prop， recovery 模式的build.prop, 同標准模式。589 recovery_build_prop := $(INSTALLED_BUILD_PROP_TARGET)
9. recovery_resource_deps， recovery 模式使用的res, 位於：recovery/custom/{proct_name}/res, 以及設備自定義部分（我們沒用到）
591 recovery_resources_common := $(call include-path-for, recovery)/custom/$(TARGET_PRODUCT)/res592 recovery_resources_private := $(strip $(wildcard $(TARGET_DEVICE_DIR)/recovery/res))593 recovery_resource_deps := $(shell find $(recovery_resources_common) 594 $(recovery_resources_private) -type f) 10. RECOVERY_INSTALL_OTA_KEYS, ota 密鑰：
618 # Generate a file containing the keys that will be read by the619 # recovery binary.620 RECOVERY_INSTALL_OTA_KEYS := /621 $(call intermediates-dir-for,PACKAGING,ota_keys)/keysL638-L655 准備內容
638 @echo ----- Making recovery image ------639 rm -rf $(TARGET_RECOVERY_OUT)640 mkdir -p $(TARGET_RECOVERY_OUT)641 mkdir -p $(TARGET_RECOVERY_ROOT_OUT)642 mkdir -p $(TARGET_RECOVERY_ROOT_OUT)/etc643 mkdir -p $(TARGET_RECOVERY_ROOT_OUT)/tmp
准備recovery目錄：out/target/proct/{proct_name}/recovery 及其子目錄：
./root
./root/etc
./root/tmp644 echo Copying baseline ramdisk...645 cp -R $(TARGET_ROOT_OUT) $(TARGET_RECOVERY_OUT)646 echo Modifying ramdisk contents...647 rm -rf $(TARGET_RECOVERY_ROOT_OUT)/res
從標准根文件系統拷貝所有文件， 刪除其res 目錄。
648 cp -f $(recovery_initrc) $(TARGET_RECOVERY_ROOT_OUT)/649 cp -f $(recovery_binary) $(TARGET_RECOVERY_ROOT_OUT)/sbin/ 拷貝recovery 模式的核心文件 init.rc 及 recovery 650 cp -rf $(recovery_resources_common) $(TARGET_RECOVERY_ROOT_OUT)/651 $(foreach item,$(recovery_resources_private), /652 cp -rf $(item) $(TARGET_RECOVERY_ROOT_OUT)/)653 cp $(RECOVERY_INSTALL_OTA_KEYS) $(TARGET_RECOVERY_ROOT_OUT)/res/keys 拷貝資源文件及密鑰文件。 654 cat $(INSTALLED_DEFAULT_PROP_TARGET) $(recovery_build_prop) /655 > $(TARGET_RECOVERY_ROOT_OUT)/default.prop 生成屬性文件 default.prop, 它包含了標准根文件系統的default.prop （out/target/proct/{proct_name}/root/default.prop）以及system分區的build.prop (out/target/proct/{proct_name}/system/build.prop) L656-L661 最終生成recovery.img
656 $(MKBOOTFS) $(TARGET_RECOVERY_ROOT_OUT) | $(MINIGZIP) > $(recovery_ramdisk) 壓縮recovery根文件系統 657 build/quacomm/mkimage $(PRODUCT_OUT)/ramdisk-recovery.img RECOVERY > $(PRODUCT_OUT)/ramdisk_recovery.img 加一個標識頭（RECOVERY） 658 mv $(PRODUCT_OUT)/ramdisk_recovery.img $(PRODUCT_OUT)/ramdisk-recovery.img659 $(MKBOOTIMG) $(INTERNAL_RECOVERYIMAGE_ARGS) --output $@660 @echo ----- Made recovery image -------- $@661 $(hide) $(call assert-max-image-size,$@,$(BOARD_RECOVERYIMAGE_PARTITION_SIZE),raw)
和內核一起，生成recovery.img附：Recovery 根文件系統目錄結構
$ tree
.
├── advanced_meta_init.rc
├── data
├── default.prop
├── dev
├── etc
├── init
├── init.factory.rc
├── init.goldfish.rc
├── init.quacomm.rc
├── init.rc
├── meta_init.rc
├── proc
├── res
│ ├── images
│ │ ├── icon_error.png
│ │ ├── icon_installing.png
│ │ ├── indeterminate1.png
│ │ ├── indeterminate2.png
│ │ ├── indeterminate3.png
│ │ ├── indeterminate4.png
│ │ ├── indeterminate5.png
│ │ ├── indeterminate6.png
│ │ ├── progress_empty.png
│ │ └── progress_fill.png
│ └── keys
├── sbin
│ ├── adbd
│ ├── advanced_meta_init
│ ├── meta_init
│ ├── meta_tst
│ └── recovery
├── sys
├── system
└── tmp