前言

2013年7月至2015年6月在長虹擔任Android系統研發工程師，主要負責長虹智慧電視升級（OTA升級），研發平臺是MST 628 和 MTK 5327等。

摘要

隨著Android系統的快速發展，越來越多的智慧終端裝置搭載Android平臺。Android系統升級的可以優化智慧電視系統性能、更新系統內容。因此，Android系統升級在Android系統開發領域極其重要。如何保證Android系統升級的安全性、可靠性與可操作性。本文詳細介紹了Android系統升級包的製作、Recovery模式的工作原理，TV終端升級包的下載、升級包的具體升級過程等。

一、 Android系統升級概述

Android系統升級的本質是對system、perm、data分割槽下的檔案進行升級，按照升級包的差異來分可以分為整包升級與查分升級。整包升級首先將分割槽格式化，然後將升級包中的檔案拷貝進去。差分升級則只升級檔案的差異部分。如圖（1.1）所示，系統升級主要包括升級包的製作與釋出、終端升級包的下載以及Recovery模式下的具體升級幾個過程。本文分九個部分講述Android系統的系統升級。

第一部分是系統概述；
第二部分講述Recovery模式，包括如何進入Recovery模式，進入Recovery模式後的操作以及Recovery模式的通訊介面；
第三部分主要講述升級包的製作；
第四部分講述TV終端升級包的獲取及升級策略；
第五部分講述Android系統的三種啟動模式；
第六部分講述Android系統的模式服務；
第七部分講述從reboot到Recovery；
第八部分講述 Recovery服務的核心install_package函式；
第九部分講述升級程式update_binary的執行過程。

圖1-1

二、Recovery模式

2.1 Recovery模式中的三個部分
Recovery的工作需要整個軟體平臺的配合，從通訊架構上來看，主要有三個部分。
1） MainSystem：即正常啟動模式（BCB中無命令），是用boot.img啟動的系統，Android的正常工作模式。更新時，在這種模式中我們的上層操作就是使用OTA或則從SD卡中升級升級包。在重啟進入Recovery模式之前，會向BCB中寫入命令，以便在重啟後告訴bootloader進入Recovery模式。
2） Recovery：系統進入Recovery模式後會裝載Recovery分割槽，該分割槽包含recovery.img（同boot.img相同，包含了標準的核心和根檔案系統）。進入該模式後主要是執行 Recovery服務（/sbin/recovery）來做相應的操作（重啟、升級升級、擦除cache分割槽、擦除data分割槽等）。
3） Bootloader：除了正常的載入啟動系統之外，還會通過讀取MISC分割槽（BCB）獲得來至Main system和Recovery的訊息。
2.2 Recovery模式中的兩個通訊介面
在Recovery服務中上述的三個實體之間的通訊是必不可少的，他們相互之間又有以下
兩個通訊介面。
通過CACHE分割槽中的三個檔案：
1） Recovery通過/cache/recovery/目錄下檔案與Mainsystem進行通訊，過程如下 ：
/cache/recovery/command：這個檔案儲存著Main system傳給Recovery的命令列。 –update_package=root:path： Main system將這條命令寫入時，代表系統需要升級，進入Recovery模式後，將該檔案中的命令讀取並寫入BCB中，然後進行相應的更新升級包的操作。
–wipe_data：擦除使用者資料。擦除data分割槽時必須要擦除cache分割槽。
–wipe_cache： 擦除cache分割槽。
2）通過BCB（Bootloader Control Block）：
BCB是bootloader與Recovery的通訊介面，也是Bootloader與Main system之間的通訊介面。儲存在flash中的MISC分割槽，佔用三個page，其本身就是一個結構體，具體成員 以及各成員含義如下：
struct bootloader_message{
char command[32];
char status[32];
char recovery[1024];
};
command成員：即當我們想要在重啟進入Recovery模式時，會更新這個成員的值。另外在成功更新後結束Recovery時，會清除這個成員的值，防止重啟時再次進入Recovery模式。
status：在完成相應的更新後，Bootloader會將執行結果寫入到這個欄位。
recovery：可被Main System寫入，也可被Recovery服務程式寫入。該檔案內容格式為：
“recovery\n
\n
”
該檔案儲存的就是一個字串，必須以recovery\n開頭，否則這個欄位的所有內容域會被忽略。“recovery\n”之後的部分，是/cache/recovery/command支援的命令。可以將其理解為Recovery操作過程中對命令操作的備份。Recovery對其操作的過程為：先讀取BCB然後讀取/cache/recovery/command，然後將二者重新寫回BCB，這樣在進入Main system之前，確保操作被執行。在操作之後進入Main system之前，Recovery又會清空BCB的command域和recovery域，這樣確保重啟後不再進入Recovery模式。
2.3 從Main System重啟並進入Recovery模式
如圖（2.1）所示為以上三個部分的通訊過程

