Google は、黒人コミュニティに対する人種平等の促進に取り組んでいます。取り組みを見る

super のサイズを設定する方法

デバイスの更新可能性を高めるには、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 の最も古いイメージと最新のイメージを使用して増加率を計算します。