Häufig gestellte Fragen

Hat Google auf irgendwelchen Geräten A/B-OTAs verwendet?

Ja. Der Marketingname für A/B-Updates lautet Seamless Updates . Pixel- und Pixel XL-Telefone ab Oktober 2016 werden mit A/B ausgeliefert, und alle Chromebooks verwenden dieselbe update_engine Implementierung von A/B. Die erforderliche Plattformcode-Implementierung ist in Android 7.1 und höher öffentlich.

Warum sind A/B-OTAs besser?

A/B-OTAs bieten ein besseres Benutzererlebnis bei der Aktualisierung. Messungen anhand monatlicher Sicherheitsupdates zeigen, dass sich diese Funktion bereits als Erfolg erwiesen hat: Im Mai 2017 führen 95 % der Pixel-Besitzer das neueste Sicherheitsupdate nach einem Monat aus, verglichen mit 87 % der Nexus-Benutzer, und Pixel-Benutzer aktualisieren früher als Nexus-Benutzer. Fehler beim Aktualisieren von Blöcken während eines OTA führen nicht mehr dazu, dass ein Gerät nicht startet; Bis das neue Systemabbild erfolgreich gestartet wurde, behält Android die Möglichkeit, auf das vorherige funktionierende Systemabbild zurückzugreifen.

Wie hat sich A/B auf die Pixel-Partitionsgrößen 2016 ausgewirkt?

Die folgende Tabelle enthält Details zur Versand-A/B-Konfiguration im Vergleich zur intern getesteten Nicht-A/B-Konfiguration:

A/B-Updates erfordern eine Erhöhung des Flash-Speichers um nur 320 MiB, wobei durch das Entfernen der Wiederherstellungspartition 32 MiB eingespart werden und durch das Entfernen der Cache-Partition weitere 100 MiB erhalten bleiben. Dadurch werden die Kosten der B-Partitionen für den Bootloader, die Boot-Partition und die Radio-Partition ausgeglichen. Die Größe der Herstellerpartition hat sich verdoppelt (wobei der größte Teil der Größe zugenommen hat). Das A/B-Systembild von Pixel ist halb so groß wie das ursprüngliche Nicht-A/B-Systembild.

Bei den intern getesteten Pixel-A/B- und Nicht-A/B-Varianten (nur A/B wurde ausgeliefert) unterschied sich der genutzte Speicherplatz nur um 320 MiB. Auf einem 32-GiB-Gerät sind es knapp 1 %. Bei einem 16-GiB-Gerät wären dies weniger als 2 % und bei einem 8-GiB-Gerät fast 4 % (vorausgesetzt, alle drei Geräte hätten das gleiche Systemabbild).

Warum haben Sie SquashFS nicht verwendet?

Wir haben mit SquashFS experimentiert, konnten jedoch nicht die für ein High-End-Gerät gewünschte Leistung erzielen. Wir verwenden oder empfehlen SquashFS nicht für Handheld-Geräte.

Genauer gesagt ermöglichte SquashFS eine Größeneinsparung von etwa 50 % auf der Systempartition, aber die überwiegende Mehrheit der gut komprimierten Dateien waren die vorkompilierten .odex-Dateien. Diese Dateien hatten eine sehr hohe Komprimierungsrate (nahe 80 %), aber die Komprimierungsrate für den Rest der Systempartition war viel niedriger. Darüber hinaus führte SquashFS in Android 7.0 zu folgenden Leistungsproblemen:

• Pixel verfügt im Vergleich zu früheren Geräten über einen sehr schnellen Flash, aber nicht über eine große Anzahl an CPU-Reservezyklen. Das Lesen von weniger Bytes aus dem Flash, aber der Bedarf an mehr CPU für I/O war ein potenzieller Engpass.
• E/A-Änderungen, die bei einem künstlichen Benchmark-Lauf auf einem entlasteten System gut funktionieren, funktionieren manchmal bei realen Anwendungsfällen unter realer Last nicht gut (z. B. Krypto auf Nexus 6).
• Beim Benchmarking ergaben sich an manchen Stellen Rückschritte von 85 %.

Während SquashFS ausgereifter wird und Funktionen zur Reduzierung der CPU-Belastung hinzufügt (z. B. eine Whitelist häufig aufgerufener Dateien, die nicht komprimiert werden sollten), werden wir es weiterhin evaluieren und den Geräteherstellern Empfehlungen geben.

Wie haben Sie die Größe der Systempartition ohne SquashFS halbiert?

