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 仍能够回退到上一个可使用的系统映像。
什么是 system_other？
应用存储在 .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，在系统映像总大小中占据比重最大的几种文件类型明细如下：
| .odex | 1391770312 字节 | 50.5% |
| .apk | 846878259 字节 | 30.7% |
| .so（原生 C/C++ 代码） | 202162479 字节 | 7.3% |
| .oat 文件/.art 映像 | 163892188 字节 | 5.9% |
| 字体 | 38952361 字节 | 1.4% |
| icu 语言区域数据 | 27468687 字节 | 0.9% |
这些数字在其他设备上是类似的，因此在 Nexus/Pixel 设备上，.odex 文件会占用 system 分区大约一半的空间。这意味着我们可以继续使用 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 文件（因此，用户不使用的应用不需要空间）。如需了解详情，请观看 2016 年 Google I/O 大会演讲 ART 的演变。
难以比较的几个主要原因：
-
由 Google Play 更新的应用在收到其第一次更新时，始终会立即将 .odex 文件放在
/data上。 - 用户不运行的应用根本不需要 .odex 文件。
- 配置文件驱动型编译生成的 odex 文件比预先编译生成的 .odex 文件要小（因为前者仅会优化对性能至关重要的代码）。
如需详细了解可供 OEM 使用的调整选项，请参阅配置 ART。
.odex 文件在 /data 上不是有两个副本吗？
这个问题有点复杂…写入新的系统映像后，系统将针对新的 .dex 文件运行新版本的 dex2oat，以生成新的 .odex 文件。这个过程发生在旧系统仍在运行时，因此旧的和新的 .odex 文件同时位于 /data 上。
在优化每个软件包之前，OtaDexoptService 中的代码 (frameworks/base/+/main/services/core/java/com/android/server/pm/OtaDexoptService.java) 都会调用 getAvailableSpace，以避免过度填充 /data。请注意，此处的可用数值仍然是保守估计：是指在达到通常的系统下限空间阈值之前剩余的空间量（以百分比和字节数计）。所以如果 /data 已满，每个 .odex 文件便不会有两个副本。上述代码还有一个 BULK_DELETE_THRESHOLD：如果设备上的可用空间即将被填满（如上所述），属于未使用应用的 .odex 文件将会被移除。这是每个 .odex 文件没有两个副本的另一种情况。
最糟糕的情况是 /data 已被完全填满，更新将等到设备重新启动到新系统，而不再需要旧系统的 .odex 文件时。PackageManager 可处理此情况：(frameworks/base/+/main/services/core/java/com/android/server/pm/PackageManagerService.java#7215)。在新系统成功启动之后，installd (frameworks/native/+/main/cmds/installd/dexopt.cpp#2422) 可以移除旧系统之前用过的 .odex 文件，从而让设备返回到只有 1 个副本的稳定状态。
因此，尽管 /data 可能会包含所有 .odex 文件的两个副本，但 (a) 这是暂时的，并且 (b) 只有在 /data 上有足够的可用空间时才会发生。除了在更新期间，将始终只有 1 个副本。作为 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/+/main/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 来预编译新的系统映像。这显然在资源要求上没有明确的界限，因为它会编译实际应用。与编译小而简单的应用相比，编译大而复杂的应用所涉及的工作量显然要多出许多；而在第一个阶段，没有任何磁盘块会比其他磁盘块更大或更复杂。
该过程类似于 Google Play 先在后台安装应用更新，然后显示“已更新 5 个应用”通知，而这是多年来一直采用的做法。
如果用户实际上正在等待更新，将会怎样？
GmsCore 中的当前实现不区分后台更新和用户启动的更新，但将来可能会加以区分。届时，如果用户明确要求安装更新或正在查看更新进度界面，我们将假设他们正在等待系统完成更新，从而优先安排更新工作。
如果无法应用更新，将会怎样？
对于非 A/B 更新，如果更新无法应用，过去经常会导致用户的设备无法使用。唯一的例外情况是在尚未应用更新之前就出现问题（比如说因为更新包验证失败）。对于 A/B 更新，无法应用更新不会影响当前正在运行的系统。可以稍后重新尝试更新。