デバイスの更新可能性を高めるには、super
パーティションのサイズを正しく設定することが重要です。このサイズは、デバイスが受け取ることができる更新の数と、それらの更新を完了できるユーザーの数に直接影響します。
考慮すべき重要な変数がいくつかあります。1 つ目は初期設定サイズです。これは、デバイスに最初に書き込むときのすべての動的パーティションの合計サイズです。2 つ目は増加率です。これは、デバイスの更新可能な期間全体で OS のサイズが大きくなる割合(パーセンテージ)です。
また、仮想 A/B デバイスは、更新の際に /data
のスペースを使用できるため、super
のサイズを設定する際はこの点も考慮する必要があります。/data
で必要となるスペースが多すぎると、一部のユーザーは更新を行えません(または希望しません)。ただし、ほとんどのユーザーに一定の割合の空き容量があることがわかっていれば、デバイスは super
からその容量を安心して差し引くことができます。また、デバイスは、単に super
を大きくすることによって、/data
が不要であることを保証することもできます。
これらの変数に基づいて super
パーティションのサイズを設定する場合に役立つモデルを以下に示します。
/data を利用する
仮想 A/B は、/data
のサイズを大きくすることができるよう super
の圧縮を奨励しています。更新の際は、このスペースの一部が必要になります。更新可能性への影響を把握するには、その空き容量が長期間確保されている可能性が高いデバイスの割合を特定することが大切です。この数値の特定は、デバイスのハードウェアとそのデバイスでのユーザーの行動に大きく左右されます。以下の例では、この数値を AllowedUserdataUse
とします。
圧縮なし
圧縮なしの場合、フル OTA には、OS とほぼ同じサイズのスナップショットが必要となるため、super
のサイズを設定する際には以下の点を考慮してください。
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) Super = Max(FinalDessertUpdate, FinalDessertSize * 2 - AllowedUserdataUse)
たとえば、仮想 A/B デバイスの初期設定サイズ(FactorySize)が 4 GB、予想増加率(ExpectedGrowth)が 50% で、ほぼすべてのユーザーが 1 GB の空き容量を確保できる(または、更新用に最大 1 GB の空き容量を用意できる)ことがわかっているとします。このデバイスの場合、super
のサイズは以下のように求めることができます。
FinalDessertSize = 4GB + (4GB * 0.5) = 6GB Super = Max(6GB, 6GB * 2 - 1GB) = Max(6GB, 11GB)
つまり、このデバイスに必要な super
パーティションのサイズは 11 GB です。
圧縮あり
圧縮ありの場合、フル OTA には OS のサイズの約 70% のスナップショットが必要となります。
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) FinalOTASnapshotSize = FinalDessertSize * 0.7 Super = Max(FinalDessertUpdate, FinalDessertSize + FinalOTASnapshotSize - AllowedUserdataUse)
たとえば、仮想 A/B 圧縮ありで設定されたデバイスの初期設定サイズ(FactorySize)が 4 GB、予想増加率(ExpectedGrowth)が 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
つまり、このデバイスに必要な super
パーティションのサイズは 9.2 GB です。
/data を利用しない
OTA で /data
にスナップショット分のスペースを必要としない場合は、super
のサイズ設定は簡単です。
圧縮なし
圧縮なしの仮想 A/B デバイス、または通常の A/B デバイスの場合:
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) Super = FinalDessertSize * 2
たとえば、仮想 A/B デバイスの初期設定サイズ(FactorySize)が 4 GB、予想増加率(ExpectedGrowth)が 50% とします。このデバイスで OTA のスナップショットに /data
を使用しない場合、計算は次のようになります。
FinalDessertSize = 4GB + (4GB * 0.5) = 6GB Super = FinalDessertSize * 2 = 12GB
つまり、このデバイスに必要な super
パーティションのサイズは 12 GB です。
圧縮あり
圧縮ありの仮想 A/B デバイスの場合:
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) FinalOTASnapshotSize = FinalDessertSize * 0.7 Super = FinalDessertSize + FinalOTASnapshotSize
たとえば、仮想 A/B 圧縮デバイスの初期設定サイズ(FactorySize)が 4 GB、予想増加率(ExpectedGrowth)が 50% とします。このデバイスで OTA のスナップショットに /data
を使用しない場合、計算は次のようになります。
FinalDessertSize = 4GB + (4GB * 0.5) = 6GB FinalOTASnapshotSize = 6GB * 0.7 = 4.2GB Super = 6GB + 4.2GB = 10.2GB
つまり、このデバイスに必要な super
パーティションのサイズは 10.2 GB です。
注意点
初期設定サイズ(FactorySize)が 4 GB で、最後の更新が 5 GB であれば、super
に必要なのは 10 GB ではなく 9 GB ではないかと思われがちですが、最初の更新と最後の更新がどちらも 5 GB の場合は、最後の更新で super
のスペースが不足する可能性があります。上記の数式は、パーティションの拡張がいつでも発生する可能性があることを前提としています。最後の更新の適用に必要な容量が、最初の更新の適用に必要な容量と同じになることもあります。
圧縮率は推定値です。OS イメージは、コンテンツに応じて圧縮の状態が変わることがあります。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
の最も古いイメージと最新のイメージを使用して増加率を計算します。