android升級包製作

⑴ 如何自己編譯android系統並製作刷機包

android系統製作刷機包方法：

【一】：下載安裝最新版ROM助手（市場中有很多類似的製作工具，關鍵要求操作簡單，功能強大），安裝程序非常簡單，只需在一隻蘑菇首頁內直接下載，並解壓到自己的電腦安裝即可。

【二】：如果已經下載了與機型匹配的ROM刷機包，那麼現在可以直接打開ROM助手了，接下來繪制專屬個性的完美刷機包就從這里開始吧。

【三】：打開軟體後，它會自動升級到最新版本，另外打開主界面後，會直觀簡明的顯示出它的所有功能，例如：性能優化，系統精簡，預裝APK，簽名打包等等。提醒大家，不要貪心哦，要根據自己的需求點擊需要操作的功能，如系統精簡，然後進入操作界面，所有功能全部修改一遍也無妨，反正都是一鍵操作，省時省力。

⑵ 如何修改製作卡刷包 安卓卡刷包製作教程

在此先要明確聲明一下：
依照此做法出現您的手機出現任何問題，概不負責的喔！！
英文好的朋友，可以直接看英文官方的參考網站即可：
只用android源代碼做一些簡單實驗的朋友可以參考下面這幾個網站：
說起android刷機包，聽起來非常神秘，實際上它僅僅是一個經過數字簽名的zip壓縮包而已。如果要自己製作刷機包，則必須了解刷機包的基本工作原理，偶首先從android系統的啟動說起：
android系統啟動的時候，首先會進行一些諸如硬體自檢之類的操作，這些操作完成以後（至少它應該知道當前的機器有沒有電），會檢查一下當前手機按鍵的狀態（接下來就是所謂刷機模式切換了，不同的android手機有不同的按鍵組合用來進入刷機模式），如果此時按鍵狀態處於刷機組合，那麼系統會調用ROM裡面的一個叫做recovery的程序（這時就是進入了所謂的刷機程序了，它只是一個工具性質程序，用於檢查刷機包的完整性和數字簽名的合法性。對於目前大多數root過的機器而言，數字簽名的合法性都不會成問題，然後由recovery程序將刷機包進行解壓，然後把刷機包裡面的文件寫入到ROM中去，以此完成刷機過程）；如果此時按鍵沒有標明是刷機模式，那麼系統會創建內存檔，開始從ROM裡面載入相應的文件系統，並把相關的文件拷貝到內存檔中，進而引導linux啟動，然後是啟動虛擬機dalvik，然後就是創建工作進程載入和運行framework，然後就會看到待機的畫面。當然在這個過程中還發生了許多事情，啟動了許多服務，為了簡化起見，對於啟動過程偶只講解到此，感興趣的朋友可以自己結合著linux的啟動過程加以對比來學習。
現在來總結一下，實際上刷機包就是一個ROM文件的壓縮包，進入刷機模式後，recovery程序會把刷機包裡面的文件寫入ROM存儲區替換ROM存儲區的原有文件；當下次啟動手機的時候，會從ROM中載入剛剛替換過的文件，並利用這些文件來啟動和運行系統。這就是刷機包的全部功能和作用，看不懂的朋友可以反復看幾次，刷機的本質就是文件的覆蓋和替換操作，偶相信各位一定能看懂！
OK，現在大家已經知道ROM文件的zip壓縮包就是所謂的刷機包。製作刷機包的過程就是准備這些文件，然後重新把這些文件壓縮成一個zip包的過程，在製作的最後，使用簽名工具簽個名，就可以測試和發布刷機包了。雖然說起來就是一句話的事情，但是實際上准備這些文件的過程是非常痛苦和漫長的。
那麼update.zip壓縮包裡面的都包含哪些文件？這些文件又都是如何做出來的呢？hoho，現在開始漸漸接觸到問題的本質了，解壓縮這個update.zip壓縮包以後我們可以看到兩個目錄和一個文件：
boot.img <---文件，這是編譯內核源代碼生成的內核映像，然後與android源碼編譯出來的ramdisk.img一起通過mkbootimg工具創建出來的，圖省事的朋友也可以從網上其他的刷機包裡面拷貝一個能用的出來即可，基本上都差不多。
META-INF <---目錄，這個目錄是手工創建的，主要用來存放一個升級腳本update-script（這個腳本的內容與system目錄中包含的文件有很大關聯）以及保存若干刷機包內的apk文件的簽名。
system <---目錄，這個目錄就是編譯android的平台源代碼生成的，
其實最好的學習方式就是把現在互聯網上的那些update.zip包給解包，然後自己一個一個文件地看和分析，然後修改，嘗試做自己的刷機包。
對於這個boot.img，基本思路是編譯android kernel代碼，生成內核image然後利用mkbootimg感興趣的朋友可以參考下面這兩個wiki網站：
下面的做法偶都是在linux下面完成的（slackware 13.1）：
（1）下載和編譯android的源代碼，具體過程不再贅述
如果各位還不知道repo sync之類的命令的話，可以參考網上的關於下載android源代碼以及編譯的文章，據偶所知這些文章非常豐富。編譯之前一定要注意平台的選擇，不同平台的驅動程序是不一樣的！這些參數可以通過:
$ cd android-src <---進入android的源代碼目錄
$ . build/envsetup.sh <---設置環境變數，運行完畢後，你可以輸入一下help命令，看看google的團隊提供了多少有用的便利命令，這對於我們以後修改代碼重新編譯非常有幫助。
$ lunch generic-eng <---開始配置android的源代碼的編譯選項
運行上述命令後會看到如下輸出：
wayne@wayne:~/android-src$ lunch generic-eng
============================================
PLATFORM_VERSION_CODENAME=REL
PLATFORM_VERSION=2.1-update1
TARGET_PRODUCT=generic
TARGET_BUILD_VARIANT=eng
TARGET_SIMULATOR=false
TARGET_BUILD_TYPE=release
TARGET_ARCH=arm
HOST_ARCH=x86
HOST_OS=linux
HOST_BUILD_TYPE=release
BUILD_ID=ECLAIR
============================================
$ make -j2 <---只有單核的CPU的朋友可以嘗試此參數，雙核的朋友可以試試-j3，否則就老老實實運行make即可。
然後就是一個漫長的等待，這個時間大概有1-2小時左右（偶的機器比較慢），完全編譯完畢以後硬碟的佔用大概需要8個G左右。
（2）編譯完成以後，進入wayne@wayne:~/android-src/out/target/proct/generic目錄，應該會看到如下的文件：
android-info.txt
data
obj
ramdisk.img
sdk
system
userdata.img
clean_steps.mk
installed-files.txt
previous_build_config.mk
root
symbols
system.img
這里的system.img是不是很眼熟？！對拉，這個就是刷機包裡面好像也有一個叫做什麼system的目錄，那麼這個system.img裡面都有什麼呢？這裡面的東西其實就是當前目錄下的一個叫做system的目錄裡面的內容了，只是保存成了yaffs文件系統的格式。我們可以通過unyaffs工具來把system.img給解開來看看，就明白偶說話了。
unyaffs的代碼下載地址為：
在linux下編譯方法非常地簡單，只需要下載源代碼，然後運行：$ gcc -c unyaffs.c
$ gcc -o unyaffs unyaffs.o
即可生成這個unyaffs的解包工具，利用這個工具就可以把自己生成的system.img進行解包，然後修改裡面的內容了。
unyaffs使用方法非常簡單：
$ unyaffs system.img [回車]
即可將system.img解包成一個叫做system的目錄，裡麵包含了整個android的文件系統
（3）剛剛開始，不適合一切從頭來，還是老實一些，先從修改別的大牛們做得刷機包開始吧
首先拷貝一個從網上下載下來的刷機包，然後找一個目錄解壓縮（當然，這是最保險的做法，自己做這些目錄也沒有任何問題，只是比較費時間而已）
$ unzip xxxxxx.zip <--- 這個xxxxx.zip就是從網上下載的某刷機包（一定要跟你的代碼版本基本一致喔，偶在這里用的是2.1的刷機包）
（4）替換原有的system目錄
解壓縮刷機包以後，會看到在開篇的時候提到的兩個目錄，一個文件：
boot.img
META-INF
system
好了，可以把system目錄拷貝到別的路徑下備份一給，防止這些修改發生別的問題。然後把wayne@wayne:~/android-src/out/target/proct/generic這個目錄下面的system拷貝到當前的工作目錄下。注意，這個system目錄裡面有很多「符號鏈接」指向了toolbox。這些鏈接其實沒啥用，可以通過後面的update-script自動進行創建的，因此，需要用一個腳本把這些鏈接都刪掉。
可以參考：
這個網頁附件給出來的DeleteExtras.txt改寫成一個DeleteExtras.sh腳本來清除這些符號鏈接。
（5）修改update-script腳本
修改META-INF/com/google/android目錄下的那個叫做update－script的腳本，只要修改一下即可，主要是刪除一些不存在的文件以及增加一些文件的許可權之類的定義（語法十分清晰，一目瞭然）。把需要「預裝」到刷機包裡面的apk安裝程序都准備好，將這些apk拷貝到system/app目錄下即可。那個boot.img能不改就不改，因為這東西涉及到驅動和內核的問題，出了問題刷機包就啟動不了了。

