设置 super 分区的大小

正确调整 super 分区的大小对于设备可更新性非常重要。该大小会直接影响设备可进行多少次更新以及可成功获取这些更新的用户数。

需要考虑几个重要的变量。第一个是出厂大小，也就是首次刷写设备时所有动态分区的大小。第二个是增长率，即操作系统大小在设备整个可更新生命周期中增加的百分比。

此外，虚拟 A/B 设备可以在更新期间占用 /data 上的空间，在调整 super 的大小时必须考虑这一点。如果 /data 需要的空间过多，某些用户便无法（或不愿意）执行更新。不过，如果知道大多数用户都有一定的可用空间，设备就可以轻松地从 super 中减去这部分空间。或者，设备只需确保 super 足够大，即可保证绝不需要 /data。

下面这些模型可以指导您根据这些变量调整 super 分区的大小。

依赖 /data

虚拟 A/B 鼓励缩减 super，以允许增加 /data 的大小。更新期间需要占用其中部分空间。为了解对可更新性的影响，就必须要知道在一段时间内可能拥有这部分可用空间量的设备数量所占百分比。确定这个数据在很大程度上取决于设备的硬件和用户在该设备上的行为。在下面的示例中，该数据称为 AllowedUserdataUse。

不采用压缩法

若不采用压缩法，整个 OTA 所需的快照大小与操作系统大致相同，因此在调整 super 的大小时必须考虑到这一点：

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  Super = Max(FinalDessertUpdate, FinalDessertSize * 2 - AllowedUserdataUse)

例如，假设某个虚拟 A/B 设备的出厂大小为 4 GB，预期增长率为 50%，并且了解几乎所有用户都有 1 GB 的可用空间（或者愿意释放最多 1 GB 的空间用于更新）。对于此设备，可以按如下所示调整 super 的大小：

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  Super = Max(6GB, 6GB * 2 - 1GB) = Max(6GB, 11GB)

因此，此设备应该具有 11 GB 的 super 分区。

采用压缩法

若采用压缩法，整个 OTA 所需的快照大小约为操作系统大小的 70%：

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  FinalOTASnapshotSize = FinalDessertSize * 0.7
  Super = Max(FinalDessertUpdate, FinalDessertSize + FinalOTASnapshotSize - AllowedUserdataUse)

例如，假设某个设备配置了虚拟 A/B 压缩，出厂大小为 4GB，预期增长率为 50%，并且了解几乎所有用户都有 1 GB 的可用空间（或者愿意释放最多 1 GB 的空间用于更新）。对于此设备，可以按如下所示调整 super 的大小： 

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  FinalOTASnapshotSize = 6GB * 0.7 = 4.2GB
  Super = Max(6GB, 6GB + 4.2GB - 1GB) = Max(6GB, 9.2GB) = 9.2GB

因此，此设备应该具有 9.2 GB 的 super 分区。

不依赖于 /data

如果您希望 OTA 从不需要 /data 上的快照空间，那么调整 super 的大小很简单。

不采用压缩法

对于未采用压缩法的虚拟 A/B 设备或普通 A/B 设备：

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  Super = FinalDessertSize * 2

例如，假设某个虚拟 A/B 设备的出厂大小为 4 GB，预期增长率为 50%。为了确保此设备从不将 /data 用于 OTA 快照，计算方法如下：

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  Super = FinalDessertSize * 2 = 12GB

因此，此设备应该具有 12 GB 的 super 分区。

采用压缩法

对于采用压缩法的虚拟 A/B 设备：

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  FinalOTASnapshotSize = FinalDessertSize * 0.7
  Super = FinalDessertSize + FinalOTASnapshotSize

例如，假设某个虚拟 A/B 压缩设备的出厂大小为 4 GB，预期增长率为 50%。为了确保此设备从不将 /data 用于 OTA 快照，计算方法如下：

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  FinalOTASnapshotSize = 6GB * 0.7 = 4.2GB
  Super = 6GB + 4.2GB = 10.2GB

因此，此设备应该具有 10.2 GB 的 super 分区。

注意事项

您可能很容易发现，如果出厂大小为 4 GB，而最终更新大小为 5 GB，那么 super 需要为 9 GB，而不是 10 GB。但是，如果首次更新和最终更新的大小均为 5 GB，那么 super 中的空间可能不足以完成最终更新。上述公式假设分区随时可能会增长。应用最终更新所需的空间可能与应用首次更新所需的空间相同。

请注意，压缩比是估计值。操作系统映像的压缩效果是优是劣取决于其内容。如果使用 EROFS 等压缩文件系统，虚拟 A/B 的进一步压缩带来的好处会减少。在这种情况下，最好使用其中一个未压缩公式作为准则。

计算大小

若要求出上述示例中 FinalDessertSize 的值，请将所有动态分区的大小相加。AOSP 动态分区映像包括：

  • system.img
  • vendor.img
  • product.img
  • system_ext.img
  • vendor_dlkm.img
  • system_dlkm.img

请务必根据非稀疏映像计算大小。构建 Android 12 或更低版本时，映像默认处于稀疏状态，可以通过 simg2img 变为非稀疏格式。

也可以通过 OTA 软件包计算分区大小。这样做还可以估算每个分区的虚拟 A/B 快照大小：

  python3 system/update_engine/scripts/payload_info.py path/to/ota-package.zip

或者，您也可以使用 OTA 分析工具。此工具不会上传任何文件，也不会在本地分析 OTA 软件包。

若要求出 ExpectedGrowth 的值，请使用之前发布的设备。使用最早和最近的 super 映像计算增长值。