文章目錄

• 前言
• 一、種類劃分
• 三、OTA升級log
• 三、OTA包制作
  • full包
  • 差分包
• 總結(jié)

---

前言

OTA(over the air)一種通過空中下載技術(shù)下載升級的方式，指的通常是使用wifi或者數(shù)據(jù)流量的方式從服務(wù)器中將升級包下載到本地升級的一種方式；但是本地使用OTA包的升方式，我們也可以稱之為OTA升級（概念的擴展），簡單理解起來只要是使用制作出來的升級包去升級的過程我們統(tǒng)稱為OTA升級。

一、種類劃分

按升級方式的不同，可分為：在線升級和本地升級

按升級載體的不同，可分為：在線升級、T卡升級、adb升級

按升級包類型不同，可分為：增量(incremental update)升級和整包(full update)升級

命名方式：差分包、增量包、升級包、降級包、整包

1.1 在線升級

在線升級簡單來說，就是將升級包上傳至服務(wù)器端，然后機器通過連接wifi或者數(shù)據(jù)流量從服務(wù)器端將升級包下載到手機中進行升級的一種方式；這種升級方式需要配置對應(yīng)的指紋信息或者IMEI號等，保證手機可搜索到包，以及搜索到包的正確性，這種方式是用戶通常升級版本最常用的方式，整個流程需要經(jīng)過對應(yīng)的服務(wù)器端->framework框架層->recovery升級階段。

1.2 T卡升級

T卡升級其實也可以稱為本地升級，它是將升級包放置到T卡中進行升級的一種方式，通常的T卡升級可以從兩個入口進行升級，分別是：1、正常模式下的設(shè)置模塊自定義的system update升級入口；2、進入recovery模式下選擇”apply update from sdcard”

1.3 sideload升級

adb升級其實也是本地升級的一種，因為升級包都是離線狀態(tài)下取到的，不需要從服務(wù)器端下載，它的方式其實也有兩種：1、正常模式下，保證adb端口正常直接執(zhí)行adb reboot recovery sideload xx/xx/xx.zip；2、recovery模式下，選擇”apply update from adb”菜單后，通過執(zhí)行adb sideload xx/xx/xx.zip命令進行升級。

1.4 升級結(jié)果

1.4.1 關(guān)注升級過程：

在安卓7.0之前，升級的過程谷歌原生UI主要以綠色小機器人作為標記，當然OEM廠商也可以自己design，這種谷歌原生方式在升級過程中如果出現(xiàn)報錯會有小機器人倒下等提示，如果是直接進recovery模式會有l(wèi)og提示升級失敗字樣，這種情況一定可以確定升級失敗（下圖是在項目上找到的升級失敗的截圖，ui同事已經(jīng)對其做了替換，利用這種ui提示代表升級失敗）

1.4.2 關(guān)注升級結(jié)果：

當?shù)谝环N情況已經(jīng)可以確認升級失敗了，那么第二點就不用參考，否則在第一種情況未出現(xiàn)異常后，需要關(guān)注第二點的表現(xiàn)。升級后的結(jié)果主要指的是升級完成后，重啟開機，如果能夠正常開機，再檢查對應(yīng)各項內(nèi)容是否升級成功，比如版本號是否更新、應(yīng)用是否更新等情況。如果升級完成之后，無法開機，可以直接將機器拿到升級模塊負責同事，檢查升級過程是否有異常，如果沒有異常交由開機啟動模式分析為什么無法開機，升級同事負責協(xié)助；如果升級完成后，能夠正常開機，檢查對應(yīng)的版本號等已更新，但是會出現(xiàn)應(yīng)用報錯、或者頁面布局存在異常，需要將問題直接反饋到模塊負責同事

二、OTA升級log

2.1 MTK上層log

適用場景：針對的就是在線升級方式導(dǎo)致的升級失敗或者是本地T卡升級從設(shè)置模塊的system update入口選擇升級導(dǎo)致的升級失敗，對于這兩種方式升級失敗問題，要求升級前打開MTK log進行升級，升級失敗后提供對應(yīng)的MTK LOG，再通俗點理解就是凡是在正常模式下啟動的升級流程都需要提供MTK LOG。

