今天給大家介紹一下 Android 系統已有的更新機制。目前，現有的Android 系統主要有三種不同的更新機制，分別是
A Only、
A/B
、
virtual A/B。
virtual A/B是目前谷歌推薦的更新機制，不過目前大部分機型，還是使用較為傳統的A Only更新機制，部分中高階旗艦產品才開始使用A/B、virtual A/B。
更優秀的更新機制，可以延長一部手機的系統更新週期。這幾種更新方式都有各自的優點和缺點，主要側重點在於更新機制的安全性、儲存空間佔用以及使用者的可感知性
。
下面簡單介紹一下。
A Only（簡稱：非A/B更新）
顧名思義，這種模式下，系統只在一個分割槽裡面。好處是系統對空間佔用少，壞處是OTA更新速度較慢，而且一旦更新失敗，容易成磚。
A/B（簡稱：無縫更新）
搭載 Android 7。0 系統的Google Pixel 採用了這個更新模式，之後有一些中高階機型使用了此模式。簡單來說，這種做法可以將系統分別裝在兩個不同的分割槽當中，裝置則可以從任何一個分割槽啟動系統，但是系統A和系統B共用一個data資料分割槽。也就是說在更新或者刷入系統時，如果你在使用 A 分割槽的系統，那麼可以讓 B 分割槽的檔案進行更新。如果 B 分割槽更新後出現問題了，還可以重新進入 A 分割槽的系統。
［1］
A/B分割槽的好處
（1）無縫更新。更新過程可以幾乎完全在後臺進行，無縫更新可以節省大量時間。
（2）安全性，不會因為升級出現無法開機的問題。在系統A升級系統B，如果升級成功則重啟到B系統，而如果升級失敗，則保留在A系統。
A/B分割槽的壞處：
（1）多佔用10多個G的儲存空間
到這裡，安卓系統就已經有了兩個更新機制：A/B（無縫）更新和非 A/B 更新。但是，為了降低程式碼複雜性並增強更新性，谷歌在 Android 11 中將這兩個機制統一，推出了新的更新機制，
virtual A/B
（即虛擬A/B），結合了兩個前身的優勢，將無縫更新帶到所有裝置，同時最大限度地降低儲存成本。
virtual A/B（簡稱虛擬A/B更新）
從Android 11 開始，Google推薦virtual A/B，這種方法，刪除了recovery/cache 兩個分割槽，但是system只有一套，比A/B少了一套，使用了A/B系統類似的更新方法，ota之後，在分割槽內產生△system △vendor等差異化內容，重啟之後，使用△資料+super內容，組成snapshot ，系統引導 snapshot 開機，如果開機正常，那麼開機以後merge △ 資料到 super ，等下次重啟，使用正常的super分割槽系統開機。［2］
virtual A/B的優點［3］：
1： 和A/B一樣，它支援無縫更新
2：支援更新回滾。如果新作業系統無法啟動，裝置將自動回滾到上一個版本
3：使用
最小額外空間
4：不容易出現OTA之後無法開機問題
virtual A/B的缺點：
1：在合併建立映象過程中，對快閃記憶體讀寫效能有一點的要求
當然，出廠就是安卓11系統的手機和後期透過OTA的方式升級到安卓11的機型的系統機制並不相同。一般來而言，後期透過OTA的方式升級到安卓11的機型預設還是Recovery升級方案，這是因為分割槽已經無法修改。對於經常刷機ROOT的機友來說，由於更新機制的不同，在使用Magisk 獲取ROOT的方式也可能和普通的不一樣。此外，對於使用Virtual A/B的機型，第三方REC也不太好適配。
需要注意的是，在這已有的三種更新機制當中，Google沒有強制手機廠商一定要使用 A/B 或者 Virtual A/B，無論使用 A/B 或者 Virtual A/B，都不影響其使用Android 11系統。Google 只有在Android one系統上強制使用A /B。
參考文獻：
［1］csdn，guyongqiangx，2017-05-07，Android A/B System OTA分析概覽，https：//blog。csdn。net/guyongqiangx/article/details/71334889
［2］微博，秋葉隨風，https：//weibo。com/1697247850/JjRvXnlYy
［3］谷歌開發者中心，配置-更新-虛擬A/B 概述，2020-12-29，Virtual_ab概述：https：//source。android。google。cn/devices/tech/ota/virtual_ab？hl=en