⑶ android系統 如何要用差分做升級

1、首先是差分包patch的生成。在update.zip中的patch文件夾中有需要與系統文件同名但是以xxx.p 為後綴的文件，就是生成的差分patch文件。OTA系統差分包的製作，使用命令：
./build/tools/releasetools/ota_from_target_files -n -i <舊包> <新包> <差分包名>
在查閱ota_from_target_files 的代碼可知，是在函數WriteIncrementalOTAPackage里生成差分包的，在這個函數里邊創建了common.Difference這個類，繼續跟進，在common.py中的類 class Difference(object):里可以看到：
diff_program = DIFF_PROGRAM_BY_EXT.get(ext, "bsdiff")
2、看到了android中提供用來製作差分增量升級包的工具，在android的代碼目錄下 \external\bsdiff bsdiff是二進制差分工具，其對應的bspatch是相應的補丁合成工具，需要注意的是增量升級的補丁包,是需要在伺服器端，即PC端完成：命令：bsdiff oldfile newfile patchfile。
3、bspatch的命令格式為：bspatch oldfile newfile patchfile。

⑷ Android系統可以升級嗎怎麼升級

安卓系統可以升級，升級過程如下：

下面以升級Android2.3.4為例子，注意：Android2.3.4隻支持從Android2.3.3升級，如果系統是Android2.3.1的話，必須要先升級到Android2.3.3才可以再升級為2.3.4。