抓取方法：確認版本是否是user版本。userdebug版本和eng版本默認開啟MTK LOG，如果是user版本，可以使用工程指令：調(diào)出log界面，選擇啟動即可。默認將mtklog存放到內(nèi)置sdcard里面去了，其實如果你插入外置T卡，也可以選擇將log保存在外置T卡里面，除此之外還可以選擇保存哪些log，假設(shè)是保存在內(nèi)置T卡里面，可以使用MTP的方式拷貝MTKlog出來或者是執(zhí)行命令：adb pull /sdcard/mtklog d:mtklog\即可，存放的地方可以自己定義，抓取后再出現(xiàn)異常后，提供給研發(fā)同事。

2.2 Recovery升級log

解釋：主要指的就是升級過程中打印出來的log，該log是進入recovery模式后打印出來的，與正常模式下的mtklog是完全不同的，存放于cache分區(qū)中，需要單獨抓取。

適用場景：任何升級失敗場景

抓取方法1：進人recovery模式提供log截圖，操作方法是進人recovery界面，或者當前已處在recovery模式下的時候，找到下面的菜單位置，按power鍵進入，進入后發(fā)現(xiàn)會有下面截圖所示，有l(wèi)ast_log和last_kmsg字樣，對于簡單的升級來說，只需要進入last_log，按音量下鍵往下翻頁，直到看到類似failed字樣，或者是進度條拉到大概90%到100%左右處截圖提供，有些時候last_log會不止一個，有l(wèi)ast_log1/last_log2等，這個時候需要測試同事同時關(guān)注下last_log和last_log1。

抓取方法2：提供cache分區(qū)，這種方式可以提供更全的升級log，需要掌握下載工具dump cache分區(qū)的操作。

2.3 cache分區(qū)dump流程

A、打開工具界面后，選擇ReadBackA、打開工具界面后，選擇ReadBack

B、選擇ReadBack后會看到下面的截圖界面，按照提示選擇Add

C、選擇 Add之后，會出現(xiàn)下面截圖所示界面，雙擊截圖位置

D、雙擊之后會彈出一個框，需要填寫鏡像文件的名稱和存放位置，保存

E、保存按鈕點擊后，會再次彈出新的框，如下所示，最關(guān)鍵的地方也是在這里，這里需要填寫dump的鏡像文件的起始地址和size大小，一開始默認都是全0

F、鏡像文件的起始地址和長度可以從下載版本中的scatter.txt里面獲取，如dump cache分區(qū)，就需要找到cache分區(qū)所在位置，填寫如下兩個值到對應(yīng)上面的框圖中

G、填寫后，就如下圖所示，點擊OK按鈕

H、 配置完成后，就可以點擊Read Back按鈕，成灰顯狀態(tài)后，手機關(guān)機插USB，即可完成分區(qū)的dump過程，最終dump完成后如下截圖所示，從之前存放的位置選擇dump出來的cache.img提供即可

三、OTA包制作

3.1 full包編譯

方式1：

A、執(zhí)行source tran_setenv.sh xx user/userdebug/eng efuse

B、編譯整個工程，執(zhí)行make -j24 2>&1 | tee build.log

C、簽名鏡像文件，執(zhí)行./vendor/mediatek/proprietary/scripts/sign-image/sign_image.sh【重點：這一步一定要先操作】

D、執(zhí)行做包指令，make otapackage -j24 2>&1 | tee ota.txt，按照正常的這種流程操作完畢后，會在對應(yīng)的項目路徑下面生成對應(yīng)的full包

方式2：

A、make otapackage命令除了是生成full包之外，還會在對應(yīng)的該目錄下生成target_files目錄，如果沒有執(zhí)行make otapackage這一命令，是不會有該目錄的，該目錄下面的zip包也是用來制作差分包的基礎(chǔ)版本

B、有了上述的target包之后，就可以直接通過調(diào)用腳本指令制作full包，執(zhí)行： ./build/tools/releasetools/ota_from_target_files -k vendor/commonconfig/security/releasekey -s vendor/mediatek/proprietary/scripts/releasetools/mt_ota_from_target_files.py full_xx-target_files-xx.zip Tcard.zip

3.2 full包生成

build/core/Makefile：

