Größe der Super-Partition festlegen

Die richtige Größe der Partition super ist wichtig für die Updatefähigkeit des Geräts. Die Größe wirkt sich direkt darauf aus, wie viele Updates ein Gerät erhalten kann und wie viele Nutzer diese Updates erfolgreich installieren können.

Es gibt einige wichtige Variablen zu berücksichtigen. Die erste ist die Werksgröße, also die Größe aller dynamischer Partitionen, wenn das Gerät zum ersten Mal geflasht wird. Die zweite ist die Wachstumsrate, also der Prozentsatz, um den die Größe des Betriebssystems während der gesamten Updatefähigkeit des Geräts zunimmt.

Außerdem können Virtual A/B-Geräte während eines Updates Speicherplatz auf /data verwenden. Dies muss bei der Größenbestimmung von super berücksichtigt werden. Wenn zu viel Speicherplatz auf /data benötigt wird, können einige Nutzer das Update nicht installieren (oder möchten es nicht installieren). Wenn jedoch bekannt ist, dass die meisten Nutzer einen bestimmten Prozentsatz an freiem Speicherplatz haben, können Geräte diesen Speicherplatz problemlos von super abziehen. Alternativ können Geräte garantieren, dass /data niemals benötigt wird, indem sie super einfach groß genug machen.

Im Folgenden finden Sie einige Modelle, die Ihnen bei der Größenbestimmung der Partition super anhand dieser Variablen helfen.

Auf /data angewiesen sein

Virtual A/B empfiehlt, super zu verkleinern, um die Größe von /data zu erhöhen. Ein Teil dieses Speicherplatzes wird während eines Updates benötigt. Um die Auswirkungen auf die Updatefähigkeit zu verstehen, ist es wichtig zu wissen, wie viel Prozent der Geräte im Laufe der Zeit wahrscheinlich so viel freien Speicherplatz haben. Diese Zahl hängt stark von der Hardware des Geräts und dem Nutzerverhalten ab. In den folgenden Beispielen wird diese Zahl als AllowedUserdataUse bezeichnet.

Ohne Komprimierung

Ohne Komprimierung benötigt ein vollständiges OTA einen Snapshot, der ungefähr so groß ist wie das Betriebssystem. Dies muss bei der Größenbestimmung von super berücksichtigt werden:

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  Super = Max(FinalDessertUpdate, FinalDessertSize * 2 - AllowedUserdataUse)

Betrachten wir beispielsweise ein Virtual A/B-Gerät mit einer Werksgröße von 4 GB, einem erwarteten Wachstum von 50 % und der Information, dass fast alle Nutzer 1 GB freien Speicherplatz haben (oder bereit sind, bis zu 1 GB Speicherplatz für ein Update freizugeben). Für dieses Gerät kann super so dimensioniert werden:

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  Super = Max(6GB, 6GB * 2 - 1GB) = Max(6GB, 11GB)

Dieses Gerät sollte also eine 11 GB große super-Partition haben.

Mit Komprimierung

Mit Komprimierung benötigt ein vollständiges OTA einen Snapshot, der ungefähr 70% der Größe des Betriebssystems entspricht:

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  FinalOTASnapshotSize = FinalDessertSize * 0.7
  Super = Max(FinalDessertUpdate, FinalDessertSize + FinalOTASnapshotSize - AllowedUserdataUse)

Betrachten wir beispielsweise ein Gerät, das mit Virtual A/B-Komprimierung konfiguriert ist, mit einer Werksgröße von 4 GB, einem erwarteten Wachstum von 50 % und der Information, dass fast alle Nutzer 1 GB freien Speicherplatz haben (oder bereit sind, bis zu 1 GB Speicherplatz für ein Update freizugeben). Für dieses Gerät kann super so dimensioniert werden: 

  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

Dieses Gerät sollte also eine 9, 2 GB große super-Partition haben.

Nicht auf /data angewiesen sein

Wenn Sie OTAs haben möchten, für die niemals Snapshot-Speicherplatz auf /data erforderlich ist, ist die Größenbestimmung von super ganz einfach.

Ohne Komprimierung

Für ein Virtual A/B-Gerät ohne Komprimierung oder ein normales A/B-Gerät:

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  Super = FinalDessertSize * 2

Betrachten wir beispielsweise ein Virtual A/B-Gerät mit einer Werksgröße von 4 GB und einem erwarteten Wachstum von 50%. Damit dieses Gerät /data niemals für OTA-Snapshots verwendet, sieht die Berechnung so aus:

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  Super = FinalDessertSize * 2 = 12GB

Dieses Gerät sollte also eine 12 GB große super-Partition haben.

Mit Komprimierung

Für ein Virtual A/B-Gerät mit Komprimierung:

  FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth)
  FinalOTASnapshotSize = FinalDessertSize * 0.7
  Super = FinalDessertSize + FinalOTASnapshotSize

Betrachten wir beispielsweise ein Virtual A/B-Komprimierungsgerät mit einer Werksgröße von 4 GB und einem erwarteten Wachstum von 50%. Damit dieses Gerät /data niemals für OTA-Snapshots verwendet, sieht die Berechnung so aus:

  FinalDessertSize = 4GB + (4GB * 0.5) = 6GB
  FinalOTASnapshotSize = 6GB * 0.7 = 4.2GB
  Super = 6GB + 4.2GB = 10.2GB

Dieses Gerät sollte also eine 10, 2 GB große super-Partition haben.

Vorsichtsmaßnahmen

Es mag verlockend sein, festzustellen, dass super bei einer Werksgröße von 4 GB und einem finalen Update von 5 GB 9 GB statt 10 GB groß sein muss. Wenn jedoch das erste und das finale Update jeweils 5 GB groß sind, reicht der Speicherplatz in super möglicherweise nicht für das finale Update aus. Die oben genannten Formeln gehen davon aus, dass das Wachstum der Partition jederzeit erfolgen kann. Der für die Installation des finalen Updates erforderliche Speicherplatz kann derselbe sein wie für die Installation des ersten Updates.

Die Komprimierungsverhältnisse sind Schätzungen. Ein Betriebssystem-Image kann je nach Inhalt besser oder schlechter komprimiert werden. Bei Verwendung eines komprimierten Dateisystems wie EROFS ist die zusätzliche Komprimierung durch Virtual A/B weniger effektiv. In diesem Fall ist es besser, eine der unkomprimierten Formeln als Richtlinie zu verwenden.

Größe berechnen

Um den Wert von FactorySize in den vorherigen Beispielen zu ermitteln, addieren Sie die Größen aller dynamischen Partitionen. Die dynamischen Partition-Images von AOSP sind:

  • system.img
  • vendor.img
  • product.img
  • system_ext.img
  • vendor_dlkm.img
  • system_dlkm.img

Berechnen Sie die Größe anhand von nicht sparsifizierten Images. Beim Erstellen von Android 12 oder niedriger werden Images standardmäßig sparsifiziert und können mit simg2img wieder nicht sparsifiziert werden.

Es ist auch möglich, die Partitionsgrößen aus einem OTA-Paket zu berechnen. Dabei wird auch die Virtual A/B-Snapshot-Größe für jede Partition geschätzt:

  python3 system/update_engine/scripts/payload_info.py path/to/ota-package.zip

Alternativ können Sie das OTA Analysis Tool verwenden. Mit diesem Tool werden keine Dateien hochgeladen und OTA-Pakete werden lokal analysiert.

Um den Wert von ExpectedGrowth zu ermitteln, verwenden Sie ein zuvor veröffentlichtes Gerät. Berechnen Sie das Wachstum anhand des frühesten und des neuesten super-Images.