mtk安卓ota包編譯

㈠ 如何打包安卓手機Zip升級包如何簽名不換Recovery，用官方Recovery

通過分析update.zip包在具體Android系統升級的過程，來理解Android系統中Recovery模式服務的工作原理。
我們先從update.zip包的製作開始，然後是Android系統的啟動模式分析，Recovery工作原理，如何從我們上層開始選擇system update到重啟到Recovery服務，以及在Recovery服務中具體怎樣處理update.zip包升級的，我們的安裝腳本updater-script怎樣被解析並執行的等一系列問題。分析過程中所用的Android源碼是gingerbread0919（tcc88xx開發板標配的），測試開發板是tcc88xx。
一、 update.zip包的目錄結構
|----boot.img
|----system/
|----recovery/
`|----recovery-from-boot.p
`|----etc/
`|----install-recovery.sh
|---META-INF/
`|CERT.RSA
`|CERT.SF
`|MANIFEST.MF
`|----com/
`|----google/
`|----android/
`|----update-binary
`|----updater-script
`|----android/
`|----metadata
二、 update.zip包目錄結構詳解
以上是我們用命令make otapackage 製作的update.zip包的標准目錄結構。
1、boot.img是更新boot分區所需要的文件。這個boot.img主要包括kernel+ramdisk。
2、system/目錄的內容在升級後會放在系統的system分區。主要用來更新系統的一些應用或則應用會用到的一些庫等等。可以將Android源碼編譯out/target/proct/tcc8800/system/中的所有文件拷貝到這個目錄來代替。
3、recovery/目錄中的recovery-from-boot.p是boot.img和recovery.img的補丁(patch),主要用來更新recovery分區，其中etc/目錄下的install-recovery.sh是更新腳本。
4、update-binary是一個二進制文件，相當於一個腳本解釋器，能夠識別updater-script中描述的操作。該文件在Android源碼編譯後out/target/proct/tcc8800/system bin/updater生成，可將updater重命名為update-binary得到。
該文件在具體的更新包中的名字由源碼中bootable/recovery/install.c中的宏ASSUMED_UPDATE_BINARY_NAME的值而定。
5、updater-script：此文件是一個腳本文件，具體描述了更新過程。我們可以根據具體情況編寫該腳本來適應我們的具體需求。該文件的命名由源碼中bootable/recovery/updater/updater.c文件中的宏SCRIPT_NAME的值而定。
6、 metadata文件是描述設備信息及環境變數的元數據。主要包括一些編譯選項，簽名公鑰，時間戳以及設備型號等。
7、我們還可以在包中添加userdata目錄，來更新系統中的用戶數據部分。這部分內容在更新後會存放在系統的/data目錄下。
8、update.zip包的簽名：update.zip更新包在製作完成後需要對其簽名，否則在升級時會出現認證失敗的錯誤提示。而且簽名要使用和目標板一致的加密公鑰。加密公鑰及加密需要的三個文件在Android源碼編譯後生成的具體路徑為：
out/host/linux-x86/framework/signapk.jar
build/target/proct/security/testkey.x509.pem
build/target/proct/security/testkey.pk8 。
我們用命令make otapackage製作生成的update.zip包是已簽過名的，如果自己做update.zip包時必須手動對其簽名。
具體的加密方法：$ java –jar gingerbread/out/host/linux/framework/signapk.jar –w gingerbread/build/target/proct/security/testkey.x509.pem gingerbread/build/target/proct/security/testkey.pk8 update.zip update_signed.zip
以上命令在update.zip包所在的路徑下執行，其中signapk.jar testkey.x509.pem以及testkey.pk8文件的引用使用絕對路徑。update.zip 是我們已經打好的包，update_signed.zip包是命令執行完生成的已經簽過名的包。
9、MANIFEST.MF：這個manifest文件定義了與包的組成結構相關的數據。類似Android應用的mainfest.xml文件。
10、CERT.RSA：與簽名文件相關聯的簽名程序塊文件，它存儲了用於簽名JAR文件的公共簽名。
11、CERT.SF：這是JAR文件的簽名文件，其中前綴CERT代表簽名者。
另外，在具體升級時，對update.zip包檢查時大致會分三步：①檢驗SF文件與RSA文件是否匹配。②檢驗MANIFEST.MF與簽名文件中的digest是否一致。③檢驗包中的文件與MANIFEST中所描述的是否一致。
三、 Android升級包update.zip的生成過程分析
1) 對於update.zip包的製作有兩種方式，即手動製作和命令生成。
第一種手動製作：即按照update.zip的目錄結構手動創建我們需要的目錄。然後將對應的文件拷貝到相應的目錄下，比如我們向系統中新加一個應用程序。可以將新增的應用拷貝到我們新建的update/system/app/下（system目錄是事先拷貝編譯源碼後生成的system目錄），打包並簽名後，拷貝到SD卡就可以使用了。這種方式在實際的tcc8800開發板中未測試成功。簽名部分未通過，可能與具體的開發板相關。
第二種製作方式：命令製作。Android源碼系統中為我們提供了製作update.zip刷機包的命令，即make otapackage。該命令在編譯源碼完成後並在源碼根目錄下執行。 具體操作方式：在源碼根目錄下執行
①$ . build/envsetup.sh。
②$ lunch 然後選擇你需要的配置(如17)。
③$ make otapackage。
在編譯完源碼後最好再執行一遍上面的①、②步防止執行③時出現未找到對應規則的錯誤提示。命令執行完成後生成的升級包所在位置在out/target/proct/full_tcc8800_evm_target_files-eng.mumu.20120309.111059.zip將這個包重新命名為update.zip，並拷貝到SD卡中即可使用。
這種方式(即完全升級)在tcc8800開發板中已測試成功。
2) 使用make otapackage命令生成update.zip的過程分析。
在源碼根目錄下執行make otapackage命令生成update.zip包主要分為兩步，第一步是根據Makefile執行編譯生成一個update原包（zip格式）。第二步是運行一個python腳本，並以上一步准備的zip包作為輸入，最終生成我們需要的升級包。下面進一步分析這兩個過程。
第一步：編譯Makefile。對應的Makefile文件所在位置：build/core/Makefile。從該文件的884行（tcc8800,gingerbread0919）開始會生成一個zip包，這個包最後會用來製作OTA package 或者filesystem image。先將這部分的對應的Makefile貼出來如下：

[python] view plainprint?
# -----------------------------------------------------------------
# A zip of the directories that map to the target filesystem.
# This zip can be used to create an OTA package or filesystem image
# as a post-build step.
#
根據上面的Makefile可以分析這個包的生成過程：
首先創建一個root_zip根目錄，並依次在此目錄下創建所需要的如下其他目錄
①創建RECOVERY目錄，並填充該目錄的內容，包括kernel的鏡像和recovery根文件系統的鏡像。此目錄最終用於生成recovery.img。
②創建並填充BOOT目錄。包含kernel和cmdline以及pagesize大小等，該目錄最終用來生成boot.img。
③向SYSTEM目錄填充system image。
④向DATA填充data image。
⑤用於生成OTA package包所需要的額外的內容。主要包括一些bin命令。
⑥創建META目錄並向該目錄下添加一些文本文件，如apkcerts.txt(描述apk文件用到的認證證書)，misc_info.txt(描述Flash內存的塊大小以及boot、recovery、system、userdata等分區的大小信息)。
⑦使用保留連接選項壓縮我們在上面獲得的root_zip目錄。
⑧使用fs_config(build/tools/fs_config)配置上面的zip包內所有的系統文件(system/下各目錄、文件)的許可權屬主等信息。fs_config包含了一個頭文件#include「private/android_filesystem_config.h」。在這個頭文件中以硬編碼的方式設定了system目錄下各文件的許可權、屬主。執行完配置後會將配置後的信息以文本方式輸出 到META/filesystem_config.txt中。並再一次zip壓縮成我們最終需要的原始包。
第二步：上面的zip包只是一個編譯過程中生成的原始包。這個原始zip包在實際的編譯過程中有兩個作用，一是用來生成OTA update升級包，二是用來生成系統鏡像。在編譯過程中若生成OTA update升級包時會調用（具體位置在Makefile的1037行到1058行）一個名為ota_from_target_files的python腳本，位置在/build/tools/releasetools/ota_from_target_files。這個腳本的作用是以第一步生成的zip原始包作為輸入，最終生成可用的OTA升級zip包。
二 下面我們分析ota_from_target_files這個python腳本是怎樣生成最終zip包的。先講這個腳本的代碼貼出來如下：
[python] view plainprint?
import sys
if sys.hexversion < 0x02040000:
print >> sys.stderr, "Python 2.4 or newer is required."
sys.exit(1)
主函數main是python的入口函數，我們從main函數開始看，大概看一下main函數（腳本最後）里的流程就能知道腳本的執行過程了。
① 在main函數的開頭，首先將用戶設定的option選項存入OPTIONS變數中，它是一個python中的類。緊接著判斷有沒有額外的腳本，如果有就讀入到OPTIONS變數中。
② 解壓縮輸入的zip包，即我們在上文生成的原始zip包。然後判斷是否用到device-specific extensions（設備擴展）如果用到，隨即讀入到OPTIONS變數中。
③ 判斷是否簽名，然後判斷是否有新內容的增量源，有的話就解壓該增量源包放入一個臨時變數中（source_zip）。自此，所有的准備工作已完畢，隨即會調用該 腳本中最主要的函數WriteFullOTAPackage(input_zip,output_zip)
④ WriteFullOTAPackage函數的處理過程是先獲得腳本的生成器。默認格式是edify。然後獲得metadata元數據，此數據來至於Android的一些環境變數。然後獲得設備配置參數比如api函數的版本。然後判斷是否忽略時間戳。
⑤ WriteFullOTAPackage函數做完准備工作後就開始生成升級用的腳本文件(updater-script)了。生成腳本文件後將上一步獲得的metadata元數據寫入到輸出包out_zip。
⑥至此一個完整的update.zip升級包就生成了。生成位置在：out/target/proct/tcc8800/full_tcc8800_evm-ota-eng.mumu.20120315.155326.zip。將升級包拷貝到SD卡中就可以用來升級了。
四、 Android OTA增量包update.zip的生成
在上面的過程中生成的update.zip升級包是全部系統的升級包。大小有80M多。這對手機用戶來說，用來升級的流量是很大的。而且在實際升級中，我們只希望能夠升級我們改變的那部分內容。這就需要使用增量包來升級。生成增量包的過程也需要上文中提到的ota_from_target_files.py的參與。
下面是製作update.zip增量包的過程。
① 在源碼根目錄下依次執行下列命令
$ . build/envsetup.sh
$ lunch 選擇17
$ make
$ make otapackage
執行上面的命令後會在out/target/proct/tcc8800/下生成我們第一個系統升級包。我們先將其命名為A.zip
② 在源碼中修改我們需要改變的部分，比如修改內核配置，增加新的驅動等等。修改後再一次執行上面的命令。就會生成第二個我們修改後生成的update.zip升級包。將 其命名為B.zip。
③ 在上文中我們看了ota_from_target_files.py腳本的使用幫助，其中選項-i就是用來生成差分增量包的。使用方法是以上面的A.zip 和B.zip包作為輸入，以update.zip包作 為輸出。生成的update.zip就是我們最後需要的增量包。
具體使用方式是：將上述兩個包拷貝到源碼根目錄下，然後執行下面的命令。
$ ./build/tools/releasetools/ota_from_target_files -i A.zip B.zip update.zip。
在執行上述命令時會出現未找到recovery_api_version的錯誤。原因是在執行上面的腳本時如果使用選項i則會調用WriteIncrementalOTAPackage會從A包和B包中的META目錄下搜索misc_info.txt來讀取recovery_api_version的值。但是在執行make otapackage命令時生成的update.zip包中沒有這個目錄更沒有這個文檔。
此時我們就需要使用執行make otapackage生成的原始的zip包。這個包的位置在out/target/proct/tcc8800/obj/PACKAGING/target_files_intermediates/目錄下，它是在用命令make otapackage之後的中間生產物，是最原始的升級包。我們將兩次編譯的生成的包分別重命名為A.zip和B.zip，並拷貝到SD卡根目錄下重復執行上面的命令：
$ ./build/tools/releasetools/ota_form_target_files -i A.zip B.zip update.zip。
在上述命令即將執行完畢時，在device/telechips/common/releasetools.py會調用IncrementalOTA_InstallEnd,在這個函數中讀取包中的RADIO/bootloader.img。
而包中是沒有這個目錄和bootloader.img的。所以執行失敗，未能生成對應的update.zip。可能與我們未修改bootloader（升級firmware）有關。此問題在下一篇博客已經解決。
製作增量包失敗的原因，以及解決方案。

Android系統Recovery工作原理之使用update.zip升級過程分析（二）---update.zip差分包問題的解決
在上一篇末尾提到的生成差分包時出現的問題，現已解決，由於最近比較忙，相隔的時間也比較長，所以單列一個篇幅提示大家。這個問題居然是源碼中的問題，可能你已經製作成功了，不過我的這個問題確實是源碼中的一個問題，不知道是不是一個bug，下文會具體分析！
一、生成OTA增量包失敗的解決方案
在上一篇中末尾使用ota_from_target_files腳本製作update.zip增量包時失敗，我們先將出現的錯誤貼出來。
在執行這個腳本的最後讀取input_zip中RADIO/bootloader.img時出現錯誤，顯示DeviceSpecifiParams這個對象中沒有input_zip屬性。
我們先從腳本中出現錯誤的調用函數中開始查找。出現錯誤的調用地方是在函WriteIncrementalOTAPackage（443行）中的device_specific.IncrementalOTA_InstallEnd()，其位於WriteIncrementalOTAPackage()中的末尾。進一步跟蹤源碼發現，這是一個回調函數，他的具體執行方法位於源碼中/device/telechips/common/releasetools.py腳本中的IncrementalOTA_InstallEnd()函數。下面就分析這個函數的作用。
releasetools.py腳本中的兩個函數FullOTA_InstallEnd()和IncrementalOTA_InstallEnd()的作用都是從輸入包中讀取RADIO/下的bootloader.img文件寫到輸出包中，同時生成安裝bootloader.img時執行腳本的那部分命令。只不過一個是直接將輸入包中的bootloader.img鏡像寫到輸出包中，一個是先比較target_zip和source_zip中的bootloader.img是否不同（使用選項-i生成差分包時），然後將新的鏡像寫入輸出包中。下面先將這個函數(位於/device/telechips/common/releasetools.py)的具體實現貼出來：
我們的實際情況是，在用命令make otapackage時生成的包中是沒有這個RADIO目錄下的bootloader.img鏡像文件（因為這部分更新已被屏蔽掉了）。但是這個函數中對於從包中未讀取到bootloader.img文件的情況是有錯誤處理的，即返回。所以我們要從 出現的實際錯誤中尋找問題的原由。
真正出現錯誤的地方是：
target_bootloader=info.input_zip.read(「RADIO/bootloader.img」)。
出現錯誤的原因是：AttributeError：『DeviceSpecificParams』object has no attribute 『input_zip』，提示我們DeviceSpecificParams對象沒有input_zip這個屬性。
二、updater-script腳本執行流程分析：
先看一下在測試過程中用命令make otapackage生成的升級腳本如下：
[python] view plainprint?
assert(!less_than_int(1331176658, getprop("ro.build.date.utc")));
assert(getprop("ro.proct.device") == "tcc8800" ||
下面分析下這個腳本的執行過程：
①比較時間戳：如果升級包較舊則終止腳本的執行。
②匹配設備信息：如果和當前的設備信息不一致，則停止腳本的執行。
③顯示進度條：如果以上兩步匹配則開始顯示升級進度條。
④格式化system分區並掛載。
⑤提取包中的recovery以及system目錄下的內容到系統的/system下。
⑥為/system/bin/下的命令文件建立符號連接。
⑦設置/system/下目錄以及文件的屬性。
⑧將包中的boot.img提取到/tmp/boot.img。
⑨將/tmp/boot.img鏡像文件寫入到boot分區。
⑩完成後卸載/system。
三、總結
以上的九篇著重分析了Android系統中Recovery模式中的一種，即我們做好的update.zip包在系統更新時所走過的流程。其核心部分就是Recovery服務的工作原理。其他兩種FACTORY RESET、ENCRYPTED FILE SYSTEM ENABLE/DISABLE與OTA INSTALL是相通的。重點是要理解Recovery服務的工作原理。另外詳細分析其升級過程，對於我們在實際升級時，可以根據我們的需要做出相應的修改。

㈡ 手機方案公司需要在mtk工程源碼編譯後將apk預裝到system/app目錄下如何操作

在 Android 中，如果要使用系統限制的許可權（比如 android.permission.WRITE_SECURE_SETTINGS），我們需要把程序安裝到 /system/app/ 下。

下面以 SecureSetting.apk 為例，演示這個操作。需要准備一台已經獲得 Root 許可權的手機。

1、通過 USB 連接手機和電腦。

2、使用 adb 控制手機。

源碼列印？

1. $ adb push SecureSetting.apk /sdcard/ // 上傳要安裝的文件，為安裝做准備。
2. $ adb shell
3. $ su // 切換到 root 用戶。如果沒有獲得 Root 許可權，這一步不會成功。
4. # mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system // 讓分區可寫。
5. # cat /sdcard/SecureSetting.apk > /system/app/SecureSetting.apk // 這一步可以用 cp 實現，但一般設備中沒有包含該命令。如果使用 mv 會出現錯誤：failed on '/sdcard/NetWork.apk' - Cross-device link。
6. # mount -o remount,ro -t yaffs2 /dev/block/mtdblock3 /system // 還原分區屬性，只讀。
7. # exit
8. $ exit

$ adb push SecureSetting.apk /sdcard/ // 上傳要安裝的文件，為安裝做准備。
$ adb shell
$ su // 切換到 root 用戶。如果沒有獲得 Root 許可權，這一步不會成功。
# mount -o remount,rw -t yaffs2 /dev/block/mtdblock3 /system // 讓分區可寫。
# cat /sdcard/SecureSetting.apk > /system/app/SecureSetting.apk // 這一步可以用 cp 實現，但一般設備中沒有包含該命令。如果使用 mv 會出現錯誤：failed on '/sdcard/NetWork.apk' - Cross-device link。
# mount -o remount,ro -t yaffs2 /dev/block/mtdblock3 /system // 還原分區屬性，只讀。
# exit
$ exit

㈢ 如何給Android的OTA包添加校驗標識

下面以（RK 的 Sofia3GR 方案）來分享一下給OTA添加校驗標識經驗。
1、首先必須要了解ota升級原理以及phony腳本， 這個我就不多說了，網上資料一大把。
2、給系統添加一個屬性欄位
Sofia3GR 添加屬性欄位是在device\rockchip\sofia3gr\sofia3gr.mk裡面：我添加 ro.proct.author = TangYin 屬性。
然後執行make installclean 、 make -j8 、 ./mkimage.sh SF_3GR-cars-mehome-mn34227.dtb ota 編譯生成ota 包， 利用SD卡燒寫 到板上。
在板上使用getprop 命令可以查看到， 也可cat /system/build.prop文件。

㈣ MTK 怎麼把apk自帶的so文件編譯到rom里邊

一般情況下，MTK 文檔上面是有這個說明的，要把apk中的so文件，放到alpsvendormediatekckt72_wet_jb3artifactsout argetproctckt72_wet_jb3systemlib 里邊。注釋 ckt72_wet_jb3 是項目名字，但是這里會有一個Bug。就是當你不再用第三方apk的時候，這個so文件依舊會打包進去到rom里邊，如果你累計的so文件過大的話，rom就會變大，會影響內存運行的。這個時候，我們要想一個辦法解決才行。

如圖所示 建立這樣的目錄。lib里邊放的是apk里邊的so文件，Android.mk文件裡面的內容如下

LOCAL_PATH:= $(call my-dir)
include $(CLEAR_VARS)
LOCAL_MODULE := feizai
LOCAL_MODULE_TAGS := optional
LOCAL_SRC_FILES := $(LOCAL_MODULE).apk
LOCAL_MODULE_CLASS := APPS
LOCAL_MODULE_SUFFIX := $(COMMON_ANDROID_PACKAGE_SUFFIX)
LOCAL_CERTIFICATE := PRESIGNED

PRODUCT_COPY_FILES += $(LOCAL_PATH)/lib/libabenchmark.so:system/lib/libabenchmark.so
include $(BUILD_PREBUILT)

如果你apk的so文件不止一個，如下添加

PRODUCT_COPY_FILES+=
$(LOCAL_PATH)/libem_aitalk5.so:system/lib/libem_aitalk5.so
$(LOCAL_PATH)/libspeechmsc.so:system/lib/libspeechmsc.so
$(LOCAL_PATH)/libttsaisound.so:system/lib/libttsaisound.so
$(LOCAL_PATH)/libvadLib.so:system/lib/libvadLib.so

頂

0

㈤ 如何學習MTK 編譯android系統的framework層源碼，需要看一些什麼文檔，最近在公司需要學習、

mtk有個叫makeMtk的腳本文件，直接執行就行，後面參數加上自己要編譯的模塊，比如./makeMtk -t mm frameworks/base/core/res

㈥ 如何編譯 MTK 的模擬器

MTK的emulator是基於MTK平台的codeabse編譯得到用來模擬真機的虛擬Device,以下是具體的操作步驟：
1. Build MTK SDK Packages
-對於mt6572以前的chip，用如下的命令編譯:
./makeMtk banyan_addon
-從mt6572開始的chip,由於mt6572之後CPU開始支持X86架構，其performace會更好，mt6572之後，建議編譯x86的emulator來使用.

./makeMtk banyan_addon_x86

編譯完成後會在out/host/linux-x86/sdk_addon下生成MTK的SDK包，比如mtk_sdk_api_addon-17.1.zip，(其中17是android api level)

2. 解壓mtk_sdk_api_addon_17.1.zip
將解壓後的mtk_sdk_api_addon-17.1整個文件夾放在android原本的sdk的add-ons目錄下。

3. 拷貝emulator相關的執行文件到android sdk tool下：
- 對ICS 4.0之前的版本：
進 入android-sdk-windows\add-ons\banyan_addon_ALPS.GB.FDD.MP.V1_eng\tools 目錄下，將其中的 emulator.exe 或者 emulator（如果使用Linux的SDK的話）復制出來，覆蓋android-sdk-windows\tools下的相應 emulator.exe

- 對ICS 4.0及之後的版本：
將 mtk_sdk_api_addon-15.1\emulator對應文件夾下的emulator,emulator-arm,emulator-x86 這三支文件替換android原本sdk的tools目錄下的emulator,emulator-arm,emulator-x86這三支文件(建議備 份google原始sdk下的emulator,emulator-arm,emulator-x86，以便後面用到Google emulator)。

4. 創建新的AVD
在Target裡面選擇帶有MediaTek標志的，然後啟動這一AVD就可以了
PS：創建AVD時需要同步將SDK的版本升級到相對的android版本，比如JB2對應的android API level 17,則對應SDK的版本也要升級到level 17,否則將在創建AVD的時候將load不出帶MediaTek標志的target

㈦ android 怎麼編譯otapackage

在make android系統後，會生成系統的img文件。 make otapackage 會生成sd卡用的全部系統升級包,有260M多。要生成增量升級包。需要按以下步驟。 mkdir ~ /OTA source build/envsetup.sh; choosecom 1 1 7 eng make;make otapackage

㈧ Yocto編譯傑發或MTK的linux或android時的幾個問題

編譯問題1（audiomanager_7.0.bb的do_configure報錯）：

錯誤：CMake Error at Plugins/PluginCommandInterfaceCAPI/cmake/CommonAPI.cmake:352 (message):

|   Failed to generate files from FIDL:

手動執行一下：

$ commonapi-generator-linux-x86 -ll verbose -sk Default -d . /data/linux/hz_rs28_bm/sources/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/audiomanager/7.0-r1/audiomanager-7.0/Plugins/PluginCommandInterfaceCAPI/fidl/CommandInterface.fidl

-bash: /data/linux/hz_rs28_bm/sources/src/build/tools/commonapi_tool/commonapi-generator/commonapi-generator-linux-x86: /lib/ld-linux.so.2: bad ELF interpreter: No such file or directory

解決（需要安裝32位的glibc庫和32位java jre環境）：

$ sudo yum install glibc.i686

$ sudo yum install java-1.8.0-openjdk.i686

$ sudo ln -s /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.191.b12-1.el7_6.i386/jre/bin/java /bin/java

$ java -version    （保證是32位的java）

編譯問題2（perl_5.20.0.bb的do_package報錯）：

錯誤：ERROR: obj failed with exit code 256 (cmd was 『arm-poky-linux-gnueabi-obj』 –only-keep-debug

… generate_uudmap: File format not recognized

解決（tar在1.29版本之後需要exclude在路徑的前面）：

sources/meta/poky/bitbake/lib/bb/fetch2/bzr.py

tar_flags = 「–exclude 『.bzr』 –exclude 『.bzrtags'」

修改成：

tar_flags = 「–exclude=』.bzr』 –exclude=』.bzrtags'」

sources/meta/poky/bitbake/lib/bb/fetch2/cvs.py

tar_flags = 「–exclude 『CVS'」

修改成：

tar_flags = 「–exclude=』CVS'」

sources/meta/poky/bitbake/lib/bb/fetch2/repo.py

tar_flags = 「–exclude 『.repo』 –exclude 『.git'」

修改成：

tar_flags = 「–exclude=』.repo』 –exclude=』.git'」

sources/meta/poky/bitbake/lib/bb/fetch2/svn.py

tar_flags = 「–exclude 『.svn'」

修改成：

tar_flags = 「–exclude=』.svn'」

sources/meta/poky/meta/recipes-devtools/quilt/quilt-0.63.inc

       tar -cf – bin/ –exclude \*.in | ( cd ${D}${PTEST_PATH} && tar -xf – )

       tar -cf – compat/ –exclude \*.in | ( cd ${D}${PTEST_PATH} && tar -xf – )

       tar -cf – quilt/ –exclude \*.in | ( cd ${D}${PTEST_PATH} && tar -xf – )

       tar -cf – test/ –exclude mail.test –exclude delete.test | ( cd ${D}${PTEST_PATH} && tar -xf – )

修改成：

        tar -c –exclude=\*.in bin/ | ( cd ${D}${PTEST_PATH} && tar -xf – )

        tar -c –exclude=\*.in compat/ | ( cd ${D}${PTEST_PATH} && tar -xf – )

        tar -c –exclude=\*.in quilt/ | ( cd ${D}${PTEST_PATH} && tar -xf – )

        tar -c –exclude=mail.test –exclude=delete.test test/ | ( cd ${D}${PTEST_PATH} && tar -xf – && chmod 777 test)

sources/meta/poky/meta/recipes-extended/sed/sed-4.2.2/sed-add-ptest.patch

+       cd $(BUILDDIR); tar -cf – $(TESTDIR) –exclude *.o | ( cd $(DESTDIR) && tar -xf – )

修改成：

+       cd $(BUILDDIR); tar -c –exclude=*.o $(TESTDIR) | ( cd $(DESTDIR) && tar -xf – )

sources/meta/poky/meta/recipes-support/attr/acl.inc

tar -cf – test/ –exclude nfs | ( cd ${D}${PTEST_PATH} && tar -xf – )

修改成：

tar -c –exclude=nfs test/ | ( cd ${D}${PTEST_PATH} && tar -xf – )

sources/meta/poky/meta/recipes-support/attr/attr.inc

tar -cf – test/ –exclude ext | ( cd ${D}${PTEST_PATH} && tar -xf – )

修改成：

tar -c –exclude=ext test/ | ( cd ${D}${PTEST_PATH} && tar -xf – )

sources/meta/poky/meta/recipes-devtools/perl/perl-ptest.inc

       tar -cf – * –exclude \*.o –exclude libperl.so –exclude Makefile –exclude makefile –exclude hostperl \

               –exclude miniperl –exclude generate_uudmap –exclude patches | ( cd ${D}${PTEST_PATH} && tar -xf – )

修改成：

        tar -c –exclude=\*.o –exclude=libperl.so –exclude=Makefile –exclude=makefile –exclude=hostperl \

                –exclude=miniperl –exclude=generate_uudmap –exclude=patches * | ( cd ${D}${PTEST_PATH} && tar -x )

編譯問題3（libunwind_1.1.bb的do_compile報錯）：

錯誤：make[1]: latex2man: Command not found

解決：

$ sudo yum install texlive-tetex

$ sudo rpm -ivh ~/latex2man-1.18-2.noarch.rpm

編譯問題3（qt5-app_1.0.bb的do_compile報錯）：

錯誤（有一批類似的錯誤）：ld: cannot find -lgtest

解決：

$ vi atc_linux/application/btate/btate.pro

equals(MY_BUILD_SYSTEM, atc) {

    LIBS += -L $(DA_LIBDIR)/lib -lgtest -lpthread -lbluetoothclient -lglobalbus -lappobj -lapputils

} else {

    LIBS += -L$(DA_TOP)/application/lib -L$(DA_TOP)/../../sources/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/atc-binarys/1.0-r0/image/usr/lib -lgtest -lpthread -lbluetoothclient -l

globalbus -lappobj -lapputils

}

$ vi atc_linux/application/gps/gps_bin.pro

equals(MY_BUILD_SYSTEM, atc) {

    LIBS += -L $(DA_LIBDIR)/lib  -lapputils  -lglobalbus -lappobj -lgps

} else {

    LIBS += -L$(DA_TOP)/application/lib -L$(DA_TOP)/../../sources/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/gpsd/3.10-r0/gpsd-3.10/ -lapputils  -lglobalbus -lappobj -lgps

}

$ vi atc_linux/application/dvr/dvr_bin.pro

equals(MY_BUILD_SYSTEM, atc) {

        LIBS    += -L${DA_TOP}/lib/lib/ -ldvr -ludev -lsurface_atc -lglobalbus -lappobj -lapputils -lstorage_atc -lgps

} else {

        LIBS    += -L${DA_TOP}/application/lib -L$(DA_TOP)/../../sources/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/gpsd/3.10-r0/gpsd-3.10/ -ldvr -ludev -lsurface_atc -lglobalbus –

lappobj -lapputils -lstorage_atc -lgps

}

$ vi atc_linux/application/dvr/dvr_bin.pro

INCLUDEPATH +=  ${DA_TOP}/kernel/kernel-3.18/drivers/ \

                ../common/  \

                ../utils/   \

                ../appobj/include/          \

                ../globalbus/include/       \

                ../appcommon/include/       \

                ../storage_atc/             \

                ../dvr/gps/             \

                ../gps/include/         \

                ../gps/includeex/       \

編譯問題4（makall報錯）：

報錯：./makall: line 169: mkisofs: command not found

解決：$ sudo yum install mkisofs

編譯問題5（修改ac83xx_systemd_defconfig再編譯時報錯）：

報錯：Applying patch remove-selinux-android.patch

patching file system/extras/ext4_utils/make_ext4fs.c

Hunk #1 FAILED at 62.

1 out of 1 hunk FAILED — rejects in file system/extras/ext4_utils/make_ext4fs.c

解決：

$ vi sources/meta/meta-atc/recipes-devtools/android-tools/android-tools_5.1.1.r37.bb

在裡面做個假的do_patch()，bitbake會優先使用本bb文件的do_patch()函數。

do_patch(){

}

編譯問題6（修改ac83xx_systemd_defconfig再編譯時報錯）：

報錯：sources/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/qtbase/5.5.0+gitAUTOINC+c619d2daac-r0/git/src/corelib/tools/qregexp.cpp:3947:1: internal compiler error: in add_stores, at var-tracking.c:6000

解決：

$ cd sources/meta/poky/meta/recipes-devtools/gcc/gcc-4.9/

$ wget  http://openlinux.windriver.com/overc/sources/core2_64/gcc-4.9.2-r0.1/0062-gcc-var-tracking.c-backport-from-gcc-trunk-r212178.patch

$ vi sources/meta/poky/meta/recipes-devtools/gcc/gcc-4.9.inc

    file://0058-gcc-r212171.patch \

    file://0059-gcc-PR-rtl-optimization-63348.patch \

    file://target-gcc-includedir.patch \

    file://0062-gcc-var-tracking.c-backport-from-gcc-trunk-r212178.patch \

其實就是這個文件：

$ cat 0062-gcc-var-tracking.c-backport-from-gcc-trunk-r212178.patch

From Mon Sep 17 00:00:00 2001

From: =?UTF-8?q?Stefan=20M=C3=BCller-Klieser?= <[email protected]>

Date: Tue, 7 Apr 2015 16:15:11 +0200

Subject: [PATCH] gcc/var-tracking.c: backport from gcc trunk r212178

MIME-Version: 1.0

Content-Type: text/plain; charset=UTF-8

Content-Transfer-Encoding: 8bit

resolves a bug seen on cortexa8 building qt5 libraries.

2014-06-30  Joseph Myers  <[email protected]>

    * var-tracking.c (add_stores): Return instead of asserting if old

    and new values for conditional store are the same.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@212178 138bc75d-0d04-0410-961f-82ee72b054a4

Signed-off-by: Stefan Müller-Klieser <[email protected]>

---

gcc/var-tracking.c | 3 ++-

1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gcc/var-tracking.c b/gcc/var-tracking.c

index 65d8285..7c38910 100644

--- a/gcc/var-tracking.c

+++ b/gcc/var-tracking.c

@@ -5997,7 +5997,8 @@ add_stores (rtx loc, const_rtx expr, void *cuip)

    {

      cselib_val *oval = cselib_lookup (oloc, GET_MODE (oloc), 0, VOIDmode);

-      gcc_assert (oval != v);

+      if (oval == v)

+        return;

      gcc_assert (REG_P (oloc) || MEM_P (oloc));

      if (oval && !cselib_preserved_value_p (oval))

--

1.9.1

編譯問題7（修改ac83xx_systemd_defconfig再編譯時報錯）：

報錯：libevdev/1.2.2-r0/libevdev-1.2.2/test/test-main.c:24:19: fatal error: check.h: No such file or directory

解決：

$ vi meta/poky/meta/recipes-support/libevdev/libevdev_1.2.2.bb

LIC_FILES_CHKSUM = 「file://COPYING;md5= \

                    file://libevdev/libevdev.h;endline=21;md5=″

DEPENDS += 「libcheck」

SRC_URI = 「 http://www.freedesktop.org/software/libevdev/ ${BP}.tar.xz」

編譯問題8（修改ac83xx_systemd_defconfig再編譯時報錯）：

報錯：python報錯： 『do_rootfs』, lineno: 17, function

Exception: CalledProcessError: Command 『[『』, 『-ks』, …

解決： 沒有實際問題，重新編譯一次即可，可能是機器太忙導致超時，或者某個命令執行不成功。

編譯問題9（preuboot編譯工具問題）：

報錯：make: armv7a-mediatek451_001_vfp-linux-gnueabi-gcc: Command not found

解決：

$ vi atc_linux/bootloader/preuboot/Makefile

#CROSS_COMPILE  :=armv7a-mediatek451_001_vfp-linux-gnueabi-

CROSS_COMPILE  :=arm-poky-linux-gnueabi-

$ vi ../../atc_linux/bootloader/preuboot/driver/mmc/include/linux/list.h

#ifndef NULL

    #define NULL 0

#endif

㈨ 如何編譯一個可以燒寫進手機中的ROM，Android安卓開發者

首先．還是跟其它文章講的一樣．先下載ANDORID的源碼．在下源碼之前．請看下面第一步
----------
增加代碼，下真機配置

1
vim .repo/local_manifest.xml

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
<project path="kernel" name="kernel/msm" revision="refs/heads/android-msm-2.6.29"/>
<project path="hardware/htc/dream" name="platform/hardware/htc/dream" revision="master"/>

</manifest>

增加上面這段代碼，為一個配置．告訴伺服器．我們下的代碼．是要裝進真機的．
（就為了多下載一個KERNEL下來。。還有下載DREAM的真機配置參數..）

小哈在這里折騰了很久．很久．．非常久．．回憶起來內牛滿面

-----
下相關的代碼

2.

repo sync

-----
3.
vim env_rc
加入:
export EMU=/home/coconut/cupcake/out/host/linux-x86/bin
export ARCH=arm
export CROSS_COMPILE=arm-eabi-
export PATH=$PATH:/home/coconut/cupcake/prebuilt/linux-x86/toolchain/arm-eabi-4.2.1/bin:${EMU}

source env_rc

4.

編譯內核及無線網路驅動

$ cd $ANDROID/kernel
$ make ARCH=arm CROSS_COMPILE=../prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- msm_defconfig # 設定默認的msm配置

#編譯內核
make ARCH=arm CROSS_COMPILE=../prebuilt/linux-x86/toolchain/arm-eabi-4.4.0/bin/arm-eabi-

#編譯無線網路驅動
cd $ANDROID/system/wlan/ti/sta_dk_4_0_4_32
make ARCH=arm CROSS_COMPILE=$ANDROID/prebuilt/linux-86/toolchain/arm-eabi-4.4.0/bin/arm-eabi- KERNEL_DIR=$ANDROID/kernel

//內核拷到目錄下
$ cp $ANDROID/kernel/arch/arm/boot/zImage $ANDROID/vendor/htc/dream-open/kernel
$ cp $ANDROID/system/wlan/ti/sta_dk_4_0_4_32/wlan.ko $ANDROID/vendor/htc/dream-open/wlan.ko

5.
在HTC網站(developer.htc.com/adp.html)
下載名為signed-dream_devphone_userdebug-ota-14721.zip的包，並把它放在$ANDROID目錄下
$ cd $ANDROID
$ source build/envsetup.sh

$ lunch aosp_dream_us-eng # 指明機型
這樣編譯出來.就會在OUT下出來一個DREAM_OPEN的目錄.裡面就有相關的鏡像文件了.

$ cd vendor/htc/dream-open
$ ./unzip-files.sh ＃ 解壓htc相關驅動
$ cd $ANDROID
$ vi buildspec.mk ＃ 新建配置文件

－－－－
Vim htc_dream.mk

vim /oracle/android/src/vendor/htc/dream-open/htc_dream.mk

在頭部增加
PRODUCT_PACKAGES := \
Calculator \
Email \
ImProvider \
SdkSetup \
VoiceDialer

完成。
回到根目錄

cd /oracle/android/src
vim buildspec.mk
加入( 2010.7.7 不需要加入)：
#TARGET_PRODUCT:=htc_dream
#TARGET_PREBUILT_KERNEL:=kernel/arch/arm/boot/zImage

增加:
CUSTOM_LOCALES:=zh_CN

然後：

其中增加環境：
ubuntu 8.10 , sudo apt-get libelf-dev

make clean

// 保證PC有 1280 內存, 加上 1000 SWAP空間..虛擬機也是如此.
然後開始編譯 BOOT.IMG SYSTEM.IMG USERDATA.IMG:
make -j2

接下來
mmm -B $ANDROID/packages/apps/Luancher/ snod

cd out/target/proct/dream-open/

//先測試:
emulator -system . -kernel ~/cupcake/prebuilt/android-arm/kernel/kernel-qemu -data userdata.img
因為出來了BOOT.IMG.這個是真機的..所以不能用BOOT做為內核.要用模擬器來做內核.

//然後開始燒機
fastboot flash boot boot.img
fastboot flash system system.img
fastboot flash userdata userdata.img

fastboot reboot

㈩ MTK6582編譯Android手機程序

13年11月谷歌低調發布安卓4.4，之前人們一直在猜疑，到底MTK(聯發科）會不會為MT6589,MT6582這些CPU提供升級至安卓4.4解決方案呢？爭論不斷，後發現聯想VIBE官方論壇發出一份升級計劃，其中包含了MTK可以升級至安卓4.4,升級機型含括了MTK6589、MT6582和MT6592，因此可以基本確認，此類CPU都將可能升級至安卓4.4。 安卓4.4介紹 1、新特性編輯支持兩種編譯模式 除了默認的 Dalvik 模式,還支持 ART 模式 2、RAM優化 Android 4.4 KitKat針對RAM佔用進行了優化，甚至可以在一些僅有512MB RAM的老款手機上流暢運行。它也進一步優化了系統在低配硬體上的運行效果， 支持內核同頁合並 KSM,ZRAM 交換，似乎是為了更好地在眾多智能穿戴設備上運行。 3、新圖標、鎖屏、啟動動畫和配色方案 之前藍綠色的配色設計被更換成了白/灰色，更加簡約，另外圖標風格也進一步扁平化，還內置了一些新的動畫，整體來說界面更漂亮、佔用資源更少。另外，還加入了半透明的界面樣式，以確保狀態欄和導航欄在應用中發揮更好的效果。 4、新的撥號和智能來電顯示 首先，新的撥號程序會根據使用習慣，自動智能推薦常用的聯系人，方便快速撥號；同時，一些知名企業或是服務號碼的來電，會使用谷歌的在線資料庫進行匹配自動顯示名稱，即使手機中沒有存儲。 5、加強主動式語音功能 在Nexus 5上，可以通過說「OK，Google」來啟動語音功能，而不需要觸碰任何按鍵或是平煤，但並非支持所有機型。另外，語音搜索功能的精度也提升了25%，更加准確，還支持買電影票等新功能。 6、集成Hangouts IM軟體 Android 4.4內置了Hangouts IM軟體，類似於國內的微信，可以實現跨平台的文字、語音聊天功能，也能夠傳輸圖片、視頻等各種文件。 7、全屏模式 不論是在看電子書、或是使用任何應用程序，都能夠方便地進入到全屏模式，隱藏虛擬按鍵，帶來更投入的使用體驗。只需滑動屏幕邊緣，便可找回按鍵，也十分方便。 8、支持Emoji鍵盤 終於，Android也能夠支持豐富有趣的Emoji輸入了，可以讓郵件或是信息更加個性化。 9、輕松訪問在線存儲 可以直接在手機或平板電腦中打開存儲在Google Drive或是其他雲端存儲的文件，支持相冊或是QuickOffice等軟體，十分方便。 10、無線列印 可以使用谷歌Cloud Print無線列印手機內的照片、文檔或網頁，其他列印機廠商也將迅速跟進，發布相關應用。 11、屏幕錄像功能 Android 4.4增加了屏幕錄像功能，可以將所有在設備上的操作錄制為一段MP4視頻，並選擇長寬比或是比特率，甚至是添加水印。 12、內置字幕管理功能 在播放視頻時可自行添加字幕。 13、計步器應用 Android 4.4內置了計步器等健身應用，谷歌也在加緊與晶元製造商的合作，為未來的智能手錶做准備。 14、低功耗音頻和定位模式 Android 4.4加入了低功耗音頻和定位模式，進一步減少設備的功耗。 15、新的接觸式支付系統 雖然谷歌錢包還沒正式推出，但是Android 4.4中已經加入了新的接觸式支付功能，通過NFC和智能卡，可以在手機端輕松完成支付。 16、新的藍牙配置文件和紅外兼容性 Android 4.4內置了兩個新的藍牙配置文件，可以支持更多的設備，功耗也更低，包括滑鼠、鍵盤和手柄，還能夠與車載藍牙交換地圖。另外，新的紅外線遙控介面可以支持更多設備，包括電視、開關等等。