圖（2.1）

首先從Main System開始，在Main System使用升級包進行升級時，系統會重啟並進入Recovery模式。在系統重啟之前，Main System定會向BCB中的command域寫入boot-recovery(粉紅色線)，用來告知Bootloader重啟後進入recovery模式。這一步是必須的。至於Main System是否向recovery域寫入值我們在原始碼中不能肯定這一點。即便如此，重啟進入Recovery模式後Bootloader會從/cache/recovery/command中讀取值並放入到BCB的recovery域。而Main System在重啟之前肯定會向/cache/recovery/command中寫入Recovery將要進行的操作命令。

3、升級包的製作

3.1 升級包的目錄結構

|—-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

以上是用命令make otapackage 製作的升級包的標準目錄結構。

1）boot.img是更新boot分割槽所需要的檔案。這個boot.img主要包括kernel+ramdisk。
2）system/目錄的內容在升級後會放在系統的system分割槽。主要用來更新系統的一些應用或則應用會用到的一些庫等等。
3）recovery/目錄中的recovery-from-boot.p是boot.img和recovery.img的補丁(patch)，主要用來更新recovery分割槽，其中etc/目錄下的install-recovery.sh是更新指令碼。
4）update-binary是一個二進位制檔案，相當於一個指令碼直譯器，能夠識別updater-script描述的操作。
5）updater-script：此檔案是一個指令碼檔案，具體描述了更新過程。我們可以根據具體情況編寫該指令碼來適應我們的具體需求。
6） metadata檔案是描述裝置資訊及環境變數的元資料。主要包括一些編譯選項，簽名公鑰，時間戳以及裝置型號等。
7）我們還可以在包中新增userdata目錄，來更新系統中的使用者資料部分。這部分內容更新後會存放在系統的/data目錄下。
8）升級包的簽名：升級更新包在製作完成後需要對其簽名，否則在升級時會出現認證失敗的錯誤提示。而且簽名要使用和目標板一致的加密公鑰。加密公鑰及加密需要的三個檔案在Android原始碼編譯後生成的具體路徑為：
out/host/linux-x86/framework/signapk.jar
build/target/product/security/testkey.x509.pem
build/target/product/security/testkey.pk8 。
命令make otapackage製作生成的升級包是已簽過名的，如果自己做升級包時必須手動對其簽名。 以上命令在升級包所在的路徑下執行，其中signapk.jar testkey.x509.pem以及testkey.pk8檔案的引用使用絕對路徑。升級 是我們已經打好的包，update_signed.zip包是命令執行完生成的已經簽過名的包。
9）MANIFEST.MF：這個manifest檔案定義了與包的組成結構相關的資料。類似Android應用的mainfest.xml檔案。
10）CERT.RSA：與簽名檔案相關聯的簽名程式塊檔案，它儲存了用於簽名JAR檔案的公共簽名。
11）CERT.SF：這是JAR檔案的簽名檔案，其中字首CERT代表簽名者。

四、TV終端的升級包獲取及升級策略

4.1 功能
TV終端升級包是由終端升級程式upgradesystem.apk控制的，如圖（4.1）所示，該程式完成一下主要功能：
1） 後臺下載策略檔案，依據策略檔案判斷是否需要升級，採用差分還是整包級；
2） 斷點續傳下載需要的系統升級包，並進行checksum校驗確保其下載的正確性；
3） 檔案校驗功能，對下載的升級包進行校驗，確保下載檔案的正確性。
4） Recovery升級功能，需要recovery升級時，寫入recovery升級標識。
5） 寫入cache/recovery/command命令，便於下次重啟時升級；

五、Android系統中三種啟動模式

5.1 Android系統啟動後可能進入的模式有以下幾種
1) MAGIC KEY（組合鍵）：即使用者在啟動後通過按下組合鍵，進入不同的工作模式，具體有兩種：
Vol+ + Power ：若使用者在啟動剛開始按了Vol+ + Power組合鍵，系統會直接進入Recovery模式。以這種方式進入Recovery模式時系統會進入一個簡單的UI（使用了minui）介面，用來提示使用者進一步操作。有如下幾種操作選項：
“reboot system now”
“apply update from sdcard”
“wipe update from cache”
“wipe cache”
“wipe data”
2) 正常啟動：若啟動過程中使用者沒有按下任何組合鍵，bootloader會讀取位於MISC分割槽的啟動控制資訊塊BCB（Bootloader Control Block）。它是一個結構體，存放著啟動命令command。根據不同的命令，系統又 可以進入三種不同的啟動模式。這個結構體的定義。
struct bootloader_message{
char command[32]; //存放不同的啟動命令
char status[32]; //update-radio或update-hboot完成存放執行結果
char recovery[1024]; //存放/cache/recovery/command中的命令
};

