常見問題解答
Google 是不是在所有設(shè)備上都采用了 A/B OTA？
是的读第。A/B 更新的營(yíng)銷名稱是無縫更新。從 2016 年 10 月份開始世落，Pixel 和 Pixel XL 手機(jī)在出廠時(shí)都具備 A/B 功能魏铅，并且所有 Chromebook 都使用相同的 update_engine A/B 實(shí)現(xiàn)昌犹。必要的平臺(tái)代碼實(shí)現(xiàn)在 Android 7.1 及更高版本中是公開的。
為什么 A/B OTA 更好览芳？
A/B OTA 能夠?yàn)橛脩籼峁└玫母麦w驗(yàn)斜姥。從每月安全更新數(shù)據(jù)中獲得的指標(biāo)顯示，該功能被證明是成功的：截至 2017 年 5 月沧竟，95% 的 Pixel 用戶在一個(gè)月內(nèi)采納最新的安全更新铸敏，而 Nexus 用戶則為 87%，并且 Pixel 用戶執(zhí)行更新的時(shí)間早于 Nexus 用戶悟泵。如果在 OTA 期間無法成功更新塊搞坝，將不會(huì)再導(dǎo)致設(shè)備無法啟動(dòng)；在新系統(tǒng)映像成功啟動(dòng)之前魁袜，Android 仍能夠回退到上一個(gè)可使用的系統(tǒng)映像桩撮。
A/B 更新對(duì) 2016 Pixel 分區(qū)大小有什么影響？
下表包含已推出的 A/B 配置與經(jīng)過內(nèi)部測(cè)試的非 A/B 配置之間的對(duì)比詳細(xì)信息：
要進(jìn)行 A/B 更新峰弹，只需要在閃存中增加 320MiB店量，而通過移除恢復(fù)分區(qū)，可節(jié)省 32MiB鞠呈，通過移除緩存分區(qū)融师，又可以節(jié)省 100MiB。這將平衡引導(dǎo)加載程序蚁吝、啟動(dòng)分區(qū)和無線通訊分區(qū)的 B 分區(qū)帶來的開銷旱爆。供應(yīng)商分區(qū)增大了一倍（在增加的大小中占了絕大部分）。Pixel 的 A/B 系統(tǒng)映像大小是原來的非 A/B 系統(tǒng)映像的一半窘茁。
對(duì)于經(jīng)過內(nèi)部測(cè)試的 Pixel A/B 和非 A/B 變體（僅推出了 A/B 變體）怀伦，所用空間僅差 320MiB。在空間為 32GiB 的設(shè)備上山林，此變體只占用了不到 1% 的空間房待。對(duì)于空間為 16GiB 的設(shè)備，此變體占用了不到 2% 的空間驼抹，對(duì)于空間為 8GiB 的設(shè)備桑孩，此變體大約占用了 4% 的空間（假設(shè)所有三種設(shè)備都具有相同的系統(tǒng)映像）。
你們?yōu)楹尾皇褂?SquashFS框冀？
我們嘗試過 SquashFS流椒，但無法實(shí)現(xiàn)高端設(shè)備所需的性能。我們不會(huì)為手持設(shè)備使用 SquashFS明也，也不推薦這么做宣虾。
更具體地說极谊，使用 SquashFS 時(shí)，系統(tǒng)分區(qū)上節(jié)省了約 50% 的大小安岂，但絕大多數(shù)壓縮率較高的文件都是預(yù)編譯的 .odex 文件。這些文件都具有非常高的壓縮比（接近 80%）帆吻，但系統(tǒng)分區(qū)其余部分的壓縮比要低得多域那。另外，SquashFS 在 Android 7.0 中引發(fā)了以下性能問題：
- 與以往的設(shè)備相比猜煮，Pixel 具有非炒卧保快的閃存，但不具備大量的空閑 CPU 周期王带，因此雖然從閃存讀取的字節(jié)數(shù)更少淑蔚，但卻需要更多的 CPU 來處理 I/O，這是一個(gè)潛在的制約因素愕撰。
- 在沒有任何負(fù)載的系統(tǒng)上刹衫，有些 I/O 變化在人為基準(zhǔn)條件下不會(huì)出現(xiàn)任何問題，但在具有真實(shí)負(fù)載（如 Nexus 6 上的加密）的實(shí)際用例中有時(shí)則會(huì)出現(xiàn)問題搞挣。
- 在某些方面带迟，基準(zhǔn)化分析顯示回歸率達(dá)到 85%。
隨著 SquashFS 日趨成熟并且增添了旨在降低 CPU 影響的功能（例如囱桨，將不應(yīng)壓縮且經(jīng)常訪問的文件列入白名單）仓犬，我們將繼續(xù)對(duì)其進(jìn)行評(píng)估并向設(shè)備制造商提供建議。
在不使用 SquashFS 的情況下舍肠，你們是如何做到將系統(tǒng)分區(qū)的大小減半的搀继？
應(yīng)用存儲(chǔ)在 .apk 文件中，這些文件實(shí)際上是 ZIP 檔案翠语。每個(gè) .apk 文件中都有一個(gè)或多個(gè)包含可移植 Dalvik 字節(jié)碼的 .dex 文件叽躯。.odex 文件（經(jīng)過優(yōu)化的 .dex 文件）會(huì)與 .apk 文件分開放置，并且可以包含特定于設(shè)備的機(jī)器代碼肌括。如果存在 .odex 文件险毁，Android 將能夠以預(yù)先編譯的速度運(yùn)行應(yīng)用，而無需在每次啟動(dòng)應(yīng)用時(shí)等待系統(tǒng)編譯代碼们童。.odex 文件并不是絕對(duì)必需的：實(shí)際上 Android 可以通過解譯或即時(shí) (JIT) 編譯來直接運(yùn)行 .dex 代碼畔况，但在空間足夠的情況下使用 .odex 文件可以實(shí)現(xiàn)最佳的啟動(dòng)速度和運(yùn)行時(shí)速度組合。
示例：對(duì)于運(yùn)行 Android 7.1 且系統(tǒng)映像總大小為 2628MiB（2755792836 字節(jié)）的 Nexus 6P 中的 installed-files.txt慧库，在系統(tǒng)映像總大小中占據(jù)比重最大的幾種文件類型明細(xì)如下：
這些數(shù)字在其他設(shè)備上是類似的跷跪，因此在 Nexus/Pixel 設(shè)備上，.odex 文件會(huì)占用系統(tǒng)分區(qū)大約一半的空間齐板。這意味著吵瞻，我們可以繼續(xù)使用 EXT4葛菇，但在出廠前會(huì)將 .odex 文件寫入 B 分區(qū)，然后在第一次啟動(dòng)時(shí)將它們復(fù)制到 /data橡羞。用于 EXT4 A/B 的實(shí)際存儲(chǔ)空間與用于 SquashFS A/B 的相同眯停，因?yàn)槿绻覀兪褂昧?SquashFS，我們會(huì)將經(jīng)過預(yù)先優(yōu)化的 .odex 文件放入 system_a 而非 system_b卿泽。
將 .odex 文件復(fù)制到 /data 難道不是意味著在 /system 上節(jié)省的空間會(huì)在 /data 上被用掉嗎莺债？
不完全是。在 Pixel 上签夭，.odex 文件占用的大部分空間會(huì)用于應(yīng)用（通常存在于 /data 上）齐邦。這些應(yīng)用通過 Google Play 更新，因此系統(tǒng)映像上的 .apk 和 .odex 文件在設(shè)備生命周期的大部分時(shí)間內(nèi)都不會(huì)用到第租。當(dāng)用戶實(shí)際使用每個(gè)應(yīng)用時(shí)措拇，這類文件可以被完全排除并替換為由配置文件驅(qū)動(dòng)的小型 .odex 文件（因此，如果用戶不使用應(yīng)用的話慎宾，這類文件就不會(huì)占用空間）丐吓。有關(guān)詳細(xì)信息，請(qǐng)觀看 Google I/O 2016 演講 ART 的演變趟据。
以下是難以進(jìn)行比較的幾個(gè)主要原因：
- 由 Google Play 更新的應(yīng)用在收到其第一次更新時(shí)汰蜘，一律會(huì)盡快將 .odex 文件放在
/data上。 - 用戶不運(yùn)行的應(yīng)用根本不需要 .odex 文件之宿。
- 配置文件驅(qū)動(dòng)型編譯生成的 odex 文件比預(yù)先編譯生成的 .odex 文件更凶宀佟（因?yàn)榍罢邇H會(huì)優(yōu)化對(duì)性能至關(guān)重要的代碼）。
如需詳細(xì)了解可供 OEM 使用的調(diào)整選項(xiàng)比被，請(qǐng)參閱配置 ART色难。
.odex 文件在 /data 上不是有兩個(gè)副本嗎？
這個(gè)問題有點(diǎn)復(fù)雜等缀。寫入新的系統(tǒng)映像后枷莉，系統(tǒng)將針對(duì)新的 .dex 文件運(yùn)行新版本的 dex2oat，以生成新的 .odex 文件尺迂。這個(gè)過程發(fā)生在舊系統(tǒng)仍在運(yùn)行時(shí)笤妙，因此舊的和新的 .odex 文件同時(shí)位于 /data 上。
在優(yōu)化每個(gè)軟件包之前噪裕，OtaDexoptService 中的代碼 ([frameworks/base/+/nougat-mr1-release/services/core/java/com/android/server/pm/OtaDexoptService.java#200](https://android.googlesource.com/platform/frameworks/base/+/nougat-mr1-release/services/core/java/com/android/server/pm/OtaDexoptService.java#200)) 都會(huì)調(diào)用 getAvailableSpace蹲盘，以避免過度填充 /data。請(qǐng)注意膳音，此處的可用數(shù)值仍然是保守估計(jì)數(shù)值：它指的是在達(dá)到通常的系統(tǒng)下限空間閾值之前剩余的空間量（以百分比和字節(jié)數(shù)計(jì)）召衔。所以如果 /data 已滿，每個(gè) .odex 文件便不會(huì)有兩個(gè)副本祭陷。上述代碼還有一個(gè) BULK_DELETE_THRESHOLD：如果設(shè)備即將占滿可用空間（如上所述）苍凛，則屬于未使用應(yīng)用的 .odex 文件將會(huì)被移除趣席。這是每個(gè) .odex 文件沒有兩個(gè)副本的另一種情況。
最糟糕的情況是 /data 已被完全填滿醇蝴，更新要一直等到設(shè)備重新啟動(dòng)到新系統(tǒng)宣肚，而不再需要舊系統(tǒng)的 .odex 文件。PackageManager 可處理這種情況：([frameworks/base/+/nougat-mr1-release/services/core/java/com/android/server/pm/PackageManagerService.java#7215](https://android.googlesource.com/platform/frameworks/base/+/nougat-mr1-release/services/core/java/com/android/server/pm/PackageManagerService.java#7215))悠栓。在新系統(tǒng)成功啟動(dòng)之后霉涨，installd ([frameworks/native/+/nougat-mr1-release/cmds/installd/commands.cpp#2192](https://android.googlesource.com/platform/frameworks/native/+/nougat-mr1-release/cmds/installd/commands.cpp#2192)) 可以移除舊系統(tǒng)此前使用的 .odex 文件，從而使設(shè)備返回到只有一個(gè)副本的穩(wěn)定狀態(tài)闸迷。
因此，盡管 /data 可能會(huì)包含所有 .odex 文件的兩個(gè)副本俘枫，但 (a) 這種情況是暫時(shí)的腥沽，并且 (b) 只有在 /data 上有足夠的可用空間時(shí)才會(huì)出現(xiàn)這種情況。除非是在更新期間鸠蚪，否則該文件都將只有一個(gè)副本今阳。作為 ART 通用健壯性功能的一部分，它永遠(yuǎn)不會(huì)讓 /data 中填滿 .odex 文件（因?yàn)樵诜?A/B 系統(tǒng)上茅信，這也會(huì)是一個(gè)問題）盾舌。
難道這種寫入/復(fù)制操作不會(huì)增加閃存磨損嗎？
只有一小部分閃存會(huì)被重寫：完整的 Pixel 系統(tǒng)更新會(huì)寫入大約 2.3GiB 的數(shù)據(jù)（應(yīng)用也會(huì)被重新編譯蘸鲸，但對(duì)于非 A/B 更新而言也是如此）妖谴。一直以來，基于塊的完整 OTA 都會(huì)寫入類似數(shù)量的數(shù)據(jù)酌摇，因此閃存磨損率應(yīng)該類似膝舅。
刷寫兩個(gè)系統(tǒng)分區(qū)會(huì)增加工廠鏡像刷寫時(shí)間嗎？
不會(huì)窑多。Pixel 的系統(tǒng)映像大小并沒有增加（只是將空間劃分到了兩個(gè)分區(qū)）仍稀。
如果將 .odex 文件保留在 B 上，不會(huì)導(dǎo)致恢復(fù)出廠設(shè)置后重新啟動(dòng)速度變慢嗎埂息？
會(huì)技潘。如果您已實(shí)際使用了一臺(tái)設(shè)備，進(jìn)行了 OTA千康，并且執(zhí)行了恢復(fù)出廠設(shè)置享幽，則首次重新啟動(dòng)的速度將會(huì)比未進(jìn)行恢復(fù)出廠設(shè)置操作時(shí)慢（在 Pixel XL上，分別為 1 分 40 秒和 40 秒）拾弃，因?yàn)樵谶M(jìn)行第一次 OTA 之后琉闪，B 中將會(huì)失去 .odex 文件，所以這些文件無法復(fù)制到 /data砸彬。正所謂有得有失颠毙。
與常規(guī)啟動(dòng)相比斯入，恢復(fù)出廠設(shè)置應(yīng)該是一項(xiàng)極少執(zhí)行的操作，因此時(shí)間的花銷這個(gè)問題就顯得沒那么重要了（這并不影響從工廠獲取設(shè)備的用戶或?qū)徍苏咧郏驗(yàn)樵谶@種情況下刻两，B 分區(qū)是可用的）。使用 JIT 編譯器意味著我們不需要重新編譯所有內(nèi)容滴某，因此情況可能不會(huì)像您想象的那么糟糕磅摹。此外，您也可以通過在清單 ([frameworks/base/+/nougat-mr1-release/packages/SystemUI/AndroidManifest.xml#23](https://android.googlesource.com/platform/frameworks/base/+/nougat-mr1-release/packages/SystemUI/AndroidManifest.xml#23)) 中使用 coreApp="true" 將應(yīng)用標(biāo)記為需要預(yù)先編譯霎奢。這是 system_server 當(dāng)前采用的方式户誓，因?yàn)槌鲇诎踩紤]，不允許此進(jìn)程進(jìn)行 JIT 編譯幕侠。
如果將 .odex 文件保留在 /data 而非 /system 上帝美，不會(huì)導(dǎo)致 OTA 后重新啟動(dòng)速度變慢嗎？
不會(huì)晤硕。如上所述悼潭，系統(tǒng)會(huì)在舊系統(tǒng)映像仍在運(yùn)行時(shí)運(yùn)行新的 dex2oat，以生成新系統(tǒng)將會(huì)需要的文件舞箍。在相關(guān)工作完成之前舰褪，更新會(huì)被視為不可用。
我們可以（應(yīng)該）推出 32GiB疏橄、16GiB 或 8GiB 的 A/B 設(shè)備嗎占拍？
32GiB 可以很好地滿足需求（正如在 Pixel 上證明的那樣），而對(duì)于 16GiB捎迫，如果占用其中的 320MiB 則意味著總可用空間減少了 2%刷喜。同樣地，對(duì)于 8GiB立砸，占用其中的 320MiB 則意味著總可用空間減少了 4%掖疮。很顯然，在空間為 4GiB 的設(shè)備上颗祝，不推薦使用 A/B 更新浊闪，因?yàn)?320MiB 的開銷幾乎占到了總可用空間的 10%。
AVB2.0 需要 A/B OTA 嗎螺戳？
不需要搁宾。Android 驗(yàn)證啟動(dòng)一直以來都是需要基于塊的更新，但不一定是 A/B 更新倔幼。
A/B OTA 需要 AVB2.0 嗎盖腿？
不需要。
A/B OTA 會(huì)破壞 AVB2.0 的回滾保護(hù)嗎？
不會(huì)翩腐。對(duì)于這一點(diǎn)鸟款，存在一些混淆，因?yàn)槿绻?A/B 系統(tǒng)無法啟動(dòng)到新的系統(tǒng)映像茂卦，那么何什，重試一定的次數(shù)（由引導(dǎo)加載程序確定）后，它將自動(dòng)恢復(fù)到“之前”的系統(tǒng)映像等龙。但關(guān)鍵在于处渣，對(duì)于使用 A/B 更新的系統(tǒng)而言，“之前”的系統(tǒng)映像實(shí)際上仍然是“當(dāng)前”的系統(tǒng)映像蛛砰。設(shè)備成功啟動(dòng)新映像后罐栈，回滾保護(hù)功能就會(huì)啟動(dòng)，確保您無法使用以前的系統(tǒng)再啟動(dòng)泥畅。但是荠诬，在您真正成功啟動(dòng)新映像之前，回滾保護(hù)功能不會(huì)將其視為當(dāng)前系統(tǒng)映像涯捻。
如果在系統(tǒng)運(yùn)行時(shí)安裝更新浅妆，速度會(huì)不會(huì)很慢望迎？
使用非 A/B 更新時(shí)障癌，目標(biāo)是盡快安裝更新，因?yàn)橛脩粽诘却缱穑⑶以谙到y(tǒng)應(yīng)用更新時(shí)涛浙，用戶將無法使用其設(shè)備。使用 A/B 更新時(shí)摄欲，情況則恰恰相反轿亮。這是因?yàn)橛脩羧栽谑褂闷湓O(shè)備，于是目標(biāo)就變成了盡可能減少對(duì)用戶的影響胸墙，所以系統(tǒng)會(huì)有意緩慢地進(jìn)行更新我注。通過 Java 系統(tǒng)更新客戶端中的邏輯（對(duì)于 Google 來說是 GMSCore - 由 GMS 提供的核心軟件包），Android 還會(huì)嘗試選擇用戶完全不使用設(shè)備的時(shí)間進(jìn)行更新迟隅。該平臺(tái)支持暫停/恢復(fù)更新但骨，如果用戶開始使用設(shè)備，客戶端可以使用該功能來暫停更新智袭，并在設(shè)備再次進(jìn)入閑置狀態(tài)時(shí)恢復(fù)更新奔缠。
進(jìn)行 OTA 要經(jīng)過兩個(gè)階段，這兩個(gè)階段在界面中的進(jìn)度條下清楚地顯示為“第 1 步（共 2 步）”和“第 2 步（共 2 步）”吼野。第 1 步是寫入數(shù)據(jù)塊校哎，第 2 步是預(yù)編譯 .dex 文件。這兩個(gè)階段在對(duì)性能的影響方面有很大差異。第一個(gè)階段是簡(jiǎn)單的 I/O 操作闷哆。這只需要占用極少的資源（RAM腰奋、CPU、I/O）阳准，因?yàn)樗皇蔷徛貜?fù)制數(shù)據(jù)塊氛堕。
第二個(gè)階段是運(yùn)行 dex2oat 來預(yù)編譯新的系統(tǒng)映像。很顯然野蝇，這在資源要求上沒有明確的界限讼稚，因?yàn)樗鼤?huì)編譯實(shí)際應(yīng)用。與編譯簡(jiǎn)單的小應(yīng)用相比绕沈，編譯復(fù)雜的大應(yīng)用所涉及的工作量顯然要多出許多锐想；而在第 1 階段，沒有任何磁盤塊會(huì)比其他磁盤塊更大或更復(fù)雜乍狐。
該過程類似于 Google Play 先在后臺(tái)安裝應(yīng)用更新脚囊，然后顯示“已更新 5 個(gè)應(yīng)用”通知（這是多年來一直采用的做法）。
如果用戶實(shí)際上正在等待更新晨仑，將會(huì)怎樣意乓？
GmsCore 中的當(dāng)前實(shí)現(xiàn)并不會(huì)區(qū)分后臺(tái)更新和用戶發(fā)起的更新，但將來可能會(huì)加以區(qū)分惜傲。屆時(shí)洽故，如果用戶明確要求安裝更新或正在查看更新進(jìn)度屏幕，我們將假設(shè)他們正在等待系統(tǒng)完成更新盗誊，從而優(yōu)先安排更新工作时甚。
如果無法應(yīng)用更新，將會(huì)怎樣哈踱？
對(duì)于非 A/B 更新荒适，如果更新無法應(yīng)用，過去常常會(huì)導(dǎo)致用戶的設(shè)備無法使用开镣。唯一的例外情況是在開始應(yīng)用更新之前就出現(xiàn)問題（比如說因?yàn)檐浖?yàn)證失數段堋）。對(duì)于 A/B 更新邪财，無法應(yīng)用更新并不會(huì)影響當(dāng)前正在運(yùn)行的系統(tǒng)陕壹。可以稍后重新嘗試更新卧蜓。
哪些系統(tǒng)芯片 (SoC) 支持 A/B帐要？
截至 2017 年 3 月 15 日，我們提供的信息如下：
有關(guān)時(shí)間表的詳細(xì)信息弥奸，請(qǐng)咨詢您的 SoC 聯(lián)系人榨惠。對(duì)于上面未列出的 SoC，請(qǐng)直接與您的 SoC 供應(yīng)商聯(lián)系。
Except as otherwise noted, the content of this page is licensed under the Creative Commons Attribution 3.0 License, and code samples are licensed under the Apache 2.0 License. For details, see our Site Policies. Java is a registered trademark of Oracle and/or its affiliates.
上次更新日期：一月 24, 2018
