正確調整super分區的大小對於設備可更新性很重要。大小直接影響設備可以進行多少更新以及有多少用戶可以成功進行這些更新。
有幾個重要的變量需要考慮。第一個是出廠大小，即設備第一次刷機時所有動態分區的大小。第二個是增長率，它是操作系統大小在設備的整個可更新生命週期中增加的百分比。
此外，虛擬 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)
例如，考慮一個工廠大小為 4 GB、預期增長 50% 的虛擬 A/B 設備，並且知道幾乎所有用戶都有 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% 的 OS 大小的快照：
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) FinalOTASnapshotSize = FinalDessertSize * 0.7 Super = Max(FinalDessertUpdate, FinalDessertSize + FinalOTASnapshotSize - AllowedUserdataUse)
例如，考慮一個配置了虛擬 A/B 壓縮的設備，出廠大小為 4GB，預期增長 50%，並且知道幾乎所有用戶都有 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
例如，考慮一個工廠大小為 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 等壓縮文件系統，來自虛擬 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圖像來計算增長。