Größe der Super-Partition festlegen

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

Dabei sind einige wichtige Variablen zu berücksichtigen. Die erste ist die Größe der Fabrik, also die Größe aller dynamischen 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 über die gesamte Update-Lebensdauer des Geräts zunimmt.

Außerdem kann bei virtuellen A/B-Geräten während eines Updates Speicherplatz auf /data verwendet werden. Dies muss bei der Festlegung der Größe von super berücksichtigt werden. Wenn auf /data zu viel Speicherplatz benötigt wird, können oder wollen einige Nutzer das Update nicht durchführen. Wenn jedoch bekannt ist, dass die meisten Nutzer einen bestimmten Prozentsatz an Speicherplatz kostenlos haben, kann dieser Speicherplatz problemlos von super abgezogen werden. Oder Geräte können dafür sorgen, dass /data nie benötigt wird, indem sie super groß genug machen.

Unten finden Sie einige Modelle, die Ihnen bei der Festlegung der Größe von super-Partitionen auf Grundlage dieser Variablen helfen können.

Auf /data verlassen

Bei virtuellen A/B-Tests wird super verkleinert, 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 Aktualisierbarkeit zu verstehen, ist es wichtig zu wissen, auf wie viel Prozent der Geräte im Laufe der Zeit wahrscheinlich so viel Speicherplatz kostenlos ist. Die Ermittlung dieser Zahl hängt stark von der Hardware des Geräts und dem Nutzerverhalten auf diesem Gerät ab. In den folgenden Beispielen wird diese Nummer als AllowedUserdataUse bezeichnet.

Ohne Komprimierung

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

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

Nehmen wir beispielsweise ein virtuelles A/B-Gerät mit einer werkseitigen Größe von 4 GB, einem erwarteten Wachstum von 50 % und der Information an, 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

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

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

Nehmen wir beispielsweise ein Gerät an, das mit Virtual A/B-Kompression konfiguriert ist, eine werkseitige Größe von 4 GB hat, ein erwartetes Wachstum von 50 % aufweist und bei dem bekannt ist, 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.

Ohne Verwendung von /data

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

Ohne Komprimierung

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

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

Nehmen wir beispielsweise ein virtuelles A/B-Gerät mit einer werkseitigen Größe von 4 GB und einem erwarteten Wachstum von 50%. Damit dieses Gerät nie /data für OTA-Snapshots verwendet, würde die Berechnung so aussehen:

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

Dieses Gerät sollte also eine 12-GB-Partition super 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 virtuelles A/B-Komprimierungsgerät mit einer werkseitigen Größe von 4 GB und einem erwarteten Wachstum von 50%. Damit dieses Gerät nie /data 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.

Einschränkungen

Es könnte verlockend sein, festzustellen, dass super 9 GB statt 10 GB groß sein muss, wenn die Größe der Werksversion 4 GB und die Größe des endgültigen Updates 5 GB beträgt. Wenn das erste und das letzte Update jedoch jeweils 5 GB groß sind, ist möglicherweise nicht genügend Speicherplatz in super für das letzte Update vorhanden. Bei den oben genannten Formeln wird davon ausgegangen, dass das Wachstum von Partitionen jederzeit erfolgen kann. Der Speicherplatz, der für das endgültige Update benötigt wird, kann derselbe sein wie für das erste Update.

Die Komprimierungsverhältnisse sind Schätzungen. Ein Betriebssystem-Image kann je nach Inhalt besser oder schlechter komprimiert werden. Wenn Sie ein komprimiertes Dateisystem wie EROFS verwenden, bringt die zusätzliche Komprimierung durch Virtual A/B nur noch wenig. 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 AOSP-Images für dynamische Partitionen sind:

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

Die Größe muss auf Grundlage von nicht spärlichen Bildern berechnet werden. Beim Erstellen von Android 12 oder niedriger werden Bilder standardmäßig komprimiert und können mit simg2img dekomprimiert werden.

Es ist auch möglich, die Partitionsgrößen aus einem OTA-Paket zu berechnen. Dabei wird auch die Größe des virtuellen A/B-Snapshots 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. OTA-Pakete werden lokal analysiert.

Verwenden Sie ein zuvor veröffentlichtes Gerät, um den Wert von ExpectedGrowth zu ermitteln. Verwenden Sie das früheste und das aktuelle super-Bild, um das Wachstum zu berechnen.