常见问题解答
Google 是不是在所有设备上都采用了 A/B OTA？
是的。A/B 更新的营销名称是无缝更新。从 2016 年 10 月份开始，Pixel 和 Pixel XL 手机在出厂时都具备 A/B 功能，并且所有 Chromebook 都使用相同的 update_engine A/B 实现。必要的平台代码实现在 Android 7.1 及更高版本中是公开的。
为什么 A/B OTA 更好？
A/B OTA 能够为用户提供更好的更新体验。从每月安全更新数据中获得的指标显示，该功能被证明是成功的：截至 2017 年 5 月，95% 的 Pixel 用户在一个月内采纳最新的安全更新，而 Nexus 用户则为 87%，并且 Pixel 用户执行更新的时间早于 Nexus 用户。如果在 OTA 期间无法成功更新块，将不会再导致设备无法启动；在新系统映像成功启动之前，Android 仍能够回退到上一个可使用的系统映像。
A/B 更新对 2016 Pixel 分区大小有什么影响？
下表包含已推出的 A/B 配置与经过内部测试的非 A/B 配置之间的对比详细信息：
要进行 A/B 更新，只需要在闪存中增加 320MiB，而通过移除恢复分区，可节省 32MiB，通过移除缓存分区，又可以节省 100MiB。这将平衡引导加载程序、启动分区和无线通讯分区的 B 分区带来的开销。供应商分区增大了一倍（在增加的大小中占了绝大部分）。Pixel 的 A/B 系统映像大小是原来的非 A/B 系统映像的一半。
对于经过内部测试的 Pixel A/B 和非 A/B 变体（仅推出了 A/B 变体），所用空间仅差 320MiB。在空间为 32GiB 的设备上，此变体只占用了不到 1% 的空间。对于空间为 16GiB 的设备，此变体占用了不到 2% 的空间，对于空间为 8GiB 的设备，此变体大约占用了 4% 的空间（假设所有三种设备都具有相同的系统映像）。
你们为何不使用 SquashFS？
我们尝试过 SquashFS，但无法实现高端设备所需的性能。我们不会为手持设备使用 SquashFS，也不推荐这么做。
更具体地说，使用 SquashFS 时，系统分区上节省了约 50% 的大小，但绝大多数压缩率较高的文件都是预编译的 .odex 文件。这些文件都具有非常高的压缩比（接近 80%），但系统分区其余部分的压缩比要低得多。另外，SquashFS 在 Android 7.0 中引发了以下性能问题：
- 与以往的设备相比，Pixel 具有非常快的闪存，但不具备大量的空闲 CPU 周期，因此虽然从闪存读取的字节数更少，但却需要更多的 CPU 来处理 I/O，这是一个潜在的制约因素。
- 在没有任何负载的系统上，有些 I/O 变化在人为基准条件下不会出现任何问题，但在具有真实负载（如 Nexus 6 上的加密）的实际用例中有时则会出现问题。
- 在某些方面，基准化分析显示回归率达到 85%。
随着 SquashFS 日趋成熟并且增添了旨在降低 CPU 影响的功能（例如，将不应压缩且经常访问的文件列入白名单），我们将继续对其进行评估并向设备制造商提供建议。
在不使用 SquashFS 的情况下，你们是如何做到将系统分区的大小减半的？
应用存储在 .apk 文件中，这些文件实际上是 ZIP 档案。每个 .apk 文件中都有一个或多个包含可移植 Dalvik 字节码的 .dex 文件。.odex 文件（经过优化的 .dex 文件）会与 .apk 文件分开放置，并且可以包含特定于设备的机器代码。如果存在 .odex 文件，Android 将能够以预先编译的速度运行应用，而无需在每次启动应用时等待系统编译代码。.odex 文件并不是绝对必需的：实际上 Android 可以通过解译或即时 (JIT) 编译来直接运行 .dex 代码，但在空间足够的情况下使用 .odex 文件可以实现最佳的启动速度和运行时速度组合。
示例：对于运行 Android 7.1 且系统映像总大小为 2628MiB（2755792836 字节）的 Nexus 6P 中的 installed-files.txt，在系统映像总大小中占据比重最大的几种文件类型明细如下：
这些数字在其他设备上是类似的，因此在 Nexus/Pixel 设备上，.odex 文件会占用系统分区大约一半的空间。这意味着，我们可以继续使用 EXT4，但在出厂前会将 .odex 文件写入 B 分区，然后在第一次启动时将它们复制到 /data。用于 EXT4 A/B 的实际存储空间与用于 SquashFS A/B 的相同，因为如果我们使用了 SquashFS，我们会将经过预先优化的 .odex 文件放入 system_a 而非 system_b。
将 .odex 文件复制到 /data 难道不是意味着在 /system 上节省的空间会在 /data 上被用掉吗？
不完全是。在 Pixel 上，.odex 文件占用的大部分空间会用于应用（通常存在于 /data 上）。这些应用通过 Google Play 更新，因此系统映像上的 .apk 和 .odex 文件在设备生命周期的大部分时间内都不会用到。当用户实际使用每个应用时，这类文件可以被完全排除并替换为由配置文件驱动的小型 .odex 文件（因此，如果用户不使用应用的话，这类文件就不会占用空间）。有关详细信息，请观看 Google I/O 2016 演讲 ART 的演变。
以下是难以进行比较的几个主要原因：
- 由 Google Play 更新的应用在收到其第一次更新时，一律会尽快将 .odex 文件放在
/data上。 - 用户不运行的应用根本不需要 .odex 文件。
- 配置文件驱动型编译生成的 odex 文件比预先编译生成的 .odex 文件更小（因为前者仅会优化对性能至关重要的代码）。
如需详细了解可供 OEM 使用的调整选项，请参阅配置 ART。
.odex 文件在 /data 上不是有两个副本吗？
这个问题有点复杂。写入新的系统映像后，系统将针对新的 .dex 文件运行新版本的 dex2oat，以生成新的 .odex 文件。这个过程发生在旧系统仍在运行时，因此旧的和新的 .odex 文件同时位于 /data 上。
在优化每个软件包之前，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)) 都会调用 getAvailableSpace，以避免过度填充 /data。请注意，此处的可用数值仍然是保守估计数值：它指的是在达到通常的系统下限空间阈值之前剩余的空间量（以百分比和字节数计）。所以如果 /data 已满，每个 .odex 文件便不会有两个副本。上述代码还有一个 BULK_DELETE_THRESHOLD：如果设备即将占满可用空间（如上所述），则属于未使用应用的 .odex 文件将会被移除。这是每个 .odex 文件没有两个副本的另一种情况。
最糟糕的情况是 /data 已被完全填满，更新要一直等到设备重新启动到新系统，而不再需要旧系统的 .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))。在新系统成功启动之后，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)) 可以移除旧系统此前使用的 .odex 文件，从而使设备返回到只有一个副本的稳定状态。
因此，尽管 /data 可能会包含所有 .odex 文件的两个副本，但 (a) 这种情况是暂时的，并且 (b) 只有在 /data 上有足够的可用空间时才会出现这种情况。除非是在更新期间，否则该文件都将只有一个副本。作为 ART 通用健壮性功能的一部分，它永远不会让 /data 中填满 .odex 文件（因为在非 A/B 系统上，这也会是一个问题）。
难道这种写入/复制操作不会增加闪存磨损吗？
只有一小部分闪存会被重写：完整的 Pixel 系统更新会写入大约 2.3GiB 的数据（应用也会被重新编译，但对于非 A/B 更新而言也是如此）。一直以来，基于块的完整 OTA 都会写入类似数量的数据，因此闪存磨损率应该类似。
刷写两个系统分区会增加工厂镜像刷写时间吗？
不会。Pixel 的系统映像大小并没有增加（只是将空间划分到了两个分区）。
如果将 .odex 文件保留在 B 上，不会导致恢复出厂设置后重新启动速度变慢吗？
会。如果您已实际使用了一台设备，进行了 OTA，并且执行了恢复出厂设置，则首次重新启动的速度将会比未进行恢复出厂设置操作时慢（在 Pixel XL上，分别为 1 分 40 秒和 40 秒），因为在进行第一次 OTA 之后，B 中将会失去 .odex 文件，所以这些文件无法复制到 /data。正所谓有得有失。
与常规启动相比，恢复出厂设置应该是一项极少执行的操作，因此时间的花销这个问题就显得没那么重要了（这并不影响从工厂获取设备的用户或审核者，因为在这种情况下，B 分区是可用的）。使用 JIT 编译器意味着我们不需要重新编译所有内容，因此情况可能不会像您想象的那么糟糕。此外，您也可以通过在清单 ([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" 将应用标记为需要预先编译。这是 system_server 当前采用的方式，因为出于安全考虑，不允许此进程进行 JIT 编译。
如果将 .odex 文件保留在 /data 而非 /system 上，不会导致 OTA 后重新启动速度变慢吗？
不会。如上所述，系统会在旧系统映像仍在运行时运行新的 dex2oat，以生成新系统将会需要的文件。在相关工作完成之前，更新会被视为不可用。
我们可以（应该）推出 32GiB、16GiB 或 8GiB 的 A/B 设备吗？
32GiB 可以很好地满足需求（正如在 Pixel 上证明的那样），而对于 16GiB，如果占用其中的 320MiB 则意味着总可用空间减少了 2%。同样地，对于 8GiB，占用其中的 320MiB 则意味着总可用空间减少了 4%。很显然，在空间为 4GiB 的设备上，不推荐使用 A/B 更新，因为 320MiB 的开销几乎占到了总可用空间的 10%。
AVB2.0 需要 A/B OTA 吗？
不需要。Android 验证启动一直以来都是需要基于块的更新，但不一定是 A/B 更新。
A/B OTA 需要 AVB2.0 吗？
不需要。
A/B OTA 会破坏 AVB2.0 的回滚保护吗？
不会。对于这一点，存在一些混淆，因为如果 A/B 系统无法启动到新的系统映像，那么，重试一定的次数（由引导加载程序确定）后，它将自动恢复到“之前”的系统映像。但关键在于，对于使用 A/B 更新的系统而言，“之前”的系统映像实际上仍然是“当前”的系统映像。设备成功启动新映像后，回滚保护功能就会启动，确保您无法使用以前的系统再启动。但是，在您真正成功启动新映像之前，回滚保护功能不会将其视为当前系统映像。
如果在系统运行时安装更新，速度会不会很慢？
使用非 A/B 更新时，目标是尽快安装更新，因为用户正在等待，并且在系统应用更新时，用户将无法使用其设备。使用 A/B 更新时，情况则恰恰相反。这是因为用户仍在使用其设备，于是目标就变成了尽可能减少对用户的影响，所以系统会有意缓慢地进行更新。通过 Java 系统更新客户端中的逻辑（对于 Google 来说是 GMSCore - 由 GMS 提供的核心软件包），Android 还会尝试选择用户完全不使用设备的时间进行更新。该平台支持暂停/恢复更新，如果用户开始使用设备，客户端可以使用该功能来暂停更新，并在设备再次进入闲置状态时恢复更新。
进行 OTA 要经过两个阶段，这两个阶段在界面中的进度条下清楚地显示为“第 1 步（共 2 步）”和“第 2 步（共 2 步）”。第 1 步是写入数据块，第 2 步是预编译 .dex 文件。这两个阶段在对性能的影响方面有很大差异。第一个阶段是简单的 I/O 操作。这只需要占用极少的资源（RAM、CPU、I/O），因为它只是缓慢地复制数据块。
第二个阶段是运行 dex2oat 来预编译新的系统映像。很显然，这在资源要求上没有明确的界限，因为它会编译实际应用。与编译简单的小应用相比，编译复杂的大应用所涉及的工作量显然要多出许多；而在第 1 阶段，没有任何磁盘块会比其他磁盘块更大或更复杂。
该过程类似于 Google Play 先在后台安装应用更新，然后显示“已更新 5 个应用”通知（这是多年来一直采用的做法）。
如果用户实际上正在等待更新，将会怎样？
GmsCore 中的当前实现并不会区分后台更新和用户发起的更新，但将来可能会加以区分。届时，如果用户明确要求安装更新或正在查看更新进度屏幕，我们将假设他们正在等待系统完成更新，从而优先安排更新工作。
如果无法应用更新，将会怎样？
对于非 A/B 更新，如果更新无法应用，过去常常会导致用户的设备无法使用。唯一的例外情况是在开始应用更新之前就出现问题（比如说因为软件包验证失败）。对于 A/B 更新，无法应用更新并不会影响当前正在运行的系统。可以稍后重新尝试更新。
哪些系统芯片 (SoC) 支持 A/B？
截至 2017 年 3 月 15 日，我们提供的信息如下：
有关时间表的详细信息，请咨询您的 SoC 联系人。对于上面未列出的 SoC，请直接与您的 SoC 供应商联系。
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