Anwendungen werden in APK-Dateien gespeichert, bei denen es sich eigentlich um ZIP-Archive handelt. Jede .apk-Datei enthält eine oder mehrere .dex-Dateien mit portablem Dalvik-Bytecode. Eine .odex-Datei (optimiertes .dex) befindet sich getrennt von der .apk-Datei und kann gerätespezifischen Maschinencode enthalten. Wenn eine .odex-Datei verfügbar ist, kann Android Anwendungen mit vorzeitiger Kompilierungsgeschwindigkeit ausführen, ohne bei jedem Start der Anwendung auf die Kompilierung des Codes warten zu müssen. Eine .odex-Datei ist nicht unbedingt erforderlich: Android kann den .dex-Code tatsächlich direkt über Interpretation oder Just-In-Time-Kompilierung (JIT) ausführen, aber eine .odex-Datei bietet die beste Kombination aus Startgeschwindigkeit und Laufzeitgeschwindigkeit, wenn Platz ist vorhanden.

Beispiel: Für die Datei „installed-files.txt“ von einem Nexus 6P mit Android 7.1 und einer Gesamtgröße des System-Images von 2628 MB (2755792836 Bytes) ist die Aufteilung der größten Beiträge zur Gesamtgröße des System-Images nach Dateityp wie folgt:

Diese Zahlen sind auch für andere Geräte ähnlich, sodass .odex-Dateien auf Nexus-/Pixel-Geräten etwa die Hälfte der Systempartition einnehmen. Das bedeutete, dass wir weiterhin ext4 verwenden konnten, aber die .odex-Dateien werkseitig auf die B-Partition schreiben und sie dann beim ersten Start nach /data kopieren konnten. Der tatsächlich mit ext4 A/B verwendete Speicher ist identisch mit SquashFS A/B, denn wenn wir SquashFS verwendet hätten, hätten wir die vorgewählten .odex-Dateien auf system_a statt auf system_b versendet.

Bedeutet das Kopieren von .odex-Dateien nach /data nicht, dass der auf /system gesparte Speicherplatz auf /data verloren geht?

Nicht genau. Auf Pixel nehmen .odex-Dateien den größten Teil des Speicherplatzes für Apps ein, die normalerweise auf /data vorhanden sind. Für diese Apps werden Google Play-Updates benötigt, sodass die APK- und Odex-Dateien im Systemabbild die meiste Zeit der Lebensdauer des Geräts ungenutzt bleiben. Solche Dateien können vollständig ausgeschlossen und durch kleine, profilgesteuerte .odex-Dateien ersetzt werden, wenn der Benutzer tatsächlich jede App verwendet (und somit keinen Platz für Apps benötigt, die der Benutzer nicht verwendet). Einzelheiten finden Sie im Google I/O 2016-Vortrag „The Evolution of Art“ .

Der Vergleich ist aus einigen wesentlichen Gründen schwierig:

• Von Google Play aktualisierte Apps hatten ihre .odex-Dateien immer in /data , sobald sie ihr erstes Update erhielten.
• Apps, die der Benutzer nicht ausführt, benötigen überhaupt keine .odex-Datei.
• Bei der profilgesteuerten Kompilierung werden kleinere .odex-Dateien generiert als bei der vorzeitigen Kompilierung (da erstere nur leistungskritischen Code optimiert).

Einzelheiten zu den Tuning-Optionen, die OEMs zur Verfügung stehen, finden Sie unter ART konfigurieren .

Gibt es nicht zwei Kopien der .odex-Dateien auf /data?

Es ist etwas komplizierter ... Nachdem das neue Systemabbild geschrieben wurde, wird die neue Version von dex2oat mit den neuen .dex-Dateien ausgeführt, um die neuen .odex-Dateien zu generieren. Dies geschieht, während das alte System noch läuft, sodass sich die alten und neuen .odex-Dateien gleichzeitig auf /data befinden.

Der Code in OtaDexoptService ( frameworks/base/+/main/services/core/java/com/android/server/pm/OtaDexoptService.java ) ruft getAvailableSpace auf, bevor jedes Paket optimiert wird, um eine Überfüllung /data zu vermeiden. Beachten Sie, dass der verfügbare Wert hier immer noch konservativ ist: Es handelt sich um die verbleibende Speicherplatzmenge , bevor der übliche Systemschwellenwert für niedrigen Speicherplatz erreicht wird (gemessen als Prozentsatz und Byteanzahl). Wenn also /data voll ist, gibt es nicht zwei Kopien jeder .odex-Datei. Derselbe Code verfügt auch über einen BULK_DELETE_THRESHOLD: Wenn das Gerät den verfügbaren Speicherplatz so nahe kommt (wie gerade beschrieben), werden die .odex-Dateien entfernt, die zu Apps gehören, die nicht verwendet werden. Das ist ein weiterer Fall ohne zwei Kopien jeder .odex-Datei.

