設定超級分區大小

正確設定 super 分割區大小，對於裝置的更新可行性相當重要。大小會直接影響裝置可安裝的更新數量，以及有多少使用者可成功安裝這些更新。

您需要考量幾個重要變數。第一個是「工廠大小」，也就是裝置首次刷新時，所有動態分區的大小。第二個是成長率，也就是在裝置可更新的整個生命週期中，作業系統大小增加的百分比。

此外，虛擬 A/B 裝置可以在更新期間使用 /data 上的空間，因此在調整 super 大小時，必須考量這項因素。如果 /data 需要太多空間，部分使用者可能無法 (或不願意) 更新。不過，如果知道大多數使用者都有一定百分比的可用空間，裝置就可以輕鬆從 super 中減去該空間。或者，裝置只要讓 super 足夠大，就能保證永遠不需要 /data。

以下是一些模型，可協助您根據這些變數設定 super 分割區大小。

依賴 /data

虛擬 A/B 版本會縮小 super，以便增加 /data 的大小。更新時需要部分空間。如要瞭解更新可用性受到的影響，就必須瞭解隨著時間推移，有多少百分比的裝置可能會擁有這麼多可用空間。這個數字的計算方式，取決於裝置的硬體和使用者行為。在以下範例中，這個編號稱為 AllowedUserdataUse。

未壓縮

在未壓縮的情況下，完整 OTA 需要的快照大小大致與 OS 相同，因此在調整 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 需要的快照大小約為 OS 大小的 70%：

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

舉例來說，假設某裝置已設定虛擬 A/B 壓縮功能，工廠大小為 4 GB，預期成長率為 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 等壓縮檔案系統，Virtual 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 圖片來計算成長率。