调整 super 分区大小

正确调整 super 分区的大小对于设备的更新能力至关重要。大小直接影响设备可以进行的更新次数以及可以成功进行这些更新的用户数量。

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

此外，Virtual A/B 设备可以在更新期间使用 /data 上的空间，在调整 super 大小时必须考虑到这一点。如果 /data 上需要过多空间，则某些用户将无法（或不愿意）进行更新。但是，如果已知大多数用户都有一定百分比的可用空间，则设备可以放心地从 super 中减去该空间。或者，设备可以保证永远不需要 /data，只需将 super 做到足够大即可。

以下是一些模型，可帮助根据这些变量指导 super 分区大小的调整。

依赖 /data

Virtual A/B 鼓励缩小 super 以允许增加 /data 的大小。更新期间需要其中一些空间。为了解对可更新性的影响，必须知道随着时间的推移，可能有多少百分比的设备具有该数量的可用空间。弄清楚这个数字在很大程度上取决于设备的硬件和用户对该设备的行为。在以下示例中，此数字称为 AllowedUserdataUse。

不压缩

在不压缩的情况下，完整 OTA 需要一个与操作系统大小大致相同的快照，因此在调整 super 大小时必须考虑到这一点

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

例如，考虑一个 Virtual 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)

例如，考虑一个配置了 Virtual 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 大小就很简单了。

不压缩

对于不压缩的 Virtual A/B 设备或普通的 A/B 设备

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

例如，考虑一个出厂大小为 4 GB 且预期增长为 50% 的 Virtual A/B 设备。为了确保此设备永远不使用 /data 进行 OTA 快照，其计算方式如下所示

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

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

压缩

对于压缩的 Virtual A/B 设备

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

例如，考虑一个压缩的 Virtual 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 等压缩文件系统，则 Virtual A/B 的额外压缩会产生收益递减。在这种情况下，最好使用未压缩的公式之一作为指导。

计算大小

要在以上示例中查找 FinalDessertSize 的值，请将所有动态分区的大小加在一起。AOSP 动态分区镜像为

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

请务必根据未稀疏化的镜像计算大小。在构建 Android 12 或更低版本时，默认情况下镜像会被稀疏化，并且可以使用 simg2img 进行未稀疏化。

也可以从 OTA 软件包计算分区大小。这样做还可以估计每个分区的 Virtual A/B 快照大小

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

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

要查找 ExpectedGrowth 的值，请使用以前发布的设备。使用最早和最新的 super 镜像来计算增长。