設定超級分區大小

正確調整 super 分區大小，對裝置更新能力至關重要。大小直接影響裝置可接受的更新次數，以及可順利更新的使用者人數。

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

此外，虛擬 A/B 裝置在更新期間可以使用 /data 上的空間，因此在調整 super 大小時，必須將這點納入考量。如果/data需要太多空間，部分使用者將無法 (或不願) 進行更新。不過，如果已知大多數使用者都有一定比例的可用空間，裝置就能放心地從 super 中減去該空間。或者，裝置可以確保永遠不需要 /data，只要將 super 設得夠大即可。

以下是一些模型，可協助您根據這些變數調整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)

舉例來說，假設某裝置設定了 Virtual 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 的空間可能不足以進行最終更新。上述公式假設分割區成長可能隨時發生。套用最終更新所需的空間，可能與套用首次更新時相同。

請注意，壓縮比是預估值。OS 映像檔的壓縮效果可能會因內容而異。如果使用 EROFS 等壓縮檔案系統，Virtual A/B 的額外壓縮功能效益會遞減。在這種情況下，建議您使用其中一個未壓縮的公式做為參考。

計算大小

如要找出上述範例中的 FactorySize 值，請將所有動態分割區的大小加總。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 圖片計算成長。