Die richtige Dimensionierung der super ist wichtig für die Aktualisierbarkeit des Geräts. Die Größe wirkt sich direkt darauf aus, wie viele Updates ein Gerät durchführen kann und wie viele Benutzer diese Updates erfolgreich durchführen können.
Es sind einige wichtige Variablen zu berücksichtigen. Die erste ist die Werksgröße , also die Größe aller dynamischen Partitionen beim ersten Flashen des Geräts. Die zweite ist die Wachstumsrate , also der Prozentsatz, um den sich die Betriebssystemgröße über die gesamte aktualisierbare Lebensdauer des Geräts erhöht.
Darüber hinaus können virtuelle A/B-Geräte während eines Updates Speicherplatz auf /data beanspruchen, was bei der Dimensionierung super berücksichtigt werden muss. Wenn auf /data zu viel Speicherplatz benötigt wird, können (oder wollen) einige Benutzer das Update nicht durchführen. Wenn jedoch bekannt ist, dass die meisten Benutzer über einen gewissen Prozentsatz an freiem Speicherplatz verfügen, können Geräte diesen Speicherplatz problemlos von super abziehen. Oder Geräte können garantieren, dass /data nie benötigt wird, indem sie einfach super groß genug gemacht werden.
Im Folgenden finden Sie einige Modelle, die bei der Größenbestimmung super basierend auf diesen Variablen helfen sollen.
Verlassen Sie sich auf /data
Virtual A/B fördert die super , um eine Vergrößerung von /data zu ermöglichen. Ein Teil dieses Speicherplatzes wird während eines Updates benötigt. Um die Auswirkungen auf die Aktualisierbarkeit zu verstehen, ist es wichtig zu wissen, wie viel Prozent der Geräte im Laufe der Zeit voraussichtlich über so viel Speicherplatz verfügen werden. Die Ermittlung dieser Zahl hängt stark von der Hardware des Geräts und dem Benutzerverhalten dieses Geräts ab. In den folgenden Beispielen wird diese Nummer als AllowedUserdataUse bezeichnet.
Ohne Komprimierung
Ohne Komprimierung benötigt ein vollständiger OTA einen Snapshot, der ungefähr die gleiche Größe wie das Betriebssystem hat. Dies muss also bei der super Dimensionierung berücksichtigt werden:
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) Super = Max(FinalDessertUpdate, FinalDessertSize * 2 - AllowedUserdataUse)
Betrachten Sie beispielsweise ein virtuelles A/B-Gerät mit einer Werksgröße von 4 GB, einem erwarteten Wachstum von 50 % und dem Wissen, dass fast alle Benutzer 1 GB frei haben (oder bereit sind, bis zu 1 GB Speicherplatz für ein Update freizugeben). . Für dieses Gerät kann super wie folgt dimensioniert werden:
FinalDessertSize = 4GB + (4GB * 0.5) = 6GB Super = Max(6GB, 6GB * 2 - 1GB) = Max(6GB, 11GB)
Daher sollte dieses Gerät über eine 11 GB super verfügen.
Mit Komprimierung
Bei Komprimierung benötigt ein vollständiger OTA einen Snapshot von etwa 70 % der Größe des Betriebssystems:
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) FinalOTASnapshotSize = FinalDessertSize * 0.7 Super = Max(FinalDessertUpdate, FinalDessertSize + FinalOTASnapshotSize - AllowedUserdataUse)
Stellen Sie sich beispielsweise ein Gerät vor, das mit virtueller A/B-Komprimierung konfiguriert ist, mit einer Werksgröße von 4 GB, einem erwarteten Wachstum von 50 % und dem Wissen, dass fast alle Benutzer 1 GB frei haben (oder bereit sind, bis zu 1 GB Speicherplatz dafür freizugeben). ein Update). Für dieses Gerät kann super wie folgt 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
Daher sollte dieses Gerät über eine 9,2 GB super verfügen.
Ohne auf /data angewiesen zu sein
Wenn Sie OTAs haben möchten, die niemals Snapshot-Speicherplatz auf /data benötigen, ist super Skalierung 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
Betrachten Sie beispielsweise ein virtuelles A/B-Gerät mit einer Werksgröße von 4 GB und einem erwarteten Wachstum von 50 %. Um sicherzustellen, dass dieses Gerät niemals /data für OTA-Snapshots verwendet, würde seine Berechnung wie folgt aussehen:
FinalDessertSize = 4GB + (4GB * 0.5) = 6GB Super = FinalDessertSize * 2 = 12GB
Daher sollte dieses Gerät über eine 12 GB super verfügen.
Mit Komprimierung
Für ein virtuelles A/B-Gerät mit Komprimierung:
FinalDessertSize = FactorySize + (FactorySize * ExpectedGrowth) FinalOTASnapshotSize = FinalDessertSize * 0.7 Super = FinalDessertSize + FinalOTASnapshotSize
Betrachten Sie beispielsweise ein virtuelles A/B-Komprimierungsgerät mit einer Werksgröße von 4 GB und einem erwarteten Wachstum von 50 %. Um sicherzustellen, dass dieses Gerät niemals /data für OTA-Snapshots verwendet, würde seine Berechnung wie folgt aussehen:
FinalDessertSize = 4GB + (4GB * 0.5) = 6GB FinalOTASnapshotSize = 6GB * 0.7 = 4.2GB Super = 6GB + 4.2GB = 10.2GB
Daher sollte dieses Gerät über eine 10,2 GB super verfügen.
Vorbehalte
Es könnte verlockend sein zu beobachten, dass super 9 GB und nicht 10 GB groß sein muss, wenn die Werksgröße 4 GB beträgt und das endgültige Update 5 GB beträgt. Wenn jedoch sowohl das erste Update als auch das letzte Update 5 GB groß sind, reicht der Speicherplatz in super möglicherweise nicht für das letzte Update aus. Bei den obigen Formeln wird davon ausgegangen, dass es jederzeit zu einem Partitionswachstum kommen kann. Der zum Anwenden des letzten Updates benötigte Speicherplatz ist möglicherweise derselbe, der zum Anwenden des ersten Updates erforderlich ist.
Beachten Sie, dass es sich bei den Komprimierungsverhältnissen um Schätzungen handelt. Ein Betriebssystem-Image kann je nach Inhalt besser oder schlechter komprimiert werden. Bei Verwendung eines komprimierten Dateisystems wie EROFS führt die zusätzliche Komprimierung durch Virtual A/B zu geringeren Erträgen. In diesem Fall ist es besser, eine der unkomprimierten Formeln als Richtlinie zu verwenden.
Messung
Um den Wert von FinalDessertSize in den obigen Beispielen zu ermitteln, addieren Sie die Größen aller dynamischen Partitionen. Die dynamischen AOSP-Partitionsbilder sind:
-
system.img -
vendor.img -
product.img -
system_ext.img -
vendor_dlkm.img -
system_dlkm.img
Stellen Sie sicher, dass Sie die Größe basierend auf nicht gesparten Bildern berechnen. Beim Erstellen von Android 12 oder niedriger werden Bilder standardmäßig mit Sparsing versehen und können mit simg2img aufgehoben werden.
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
Oder Sie können das OTA-Analysetool verwenden. Dieses Tool lädt keine Dateien hoch und analysiert OTA-Pakete lokal.
Um den Wert von ExpectedGrowth zu ermitteln, verwenden Sie ein zuvor veröffentlichtes Gerät. Verwenden Sie das früheste und das neueste super , um das Wachstum zu berechnen.