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 ausführen kann und wie viele Nutzer diese Aktualisierungen.

Es gibt einige wichtige Variablen, die Sie berücksichtigen sollten. Die erste ist die Werkgröße, die Größe aller dynamischen Partitionen beim ersten Flash-Vorgang auf dem Gerät darstellt. Der zweite ist die Wachstumsrate, also der Prozentsatz, um den sich die Größe des Betriebssystems während der gesamten Aktualisierungsdauer des Geräts erhöht.

Außerdem können virtuelle A/B-Geräte während eines Updates Speicherplatz auf /data belegen. Dies muss bei der Festlegung der Größe von /data berücksichtigt werden. Wenn auf /data zu viel Speicherplatz benötigt wird, können einige Nutzer das Update nicht installieren oder sind nicht bereit dazu. Wenn es jedoch wissen, dass bei den meisten Nutzern ein gewisser Prozentsatz an Speicherplatz kostenlos ist. diesen Bereich von super. Alternativ können Geräte dafür sorgen, dass /data nie benötigt wird, indem sie super einfach groß genug machen.

Unten finden Sie einige Modelle zur Orientierung für die super-Partitionsgröße. Variablen.

Auf /data zugreifen

Bei virtuellen A/B-Tests wird empfohlen, super zu verkleinern, um die Größe von /data zu erhöhen. Ein Teil des Speicherplatzes wird während eines Updates benötigt. Um die Auswirkungen auf sollten Sie wissen, wie viel Prozent der Geräte wahrscheinlich im Laufe der Zeit kostenlos wird. 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 Zahl als AllowedUserdataUse

Ohne Komprimierung

Ohne Komprimierung benötigt ein vollständiger Over-the-air-Aktualisierungsvorgang einen Snapshot mit ungefähr derselben Größe wie das Betriebssystem. Dies muss bei der Festlegung der Größe von super berücksichtigt werden:

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

Nehmen wir zum Beispiel ein virtuelles A/B-Gerät mit einer Werksgröße von 4 GB, bei dem ein Anstieg von 50 % und wissen, dass fast alle Nutzer 1 GB kostenlos haben oder bereit sind, bis zu 1 GB freizuschalten. Platz für ein Update). 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 daher eine super-Partition mit 11 GB haben.

Mit Kompression

Bei der Komprimierung benötigt ein vollständiger Over-the-air-Aktualisierungsvorgang einen Snapshot mit etwa 70 % der Größe des Betriebssystems:

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

Angenommen, Sie haben ein Gerät mit virtueller A/B-Komprimierung konfiguriert, das ab Werk 4 GB groß ist, mit einem erwarteten Wachstum von 50 % und Sie wissen, 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 die Größe von super angepasst werden etwa so: 

  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

Daher sollte dieses Gerät eine 9,2-GB-super-Partition haben.

Ohne /data

Wenn Sie OTAs haben möchten, für die auf /data nie Snapshot-Speicherplatz benötigt wird, ist die Größe von super ganz einfach festzulegen.

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

Angenommen, Sie haben ein virtuelles A/B-Gerät mit einer Werksgröße von 4 GB und einem erwarteten Wachstum von 50 %. Damit dieses Gerät niemals /data für OTA-Snapshots verwendet, wird bei der Berechnung Beispiel:

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

Daher sollte dieses Gerät eine 12-GB-super-Partition haben.

Mit Komprimierung

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

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

Angenommen, Sie haben ein virtuelles A/B-Komprimierungsgerät mit einer Werksgröße von 4 GB und einem erwarteten Wachstum von 50 %. Damit dieses Gerät niemals /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

Daher sollte dieses Gerät eine super-Partition mit 10,2 GB haben.

Einschränkungen

Es könnte verlockend sein, anzunehmen, dass super 9 GB statt 10 GB betragen muss, wenn die Größe der Werksversion 4 GB und die endgültige Aktualisierung 5 GB beträgt. Wenn das erste und das letzte Update jedoch jeweils 5 GB groß sind, ist in super möglicherweise nicht genügend Speicherplatz für das letzte Update verfügbar. Bei den obigen Formeln wird davon ausgegangen, dass ein Partitionswachstum jederzeit ändern. Der für die Anwendung des letzten Updates erforderliche Speicherplatz kann mit dem für die Anwendung des ersten Updates übereinstimmen.

Beachten Sie, dass es sich bei den Komprimierungsverhältnissen um eine Schätzung handelt. Je nach Inhalt kann ein Betriebssystem-Image besser oder schlechter komprimiert werden. Wenn Sie ein komprimiertes Dateisystem wie EROFS verwenden, ist die zusätzliche Komprimierung durch Virtual A/B nur begrenzt effektiv. In diesem Fall sollten Sie eine der nicht komprimierten Formeln als Anhaltspunkt verwenden.

Größe berechnen

Um den Wert von FinalDessertSize in den obigen Beispielen zu ermitteln, addieren Sie die Größe aller dynamischen Partitionen. Die dynamischen AOSP-Partitions-Images sind:

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

Berechnen Sie die Größe anhand der nicht geparsten Bilder. Bei der Entwicklung von Android 12 oder niedriger sind Bilder standardmäßig dünnbesetzt und können nicht mit simg2img

Es ist auch möglich, Partitionsgrößen aus einem OTA-Paket zu berechnen. Dadurch 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 kannst du das OTA-Analysetool verwenden. Dieses Tool lädt keine Dateien hoch und analysiert OTA-Pakete lokal.

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