常见问题解答

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 配置之间的对比详细信息:

Pixel 分区大小 A/B 非 A/B
引导加载程序 50*2 50
启动 32*2 32
恢复 0 32
缓存 0 100
无线通讯 70*2 70
供应商 300*2 300
系统 2048*2 4096
总计 5000 4680

要进行 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,在系统映像总大小中占据比重最大的几种文件类型明细如下:

.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 文件会占用系统分区大约一半的空间。这意味着,我们可以继续使用 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) 都会调用 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)。在新系统成功启动之后,installd (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) 中使用 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 日,我们提供的信息如下:

Android 7.x 版本 Android 8.x 版本
Qualcomm 根据 OEM 的请求而定 所有芯片组都将受支持
Mediatek 根据 OEM 的请求而定 所有芯片组都将受支持

有关时间表的详细信息,请咨询您的 SoC 联系人。对于上面未列出的 SoC,请直接与您的 SoC 供应商联系。