Im schlimmsten Fall, wenn /data vollständig voll ist, wartet das Update, bis das Gerät im neuen System neu gestartet wurde und die .odex-Dateien des alten Systems nicht mehr benötigt. Der PackageManager erledigt dies: ( frameworks/base/+/main/services/core/java/com/android/server/pm/PackageManagerService.java#7215 ). Nachdem das neue System erfolgreich gestartet wurde, kann installd ( frameworks/native/+/main/cmds/installd/dexopt.cpp#2422 ) die vom alten System verwendeten .odex-Dateien entfernen und das Gerät wieder in den stabilen Zustand versetzen wo es nur eine Kopie gibt.

Es ist zwar möglich, dass /data zwei Kopien aller Odex-Dateien enthält, aber (a) ist dies nur vorübergehend und (b) tritt nur dann auf, wenn Sie ohnehin ausreichend freien Speicherplatz auf /data hatten. Außer bei einem Update gibt es nur eine Kopie. Und als Teil der allgemeinen Robustheitsfunktionen von ART wird /data sowieso nie mit .odex-Dateien gefüllt (da dies auch auf einem Nicht-A/B-System ein Problem wäre).

Erhöht all das Schreiben/Kopieren nicht den Flash-Verschleiß?

Nur ein kleiner Teil des Flashs wird neu geschrieben: Ein vollständiges Pixel-Systemupdate schreibt etwa 2,3 GB. (Apps werden ebenfalls neu kompiliert, aber das gilt auch für Nicht-A/B.) Traditionell haben blockbasierte vollständige OTAs eine ähnliche Datenmenge geschrieben, daher sollten die Flash-Verschleißraten ähnlich sein.

Verlängert das Flashen von zwei Systempartitionen die werkseitige Flash-Zeit?

Nein. Pixel hat die Größe des Systemabbilds nicht erhöht (es hat lediglich den Speicherplatz auf zwei Partitionen aufgeteilt).

Wird der Neustart nach dem Zurücksetzen auf die Werkseinstellungen nicht langsamer, wenn .odex-Dateien auf B verbleiben?

Ja. Wenn Sie tatsächlich ein Gerät verwendet, einen OTA durchgeführt und einen Werksdaten-Reset durchgeführt haben, ist der erste Neustart langsamer als sonst (1:40 Minuten gegenüber 40 Sekunden bei einem Pixel XL), da die .odex-Dateien verloren gegangen sind B nach dem ersten OTA und kann daher nicht nach /data kopiert werden. Das ist der Kompromiss.

Das Zurücksetzen auf die Werkseinstellungen sollte im Vergleich zum regulären Booten ein seltener Vorgang sein, sodass die benötigte Zeit weniger wichtig ist. (Dies betrifft nicht Benutzer oder Prüfer, die ihr Gerät ab Werk erhalten, da in diesem Fall die B-Partition verfügbar ist.) Die Verwendung des JIT-Compilers bedeutet, dass wir nicht alles neu kompilieren müssen, es ist also nicht so schlimm wie bei Ihnen könnte denken. Es ist auch möglich, Apps mithilfe von coreApp="true" im Manifest so zu markieren, dass eine vorzeitige Kompilierung erforderlich ist: ( frameworks/base/+/main/packages/SystemUI/AndroidManifest.xml#23 ). Dies wird derzeit von system_server verwendet, da JIT aus Sicherheitsgründen nicht zulässig ist.

Wird der Neustart nach einem OTA nicht langsamer, wenn .odex-Dateien auf /data statt auf /system gespeichert werden?

Nein. Wie oben erläutert, wird das neue dex2oat ausgeführt, während das alte System-Image noch läuft, um die Dateien zu generieren, die vom neuen System benötigt werden. Das Update gilt erst dann als verfügbar, wenn diese Arbeiten abgeschlossen sind.

Können (sollten) wir ein 32GiB A/B-Gerät versenden? 16 GB? 8 GB?

32 GB funktionieren gut, wie sich auf Pixel bewährt hat, und 320 MB von 16 GB bedeuten eine Reduzierung um 2 %. Ebenso sind 320 MiB von 8 GiB eine Reduzierung um 4 %. Offensichtlich wäre A/B auf Geräten mit 4 GB nicht die empfohlene Wahl, da der Overhead von 320 MB fast 10 % des insgesamt verfügbaren Speicherplatzes ausmacht.

Erfordert AVB2.0 A/B-OTAs?

Nein. Android Verified Boot erforderte immer blockbasierte Updates, aber nicht unbedingt A/B-Updates.

Benötigen A/B-OTAs AVB2.0?

NEIN.

Unterbrechen A/B-OTAs den Rollback-Schutz von AVB2.0?

Nein. Hier gibt es einige Verwirrung, denn wenn ein A/B-System nicht in das neue Systemabbild booten kann, wird es (nach einer von Ihrem Bootloader festgelegten Anzahl von Wiederholungen) automatisch zum „vorherigen“ Systemabbild zurückkehren. Der entscheidende Punkt hierbei ist jedoch, dass „vorher“ im A/B-Sinn tatsächlich immer noch das „aktuelle“ Systemabbild ist. Sobald das Gerät erfolgreich ein neues Image startet, greift der Rollback-Schutz und stellt sicher, dass Sie nicht mehr zurückkehren können. Aber bis Sie das neue Image tatsächlich erfolgreich gebootet haben, betrachtet der Rollback-Schutz es nicht als das aktuelle System-Image.

Wenn Sie ein Update bei laufendem System installieren, ist das nicht langsam?

Bei Nicht-A/B-Updates besteht das Ziel darin, das Update so schnell wie möglich zu installieren, da der Benutzer wartet und sein Gerät nicht verwenden kann, während das Update angewendet wird. Bei A/B-Updates ist das Gegenteil der Fall; Da der Benutzer sein Gerät noch verwendet, ist das Ziel eine möglichst geringe Beeinträchtigung, weshalb das Update bewusst langsam erfolgt. Über die Logik im Java-System-Update-Client (bei Google handelt es sich um GmsCore, das von GMS bereitgestellte Kernpaket) versucht Android außerdem, einen Zeitpunkt auszuwählen, zu dem die Benutzer ihre Geräte überhaupt nicht verwenden. Die Plattform unterstützt das Anhalten/Fortsetzen des Updates, und der Client kann damit das Update anhalten, wenn der Benutzer beginnt, das Gerät zu verwenden, und es fortsetzen, wenn das Gerät wieder inaktiv ist.

Während der Teilnahme an einem OTA gibt es zwei Phasen, die in der Benutzeroberfläche deutlich als Schritt 1 von 2 und Schritt 2 von 2 unter dem Fortschrittsbalken angezeigt werden. Schritt 1 entspricht dem Schreiben der Datenblöcke, während Schritt 2 der Vorkompilierung der .dex-Dateien dient. Diese beiden Phasen unterscheiden sich hinsichtlich der Auswirkungen auf die Leistung erheblich. Die erste Phase ist einfache E/A. Dies erfordert wenig Ressourcen (RAM, CPU, I/O), da nur langsam Blöcke kopiert werden.

In der zweiten Phase wird dex2oat ausgeführt, um das neue Systemabbild vorzukompilieren. Dies hat offensichtlich weniger klare Anforderungen an die Anforderungen, da tatsächliche Apps kompiliert werden. Und das Kompilieren einer großen und komplexen App erfordert offensichtlich viel mehr Arbeit als das Kompilieren einer kleinen und einfachen App. wohingegen es in Phase 1 keine Plattenblöcke gibt, die größer oder komplexer sind als andere.

Der Vorgang ähnelt dem Vorgang, bei dem Google Play im Hintergrund ein App-Update installiert, bevor die Aktualisierungsbenachrichtigung für die fünf Apps angezeigt wird, wie es schon seit Jahren der Fall ist.

Was ist, wenn ein Benutzer tatsächlich auf das Update wartet?

Die aktuelle Implementierung in GmsCore unterscheidet nicht zwischen Hintergrundaktualisierungen und vom Benutzer initiierten Aktualisierungen, wird dies jedoch möglicherweise in Zukunft tun. Für den Fall, dass der Benutzer ausdrücklich die Installation des Updates angefordert hat oder den Update-Fortschrittsbildschirm beobachtet, priorisieren wir die Update-Arbeit in der Annahme, dass er aktiv auf den Abschluss wartet.

Was passiert, wenn die Anwendung eines Updates fehlschlägt?

Bei Nicht-A/B-Updates blieb dem Benutzer normalerweise ein unbrauchbares Gerät zurück, wenn ein Update nicht angewendet werden konnte. Die einzige Ausnahme bestand darin, dass der Fehler auftrat, bevor eine Anwendung überhaupt gestartet war (z. B. weil das Paket nicht überprüft werden konnte). Bei A/B-Updates hat das Versäumnis, ein Update anzuwenden, keine Auswirkungen auf das aktuell laufende System. Das Update kann später einfach erneut versucht werden.

Welche Systems on a Chip (SoCs) unterstützen A/B?

Mit Stand vom 15.03.2017 liegen uns folgende Informationen vor:

Einzelheiten zu den Zeitplänen erfahren Sie bei Ihren SoC-Ansprechpartnern. Für SoCs, die oben nicht aufgeführt sind, wenden Sie sich direkt an Ihren SoC.