正確調整super分割區的大小對於裝置的可更新性非常重要。大小直接影響設備可以進行的更新數量以及有多少用戶可以成功進行這些更新。
有幾個重要的變數需要考慮。第一個是factory size ，它是裝置首次刷新時所有動態分割區的大小。第二個是成長率，它是作業系統大小在裝置的整個可更新生命週期內增加的百分比。
此外，虛擬 A/B 裝置可以在更新期間使用/data上的空間，在調整super時必須考慮這一點。如果/data上需要太多空間，則某些使用者無法（或不願意）進行更新。但是，如果知道大多數用戶都有一定比例的可用空間，那麼設備可以輕鬆地從super中減去該空間。或者，設備可以保證永遠不需要/data ，只需將super設定得足夠大即可。
以下是一些模型，可協助指導基於這些變數的super分割區大小調整。
依賴/數據
虛擬 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%，並且知道幾乎所有用戶都有 1GB 可用空間（或願意釋放最多 1GB 空間用於存儲）更新）。對於此設備， 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
例如，考慮一個工廠大小為 4 GB 且預期成長 50% 的虛擬 A/B 設備。為了確保該設備永遠不會使用/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
例如，考慮工廠大小為 4 GB 且預期成長 50% 的虛擬 A/B 壓縮設備。為了確保該設備永遠不會使用/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圖像來計算增長。