定義了一個偽目標otapackage，它依賴于INTERNAL_OTA_PACKAGE_TARGET，而該文件就是制作OTA整包最后的生成文件，它的命名方式如下，生成位置在PRODUCT_OUT目錄下，命名為$(name).zip，而name是等于$(name)-ota-$(FILE_NAME_TAG)，主要有三部分組成：TARGET_PRODUCT，這個在一開始source的時候就會確定，TARGET_BUILD_TYPE一般情況下都是定義成release，FILE_NAME_TAG這個變量在main.mk里面有定義，會根據(jù)HAS_BUILD_NUMBER宏來進行區(qū)分，最后本地生成的整包名字

BUILT_TARGET_FILES_PACKAGE的生成： 它是生成整包所需的中間文件。最后生成位置位于路徑out\target\product\xx\obj\PACKAGING\target_files_intermediates\xx-target_files-xx.zip

（1）清理以前殘存的目錄和文件，并創(chuàng)建$(zip_root)目錄，即對應(yīng)的out\target\product\xx\obj\PACKAGING\target_files_intermediates\<product>-target_files-xx

（2）創(chuàng)建$(zip_root)/RECOVERY目錄，把out/target/product/xx/recovery/root下的所有文件和目錄拷貝到$(zip_root)/RECOVERY，還有out/target/product/xx目錄下的其它目錄文件如cmdline/second/kernel等到對應(yīng)的$(zip_root)/RECOVERY目錄下

（3）創(chuàng)建$(zip_root)/BOOT目錄，并拷貝對應(yīng)的內(nèi)容到該目錄下，同 recovery，后面類似的還會創(chuàng)建SYSTEM/RADIO/VENDOR/OTA/META等目錄，其中需要重點關(guān)注的是META和OTA目錄，META目錄下面會生成很多txt文件，這些文件對于制作升級包會強相關(guān)，OTA目錄下面主要是包含了升級過程中需要的升級函數(shù)實現(xiàn)的可執(zhí)行文件

…………………… ……………………

ota_from_target_files.py腳本

(1) main函數(shù)參數(shù)解析

(2) 從中間的zip包里面的META/misc_info.txt中 解析出對應(yīng)的參數(shù)，例如key,tool_extensions等，OPTIONS.extracted_input就是前面Makefile中通過” --extracted_input_target_files”指定的target中間包，其中解析的misc_info.txt里面的內(nèi)容主要是賦給OPTIONS.info_dict；

(3) 從OPTIONS對里找到tool_extensions賦值給OPTIONS.device_specific，這是假定如果沒有指定”-s”參數(shù)的話，如果指定了就直接從指定的py腳本中獲取

(4) input_zip為上文中的zip包，out_zip為最終生成的臨時zip包，對于整包的話會調(diào)用WriteFullOTAPackage(input_zip, ?output_file=args[1])函數(shù)來生成

(5)調(diào)用SignOutput簽名臨時包，生成最終的全包升級包

?WriteFullOTAPackage函數(shù)實現(xiàn)

(1) 生成Edify腳本，主要在EdifyGenerator.py里面實現(xiàn)，在這里面實現(xiàn)的都是各種升級過程中的處理命令，寫到對應(yīng)的update-script腳本里面

(2) 調(diào)用GetPackageMetadata函數(shù)獲取對應(yīng)的元數(shù)據(jù)內(nèi)容，最后會將這些內(nèi)容寫到升級包里面

(3) 獲取對應(yīng)的版本里面的編譯時間，為日后升級過程中做校驗使用，也就是說T卡包在升級的時候是會校驗時間戳的，它不允許后往后倒退升級

(4)設(shè)置對應(yīng)的進度條處理腳本，通過script的ShowProgress實現(xiàn)

（5）獲取boot分區(qū)內(nèi)容，對system和vendor分區(qū)進行處理生成對應(yīng)升級所需內(nèi)容，其中AddCompatibilityArchiveIfTrebleEnabled主要是將system和vendor下面的一些 xml文件寫入升級包中，這些xml文件是treble使能后新增的，主要用于升級過程中校驗，在升級過程中會獲取手機里面的信息與之作比較

（6）對boot分區(qū)進行整個鏡像的內(nèi)容寫入，在升級過程中會整個覆蓋寫入boot分區(qū)

（7）preloader、lk、modem等其它特殊分區(qū)的處理

releasetools.py腳本

A、根據(jù)是否是整包往升級包中type.txt里面寫入對應(yīng)的值，讀取OTA目錄下面的ota_update_list.txt內(nèi)容寫入到scatter.txt里面，放入升級包中，對于type.txt文件最后升級的時候其實并沒有應(yīng)用到，但是scatter.txt里面在升級過程中會有用到