command可能的值有兩種， command==”boot-recovery”時，系統會進入Recovery模式。Recovery服務會具體根據/cache/recovery/command中的命令執行相應的操作（例如，升級升級或擦除cache，data等）。command為空時，即沒有任何命令，系統會進入正常的啟動，最後進入主系統（main system）。這種是最通常的啟動流程。
Android系統不同的啟動模式的進入是在不同的情形下觸發的，從SD卡中升級升級時會進入Recovery模式是其中一種，其他的比如：系統崩潰，或則在命令列輸入啟動命令式也會進入Recovery或其他的啟動模式。

六、Recovery模式服務

升級包來源有兩種，一個是OTA線上下載，一個是手動拷貝到SD卡或者U盤中。不論是哪種方式獲得升級包，在進入Recovery模式前，都未對這個zip包做處理。只是在重啟之前將zip包的路徑告訴了Recovery服務下面具體分析這種升級方式下， 升級是怎樣從上層一步步進入到Recovery模式的。
6.1、從updatesystem應用到Reboot
當我們依次選擇工具箱–>支援–>系統升級–>線上升級後會彈出一個對話方塊，提示已有升級包是否現在更新
1) 如果使用者選擇立即更新，後臺下載升級包升級，將升級包儲存到/cache目錄下。
2) 升級檔案下載完成後，在Android下對升級包進行sha1正確行校驗。校驗通過後，呼叫了pm.reboot(“recovery”)函式，這個函式只將“recovery”引數傳遞過去了，之後將“boot-recovery”寫入到了MISC分割槽的BCB資料塊的command域中。這樣在重啟之後Bootloader才知道要進入Recovery模式。
至此，Main System就開始重啟並進入Recovery模式。在這之前Main System做的最實質的就是兩件事，一是將“boot-recovery”寫入BCB的command域，二是將–update_package=/cache/升級”寫入/cache/recovery/command檔案中。下面的部分就開始重啟並進入Recovery服務了。

6.2從reboot到Recovery服務
從Bootloader開始如果沒有組合鍵按下，就從MISC分割槽讀取BCB塊的command域（在主系統時已經將“boot-recovery”寫入）。然後就以Recovery模式開始啟動。與正常啟動不同的是Recovery模式下載入的映象是recovery.img。這個映象同boot.img類似，也包含了標準的核心和根檔案系統。其後就與正常的啟動系統類似，也是啟動核心，然後啟動檔案系統。在進入檔案系統後會執行/init，init的配置檔案就是/init.rc。這個配置檔案來自bootable/recovery/etc/init.rc。這個檔案做了如下幾件事情。
1）設定環境變數。
2）建立etc連線。
3）新建目錄，備用。
4）掛載/tmp為記憶體檔案系統tmpfs
5）啟動recovery（/sbin/recovery）服務。
6）啟動adbd服務(用於除錯)。

七、從reboot到Recovery服務

7.1 Recovery服務的通用流程
從recovery.c的main函式開始：
1） ui_init()：Recovery服務使用了一個基於framebuffer的簡單ui（miniui）系統。這個函式對其進行了簡單的初始化。在Recovery服務的過程中主要用於顯示一個背景圖片和一個進度條。另外還啟動了兩個執行緒，一個用於處理進度條的顯示，另一個用於響應使用者的按鍵。
2） get_arg()：這個函式主要做了上圖中get_arg()往右往下直到parse arg/v的工作。
get_bootloader_message()：主要工作是根據分割槽的檔案格式型別（mtd或emmc）從MISC分割槽中讀取BCB資料塊到一個臨時的變數中。然後開始判斷Recovery服務是否有帶命令列的引數（/sbin/recovery，根據現有的邏輯是沒有的），若沒有就從BCB中讀取recovery域。如果讀取失敗則從/cache/recovery/command中讀取然後。這樣這個BCB的臨時變數中的recovery域就被更新了。在將這個BCB的臨時變數寫回真實的BCB之前，又更新的這個BCB臨時變數的command域為“boot-recovery”。這樣做的目的是如果在升級失敗（比如升級還未結束就斷電了）時，系統在重啟之後還會進入Recovery模式，直到升級完成。在這個BCB臨時變數的各個域都更新完成後使用set_bootloader_message()寫回到真正的BCB塊中。
3) parserargc/argv：解析我們獲得引數。註冊所解析的命令（，在下面的操作中會根據這一步解析的值進行一步步的判斷，然後進行相應的操作。
4) if(update_package)：判斷update_package是否有值，若有就表示需要升級更新包，此時就會呼叫install_package()。在這一步中將要完成安裝實際的升級包。這是最為複雜，也是升級升級包最為核心的部分。
5) if(wipe_data/wipe_cache)：這一步判斷實際是兩步，在原始碼中是先判斷是否擦除data分割槽（使用者資料部分）的，然後再判斷是否擦除cache分割槽。
6) maybe_install_firmware_update()：如果升級包中包含/radio/hboot firmware的更新，則會呼叫這個函式。
7) prompt_and_wait()：這個函式是在一個判斷中被呼叫的。其意義是如果安裝失敗，則等待使用者的輸入處理。
8) finish_recovery()：這是Recovery關閉並進入Main System的必經之路。其大體流程如下：