另外，這個升級是增量升級，並不會刪除原先系統中的數據，所以大家可以放心升級。

第一步：先要手機下載Android2.3.4的升級數據包，我用的電腦給你搜了一下。

甜點命名法開始於Android 1.5發布的時候。作為每個版本代表的甜點的尺寸越變越大，然後按照26個字母數序：紙杯蛋糕（Android 1.5），甜甜圈（Android 1.6），松餅（Android 2.0/2.1），凍酸奶（Android 2.2），姜餅（Android 2.3），蜂巢（Android 3.0）。

冰激凌三明治（Android 4.0），果凍豆（Jelly Bean，Android4.1和Android 4.2），奇巧（KitKat，Android 4.4），棒棒糖（Lollipop，Android 5.0），棉花糖（Marshmallow，Android 6.0），牛軋糖（Nougat，Android 7.0），奧利奧（Oreo，Android 8.0）。

⑸ 如何打包安卓手機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服務的工作原理。另外詳細分析其升級過程，對於我們在實際升級時，可以根據我們的需要做出相應的修改。

⑹ android開發中有多個依賴包如何打包升級

將所依賴的項目逗放置Plugins/Android下

滿足上訴條件，Unity打包的時候就會自動關聯依賴項目。

注意事項：
1.所有jar不能發生沖突（不能定義有相同的類）
2.各個依賴項目中的AndroidManifest.xml配置不能沖突。（這點Unity會提示的很詳細，改了就好。）
3.下面這個jar一定不能放進項目中，不然會出現很多莫名其妙的錯誤。