B、check-bootloader_path函數(shù)主要針對preloader做處理，它會判斷對應(yīng)的存儲芯片類型是否是ufs，通過ro.vendor.mtk_ufs_support=1宏來決定，這樣做的目的是因為ufs和emmc對應(yīng)的preloader的設(shè)備路徑是不同的，如果不做區(qū)分升級preloader分區(qū)的時候就存在問題

C、AddOTAImage_Items函數(shù)就是真正對除常用分區(qū)外其他分區(qū)進行處理的關(guān)鍵部分，它會讀取ota_update_list.txt里面待升級的分區(qū)，然后根據(jù)不同類型進行區(qū)分，最終寫入到升級包中腳本中，主要就是區(qū)分兩類，其中dtbo md1img spmfw vbmeta作為一類，直接寫入對應(yīng)的設(shè)備路徑；sspm tee scp preloader需要同時寫入對應(yīng)的源和備份設(shè)備路徑，也就是所定義的1和2

（8）判斷是否有額外腳本選項指定，以及判斷是否指定了擦除用戶數(shù)據(jù)，也就是-w，如果指定了的話，調(diào)用script的FormatPartition函數(shù)對data分區(qū)進行格式化的寫命令處理

（9）調(diào)用FinalizeMetadata函數(shù)進行處理，這里面會將metadata文件寫入升級包中的META-INF/com/android/metadata位置，再調(diào)用SignOutput函數(shù)完成版本的簽名操作，最終到此完成這個升級包的制作

3.3?差分包編譯

所謂的差分包，其實就是使用兩個版本之間的差異生成一種只針對差異化更新的增量升級包，這種升級包與full包的不同之處在于它更小，而差異化的地方多通過patch的方式升級，升級速度更快，對于手機所要求的存儲空間低。要生成差分包，就需要有兩個不同版本的target文件，因此上述full包的操作流程需要在兩個版本間都執(zhí)行過一次，獲取到最終兩個版本間的target文件，再通過target文件進行差分操作。

編譯命令： ./build/tools/releasetools/ota_from_target_files -k vendor/commonconfig/security/releasekey -s vendor/mediatek/proprietary/scripts/releasetools/mt_ota_from_target_files.py -i full_xx-target_files-xx.zip full_xxx-target_files-xxx.zip Increment-ota.zip

差分包的命令目前O版本和P版本存在差異：

O版本：. ./build/tools/releasetools/ota_from_target_files -k vendor/commonconfig/security/releasekey -s vendor/mediatek/proprietary/scripts/releasetools/mt_ota_from_target_files -i V1.zip V2.zip update.zip

P版本：./build/tools/releasetools/ota_from_target_files -k vendor/commonconfig/security/releasekey -i V1.zip V2.zip update.zip 接下來就上述指令簡單分析下差分包的生成流程，其中”藍色字體”表示選項可添加也可不添加，”紅色參數(shù)”表示必須添加。同full包一樣，差分包的生成也主要是通過ota_from_target_files.py腳本生成，只不過在處理的地方稍有差異。

3.4 差分包生成

main主函數(shù)執(zhí)行過程：

（1）從參數(shù)和環(huán)境中解析OPTIONS，同full包，前面提到過”-k”參數(shù)是可有可無的，但是如果指定的話，就會將指定的路徑key賦給OPTIONS.package_key，同時如果指定了”-i”參數(shù)就將后面跟著的版本賦給OPTIONS.incremental_source

（2）加載讀取升級包中的misc_info.txt里面的內(nèi)容，同上full包，只不過相較于full包，它這個工作需要做兩次，會同時獲取源target和目標target分別賦給OPTIONS.target_info_dict以及OPTIONS.info_dict后面在升級包處理過程中都會用到

（3）調(diào)用common.py腳本里面的UnzipTemp解壓函數(shù)解壓target zip文件，同時也會載入對應(yīng)是device_specific腳本，如果沒有通過-s命令指定的話，就會默認從META目錄下面獲取，將releasetools.py作為默認腳本

（4）再次解壓source zip，調(diào)用WriteBlockIncrementalOTAPackage腳本實現(xiàn)差分包的處理

WriteBlockIncrementalOTAPackage執(zhí)行流程：

（1）生成Edify腳本，主要在EdifyGenerator.py里面實現(xiàn)，在這里面實現(xiàn)的都是各種升級過程中的處理命令，寫到對應(yīng)的update-script腳本里面