將intent（字串）的內容作為引數傳進finish_recovery中。如果有intent需要告知Main System，則將其寫入/cache/recovery/intent中。將記憶體檔案系統中的Recovery服務的日誌（/tmp/recovery.log）拷貝到cache（/cache/recovery/log）分割槽中，以便告知重啟後的Main System發生過什麼。擦除MISC分割槽中的BCB資料塊的內容，以便系統重啟後不在進入Recovery模式而是進入更新後的主系統。刪除/cache/recovery/command檔案。這一步也是很重要的，因為重啟後Bootloader會自動檢索這個檔案，如果未刪除的話又會進入Recovery模式。原理在上面已經講的很清楚了。
9) reboot()：這是一個系統呼叫。在這一步Recovery完成其服務重啟並進入Main System。這次重啟和在主系統中重啟進入Recovery模式呼叫的函式是一樣的，但是其方向是不一樣的。所以引數也就不一樣。

八、 Recovery服務的核心install_package函式

  install_package()是升級升級特有的一部分，也是最核心的部分。在這一步才真正開始對升級包進行處理。下面就開始分析這一部分。如圖（8.1）所示：

下面順著上面的流程圖和原始碼來分析這一流程：
1）ensure_path_mount()：先判斷所傳的升級包路徑所在的分割槽是否已經掛載。如果沒有則先掛載。
2）load_keys()：載入公鑰原始檔，路徑位於/res/keys。這個檔案在Recovery映象的根檔案系統中。
3）verify_file()：對升級包升級包進行簽名驗證。
4）mzOpenZipArchive()：開啟升級包，並將相關的資訊拷貝到一個臨時的ZipArchinve變數中。這一步並未對我們的升級包解壓。
5）try_update_binary()：在這個函式中才是對我們的升級升級的地方。這個函式一開始先根據我們上一步獲得的zip包資訊，以及升級包的絕對路徑將update_binary檔案拷貝到記憶體檔案系統的/tmp/update_binary中。以便後面使用。
6）pipe()：建立管道，用於下面的子程序和父程序之間的通訊。
7）fork()：建立子程序。其中的子程序主要負責執行binary（execv(binary,args)，即執行我們的安裝命令指令碼），父程序負責接受子程序傳送的命令去更新ui顯示（顯示當前的進度）。子父程序間通訊依靠管道。
8）其中，在建立子程序後，父程序有兩個作用。一是通過管道接受子程序傳送的命令來更新UI顯示。二是等待子程序退出並返回INSTALL SUCCESS。其中子程序在解析執行安裝指令碼的同時所傳送的命令有以下幾種：
execv(binary,args)的作用就是去執行binary程式，這個程式的實質就是去解析升級包中的updater-script指令碼中的命令並執行。由此，Recovery服務就進入了實際安裝升級包的過程。

九、升級程式update_binary的執行過程

子程序所執行的程式binary為升級包中的update-binary。Recovery服務在做這一部分工作的時候是先將包中update-binary拷貝到記憶體檔案系統中的/tmp/update_binary，然後再執行的。
分析下這個程式的執行過程：
1）函式引數以及版本的檢查。
2）獲取管道並開啟：在執行此程式的過程中向該管道寫入命令，用於通知其父程序根據命令去更新UI顯示。
3）讀取updater-script指令碼：從升級包中將updater-script指令碼讀到一塊動態記憶體中，供後面執行。
4）Configure edify’s functions：註冊指令碼中的語句處理函式，即識別指令碼中命令的函式。主要有以下幾類
RegisterBuiltins()：註冊程式中控制流程的語句，如ifelse、assert、abort、stdout等。
RegisterInstallFunctions()：實際安裝過程中安裝所需的功能函式，比如mount、format、set_progress、set_perm等。
RegisterDeviceExtensions()：與裝置相關的額外新增項，在原始碼中並沒有任何實現。
FinishRegistration()：結束註冊。
5）Parsethe script：呼叫yy*庫函式解析指令碼，並將解析後的內容存放到一個Expr型別的python類中。主要函式是yy_scan_string()和yyparse()。
6）執行指令碼：核心函式是Evaluate（），它會呼叫其他的callback函式，而這些callback函式又會去呼叫Evaluate去解析不同的指令碼片段，從而實現一個簡單的指令碼直譯器。
7）錯誤資訊提示：最後就是根據Evaluate（）執行後的返回值，給出一些列印資訊。