本文轉載自：https://blog.csdn.net/guyongqiangx/article/details/71334889
Android從7.0開始引入新的OTA升級方式，A/B System Updates，這里將其叫做A/B系統。
版權聲明：
本文為guyongqiangx原創，歡迎轉載，請注明出處：
Android A/B System OTA分析（一）概覽： http://blog.csdn.net/guyongqiangx/article/details/71334889
A/B系統涉及的內容較多，分多篇對A/B系統的各個方面進行分析。本文為第一篇，概覽。
1. A/B系統的特點
顧名思義，A/B系統就是設備上有A和B兩套可以工作的系統（用戶數據只有一份，為兩套系統共用），簡單來講，可以理解為一套系統分區，另外一套為備份分區。其系統版本可能一樣；也可能不一樣，其中一個是新版本，另外一個舊版本，通過升級，將舊版本也更新為新版本。當然，設備出廠時這兩套系統肯定是一樣的。
之所以叫套，而不是個，是因為Android系統不是由一個分區組成，其系統包括boot分區的kernel和ramdisk，system和vendor分區的應用程序和庫文件，以及userdata分區的數據
A/B系統實現了無縫升級(seamless updates)，有以下特點：
出廠時設備上有兩套可以正常工作的系統，升級時確保設備上始終有一個可以工作的系統，減少設備變磚的可能性，方便維修和售后。
OTA升級在Android系統的后台進行，所以更新過程中，用戶可以正常使用設備，數據更新完成后，僅需要用戶重啟一次設備進入新系統
如果OTA升級失敗，設備可以回退到升級前的舊系統，並且可以嘗試再次更新升級。
Android 7.0上傳統OTA方式和新的A/B系統方式都存在，只是編譯時只能選擇其中的一種OTA方式。由於A/B系統在分區上與傳統OTA的分區設計不一樣，二者無法兼容，所以7.0以前的系統無法通過OTA方式升級為A/B系統。
啰嗦一下7.0以前傳統的OTA方式：
設備上有一個Android主系統和一個Recovery系統，Android主系統運行時檢測是否需要升級，如果需要升級，則將升級的數據包下載並存放到cache分區，重啟系統后進入Recovery系統，並用cache分區下載好的數據更新Android主系統，更新完成后重新啟動進入Android主系統。如果更新失敗，設備重啟后就不能正常使用了，唯一的辦法就是重新升級，直到成功為止。
A/B系統主要由運行在Android后台的update_engine和兩套分區‘slot A’和‘slot B’組成。Android系統從其中一套分區啟動，在后台運行update_engine監測升級信息並下載升級數據，然后將數據更新到另外一套分區，寫入數據完成后從更新的分區啟動。
與傳統OTA方式相比，A/B系統的變化主要有：
系統的分區設置
傳統方式只有一套分區
A/B系統有兩套分區，稱為slot A和slot B
跟bootloader溝通的方式
傳統方式bootloader通過讀取misc分區信息來決定是進入Android主系統還是Recovery系統
A/B系統的bootloader通過特定的分區信息來決定從slot A還是slot B啟動
系統的編譯過程
傳統方式在編譯時會生成boot.img和recovery.img分別用於Android主系統和Recovery系統的ramdisk
A/B系統只有boot.img，而不再生成單獨的recovery.img
OTA更新包的生成方式
A/B系統生成OTA包的工具和命令跟傳統方式一樣，但是生成內容的格式不一樣了
由於內容較多，分多篇文章來詳細分析整個A/B系統。
本文主要從分區和總體操作流程上來描述A/B系統，也可以參考Android官方對A/B系統的說明："A/B System Updates"。
2. A/B系統的分區
2.1 傳統OTA的分區
傳統OTA方式下的分區主要包括：
bootloader
存放用於引導linux的bootloader
boot
存放Android主系統的linux kernel文件和用於掛載system和其他分區的ramdisk
system
Android主系統分區，包括Android的系統應用程序和庫文件
vendor
Android主系統分區，主要是包含開發廠商定制的一些應用和庫文件，很多時候開發廠商也直接將這個分區的內容直接放入system分區
userdata
用戶數據分區，存放用戶數據，包括用戶安裝的應用程序和使用時生成的數據
cache
臨時存放數據的分區，通常用於存放OTA的升級包
recovery
存放Recovery系統的linux kernel文件和ramdisk
misc
存放Android主系統和Recovery系統跟bootloader通信的數據
2.2 A/B系統的分區
bootloader
存放用於引導linux的bootloader
boot_a和boot_b
分別用於存放兩套系統各自的linux kernel文件和用於掛載system和其他分區的ramdisk
system_a和system_b
Android主系統分區，分別用於存放兩套系統各自的系統應用程序和庫文件
vendor_a和vendor_b
Android主系統分區， 分別用於存放兩套系統各自的開發廠商定制的一些應用和庫文件，很多時候開發廠商也直接將這個分區的內容直接放入system分區
userdata
用戶數據分區，存放用戶數據，包括用戶安裝的應用程序和使用時生成的數據
misc或其他名字分區
存放Android主系統和Recovery系統跟bootloader通信的數據，由於存放方式和分區名字沒有強制要求，所以部分實現上保留了misc分區（代碼中可見Brillo和Intel的平台），另外部分實現采用其他分區存放數據（Broadcom機頂盒平台采用名為eio的分區）。
2.3 一張圖比較傳統分區和A/B系統分區
關於分區的區別，文字描述不夠直觀，采用圖片清楚多了。
主要區別在於A/B系統：
boot，system和vendor系統分區從傳統的一套變為兩套，叫做slot A和slot B；
不再需要cache和recovery分區
misc分區不是必須
關於cache和misc分區：
仍然有部分廠家保留cache分區，用於一些其他的用途，相當於temp文件夾，但不是用於存放下載的OTA數據。
部分廠家使用misc分區存放Android系統同bootloader通信數據，另有部分廠家使用其它名字的分區存儲這類數據。
3. A/B系統的狀態
3.1 系統分區屬性
對於A/B系統的slot A和slot B分區，其都存在以下三個屬性：
active
系統的活動分區標識，這是一個排他屬性，系統只能有一個分區設置為active屬性，啟動時bootloader選取設置為active的分區進行啟動。
bootable
分區可啟動標識，設置為bootable的分區表明該分區包含了一個完整的可以啟動的系統。
successful
分區成功運行標識，設置為successful的分區表明該分區在上一次啟動或當前啟動中可以正確運行。
3.2 系統的典型場景
典型的應用場景有以下4個（假定當前從B分區啟動）：
圖中：
當前運行的系統（current）用綠色方框表示，當前沒有用的系統（unused）用灰色方框表示。
屬性標識為紅色，表示該狀態下相應屬性被設置，標識為灰色標識該狀態下屬性沒有設置或設置為相反屬性，如：
”active” 表示已經設置active屬性，當前為活動分區；”active” 表示沒有設置active屬性
“bootable” 表示已經設置bootable屬性；”bootable” 表示設置為unbootable或沒有設置bootable屬性
“successful” 表示已經設置successful屬性，”successful” 表示沒有設置successful屬性
每個場景詳細說明如下：
普通場景（Normal cases）
最常見的情形，例如設備出廠時，A分區和B分區都可以成功啟動並正確運行，所以兩個分區都設置為bootable和successful，但由於是從B分區啟動，所以只有B分區設置為active。
升級中（Update in progress）
B分區檢測到升級數據，在A分區進行升級，此時將A分區標識為unbootable，另外清除successful標識；B分區仍然為active，bootable和successful。
更新完成，等待重啟（Update applied, reboot pending）
B分區將A分區成功更新后，將A分區標識為bootable。另外，由於重啟后需要從A分區啟動，所以也需要將A分區設置為active，但是由於還沒有驗證過A分區是否能成功運行，所以不設置successful；B分區的狀態變為bootable和successful，但沒有active。
從新系統成功啟動（System rebooted into new update）
設備重啟后，bootloader檢測到A分區為active，所以加載A分區系統。進入A系統后如果能正確運行，需要將A分區標識為successful。對比第1個普通場景，A和B系統都設置為bootable和successful，但active從B分區切換到A分區。至此，B分區成功更新並切換到A分區，設備重新進入普通場景。
4. A/B系統的更新流程
整個A/B系統的升級更新在后台完成，升級中任何時間點都是可中斷和可恢復的，相當於下載中的斷點續傳，更新操作對用戶是透明的，在不影響用戶操作的情況下完成升級。
設備可以設置數據下載、更新升級的場景和策略，例如：
只有在WiFi連接時才下載數據
電量較少時不下載數據、不進行更新
用戶沒有活動時才進行數據下載和更新等
具體有哪些策略依賴於開發者和用戶的設置。