（2）獲取對應(yīng)的源和目標boot內(nèi)容，主要是從IMAGES/目錄下獲取對應(yīng)的boot.img內(nèi)容，同時獲取對應(yīng)的目標recovery內(nèi)容

（3）調(diào)用common.py腳本的GetSparseImage函數(shù)獲取對應(yīng)的system內(nèi)容中的block數(shù)據(jù)，源target和目標target都要獲取分別賦給system_src和system_tgt，最后調(diào)用common.py腳本中的BlockDifference類對其進行差異化block處理，最終調(diào)用的是blockimgdiff.py里面的BlockImageDiff函數(shù)，這里面集成的都是基于bsdiff的算法

（4）接下來針對vendor分區(qū)的處理過程，它的處理方式和system分區(qū)一樣，只不過執(zhí)行的時候會首先判斷是否存在分區(qū)，由于block的升級在安卓6.0就支持了，而當時其實谷歌對于treble這塊還未有介紹，所以vendor分區(qū)作為一個非必須存在分區(qū)，主要由芯片廠商或者手機廠商自行決定，而谷歌的代碼則會照顧到vendor分區(qū)有或者無的情況，因此添加了是否存在vendor分區(qū)的判斷，這個判斷一直沿用至今也沒有去掉

（5）接下來會調(diào)用WriteFingerprintAssertion函數(shù)獲取對應(yīng)的fingerprint寫入腳本中，升級過程中會去校驗該屬性，同時會根據(jù)system和vendor在差分過程中所要求的cache size大小追加到size列表里面，后面會將要求的值寫入到對應(yīng)的metadata里面，在升級過程中也會檢測cache分區(qū)空間的剩余大小是否滿足要求

（6）接下來對boot分區(qū)進行處理，會去計算source boot 和target boot之間的差異性，如果差異太大導(dǎo)致出錯就會將boot分區(qū)作為整個鏡像文件升級處理，反之則會直接根據(jù)source和target的boot.img進行差分生成boot.img.p寫入到升級包中，升級的時候就會將boot分區(qū)做patch升級，在升級前還是會做patch check的動作，檢查手機版本中的哈希是否滿足要求，如果不一致則報錯處理，這就要求升級包的制作一定要是下載到手機中的源版本和另一個目標版本之間的差分

（7）對于非主要的ap側(cè)分區(qū)以及引導(dǎo)分區(qū)的升級都在對應(yīng)的device_specific腳本里面的IncrementalOTA_InstallEnd里面完成，這個過程前面在full包中有介紹，過程類似，差異性也有但是不多，感興趣可以自己去看代碼，不作重復(fù)介紹（7）對于非主要的ap側(cè)分區(qū)以及引導(dǎo)分區(qū)的升級都在對應(yīng)的device_specific腳本里面的IncrementalOTA_InstallEnd里面完成，這個過程前面在full包中有介紹，過程類似，差異性也有但是不多，感興趣可以自己去看代碼，不作重復(fù)介紹

（8）和full包不同之處還有一點，它支持所謂的降級處理，也就是制作升級包的時候指定--downgrade參數(shù)，指定該參數(shù)可以允許你升級到一個比你源版本時間舊的版本，但是一個重要影響它會擦除data分區(qū)，即用戶數(shù)據(jù)，所以該選項慎用

（9）最后一步也是和full包一樣，需要對其進行簽名操作，實現(xiàn)同上full包具體過程也可以查看FinalizeMetadata的實現(xiàn)

簽名命令：

java -Xmx2048m -Djava.library.path=out/host/linux-x86/lib64 -jar out/host/linux-x86/framework/signapk.jar -w vendor/tran_os/security/releasekey.x509.pem vendor/tran_os/security/releasekey.pk8 /tmp/tmpMvN4L7 out/target/product/ka7_h8024/full_ka7_h8024-ota-1542863682.zip

---

總結(jié)

對于初學(xué)者，此文章可以幫忙快速掃盲，當然任何技術(shù)上的精進都是建立在基礎(chǔ)之上。如果一些簡單的名詞或者說法都不清楚，一切都是空談。了解此篇后，就可以更深層次的學(xué)習(xí)，加油，未來可期！

總結(jié)

以上是生活随笔為你收集整理的OTA-扫盲的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。