Übersicht über virtuelles A/B

Android bietet zwei Updatemechanismen: A/B-Updates (nahtlose) und Nicht-A/B-Updates. Um die Codekomplexität zu verringern und den Aktualisierungsprozess zu verbessern, gibt es in Android 11 zwei Mechanismen durch virtuelles A/B vereinheitlicht, um nahtlose Updates für alle Geräte mit minimalen Speicherkosten. Android 12 bietet die Option der virtuellen A/B-Komprimierung, um partitionierte Partitionen mit Schnappschuss zu komprimieren. In Android 11 und Android 12 gilt Folgendes: Anwenden:

• Virtuelle A/B-Aktualisierungen sind nahtlos wie A/B-Aktualisierungen. Virtuelle A/B-Updates die Zeit zu minimieren, in der ein Gerät offline und unbrauchbar ist.
• Virtuelle A/B-Updates können zurückgezogen werden. Wenn das neue Betriebssystem nicht gestartet werden kann, Geräte werden automatisch auf die vorherige Version zurückgesetzt.
• Virtuelle A/B-Aktualisierungen verbrauchen mindestens wenig Speicherplatz, da nur die die vom Bootloader verwendet werden. Andere aktualisierbare Partitionen sind Snapshotted erstellt.

Hintergrund und Terminologie

In diesem Abschnitt wird die Terminologie definiert und die Technologie beschrieben, virtuelles A/B.

Device Mapper

Device Mapper ist eine virtuelle Linux-Blockschicht, die häufig in Android verwendet wird. Mit dynamische Partitionen, Partitionen wie /system ist ein Stapel von Geräten mit mehreren Ebenen:

• Ganz unten im Stack befindet sich die physische Superpartition (z. B. /dev/block/by-name/super.
• In der Mitte befindet sich ein dm-linear-Gerät, das angibt, welche Blöcke im Partition der gegebenen Partition ein. Dies erscheint als /dev/block/mapper/system_[a|b] auf einem A/B-Gerät oder /dev/block/mapper/system auf einem Nicht-A/B-Gerät.
• Oben befindet sich ein dm-verity-Gerät, das für bestätigte Partitionen erstellt wurde. Auf diesem Gerät wird bestätigt, dass Blockierungen auf dem dm-linear-Gerät signiert sind korrekt sind. Sie wird als /dev/block/mapper/system-verity angezeigt und ist die Quelle des Bereitstellungspunkts /system.

Abbildung 1 zeigt den Stapel unter dem Bereitstellungspunkt /system.

Abbildung 1: Unter dem Bereitstellungspunkt /system stapeln

dm-Snapshot

Virtual A/B basiert auf dm-snapshot, einem Device Mapper-Modul zur Erstellung von Snapshots Status eines Speichergeräts. Bei der Verwendung von dm-snapshot befinden sich vier Geräte in Abspielen:

• Das base-Gerät ist das Gerät mit einem Snapshot. Auf dieser Seite haben wir Gerät ist immer eine dynamische Partition, z. B. das System oder der Anbieter.
• Das Copy-on-Write-Gerät (COW) zum Protokollieren von Änderungen auf dem Basisgerät. Es kann beliebig groß sein, muss aber groß genug sein, um alle Änderungen Basisgerät.
• Das Snapshot-Gerät wird mit dem Ziel snapshot erstellt. Schreibt in den Snapshot-Gerät werden auf das COW-Gerät geschrieben. Lesevorgänge aus dem Snapshot vom Basisgerät oder vom COW-Gerät gelesen, je nachdem, ob die Daten, auf die zugegriffen wird, durch den Snapshot geändert wurden.
• Das Ursprungsgerät wird mit dem Ziel snapshot-origin erstellt. Lesevorgänge in hat das Ursprungsgerät direkt vom Basisgerät gelesen. Schreibt an den Ursprung Gerät schreibt direkt auf das Basisgerät, aber die Originaldaten werden gesichert durch Schreiben auf das COW-Gerät.

Abbildung 2: Gerätezuordnung für dm-Snapshot

Komprimierte Snapshots

In Android 12 und höher, da der Speicherplatzbedarf kann die Partition /data hoch sein, können Sie komprimierte Snapshots in der um den höheren Speicherplatzbedarf der Partition /data zu erfüllen.

Virtuelle A/B-komprimierte Snapshots basieren auf den folgenden Komponenten die in Android 12 und höher verfügbar sind:

• dm-user, ein Kernelmodul ähnlich wie FUSE, das Userspace ermöglicht zur Implementierung von Blockgeräten.
• snapuserd, ein Userspace-Daemon zum Implementieren eines neuen Snapshots Format.

Diese Komponenten ermöglichen die Komprimierung. Die weiteren notwendigen Änderungen Die Möglichkeiten für komprimierte Snapshots werden in den nächsten Abschnitten erläutert: COW-Format für komprimierte Snapshots dm-user und Snapuserd.

COW-Format für komprimierte Snapshots

Unter Android 12 und höher verwenden komprimierte Snapshots einen COW-Format. Ähnlich wie das integrierte Format des Kernels, das für unkomprimierte Snapshots hat das COW-Format für die komprimierten Snapshots abwechselnde Abschnitte. von Metadaten und Daten. Für die Metadaten des ursprünglichen Formats ist nur Ersetzen zulässig Vorgänge: Ersetzen Sie Block X im Basis-Image durch den Inhalt des Blocks Y. im Snapshot. Das COW-Format für komprimierte Snapshots ist aussagekräftiger unterstützt die folgenden Vorgänge:

• Text: Block X im Basisgerät sollte in folgendem Format durch Block Y ersetzt werden: des Basisgeräts.
• Ersetzen: Block X im Basisgerät sollte durch den Inhalt ersetzt werden des Blocks Y im Snapshot. Jeder dieser Blöcke wird im GZ-Format komprimiert.
• Null: Block X im Basisgerät sollte durch alle Nullen ersetzt werden.
• XOR: Das COW-Gerät speichert komprimierte XOR-Byte zwischen Block X und Block Y. Diese Funktion ist ab Android 13 verfügbar.

Vollständige OTA-Updates umfassen nur Ersetzen und null Vorgänge. Steigerung OTA-Updates können zusätzlich Kopiervorgänge beinhalten.

dm-user unter Android 12

Mit dem dm-user-Kernelmodul kann userspace den Device Mapper-Block implementieren Geräte. Durch einen dm-user-Tabelleneintrag wird ein sonstiges Gerät erstellt unter /dev/dm-user/<control-name> Ein userspace-Prozess kann das Gerät abfragen Lese- und Schreibanfragen vom Kernel empfangen. Jeder Anfrage ist ein Puffer für Userspace, der entweder ausgefüllt (für einen Lesevorgang) oder (für einen Schreibvorgang) propagiert wird.

Das Kernelmodul dm-user bietet eine neue für den Nutzer sichtbare Schnittstelle für den Kernel die nicht Teil der vorgelagerten Kernel.org-Codebasis ist. Bis dahin hat Google behält sich das Recht vor, die dm-user-Oberfläche in Android zu ändern.

Snapuserd

Die Userspace-Komponente für snapuserd für dm-user implementiert virtuelles A/B Komprimierung.

In der unkomprimierten Version von Virtual A/B (unter Android 11 und niedriger oder in Android 12 ohne die Option „komprimierte Snapshot“), Das COW-Gerät ist eine RAW-Datei. Wenn die Komprimierung aktiviert ist, stattdessen als dm-user-Gerät, das mit einer Instanz der snapuserd-Daemon.

Der Kernel verwendet nicht das neue COW-Format. Die Komponente „snapuserd“ übersetzt Anfragen zwischen dem Android COW-Format und dem Format:

Abbildung 3: Flussdiagramm von „snapuserd“ als Übersetzer zwischen Android und Kernel COW-Formate

Diese Verschiebung und Dekomprimierung findet auf der Festplatte nie statt. Das snapuserd fängt die COW-Lese- und -Schreibvorgänge im Kernel ab und und implementiert sie mithilfe des Android COW-Formats.

XOR-Komprimierung

Bei Geräten mit Android 13 und höher Die standardmäßig aktivierte XOR-Komprimierungsfunktion ermöglicht Snapshots, um komprimierte XOR-Byte zwischen alten und neuen Blöcken zu speichern. Wann? bei einem Virtual A/B-Update nur wenige Bytes in einem Block geändert werden, Komprimierungsspeicherschema verwendet weniger Speicherplatz als das Standardspeicherschema denn in Snapshots werden keine vollen 4.000 Byte gespeichert. Diese Reduzierung der Snapshot-Größe möglich, weil XOR-Daten viele Nullen enthalten und einfacher zu komprimieren sind als Rohdaten zu blockieren. Auf Pixel-Geräten reduziert die XOR-Komprimierung die Snapshot-Größe um 25 %, 40%.

Für Geräte mit einem Upgrade auf Android 13 und höher: XOR muss die Komprimierung aktiviert sein. Weitere Informationen finden Sie unter XOR Komprimierung.

Virtuelle A/B-Komprimierungsprozesse

Dieser Abschnitt enthält Details zur virtuellen A/B-Komprimierung, die in Android 13 und Android 12.

Metadaten lesen (Android 12)

Metadaten werden von einem snapuserd-Daemon erstellt. Die Metadaten sind primär ein Zuordnung von zwei IDs von jeweils 8 Byte, die die zu verbindenden Sektoren darstellen. In dm-snapshot heißt es disk_exception.

struct disk_exception {
    uint64_t old_chunk;
    uint64_t new_chunk;
};

Eine Laufwerksausnahme wird verwendet, wenn ein alter Datenblock durch einen neuen ersetzt wird.

Ein snapuserd-Daemon liest die interne COW-Datei über die COW-Bibliothek und erstellt die Metadaten für jeden der in der COW-Datei vorhandenen COW-Vorgänge.

Metadatenlesevorgänge werden vom dm-snapshot im Kernel initiiert, wenn das dm- snapshot-Gerät erstellt wird.

Die folgende Abbildung zeigt ein Sequenzdiagramm für den E/A-Pfad für Metadaten Bauarbeiten.

Abbildung 4: Sequenzfluss für den E/A-Pfad bei der Metadatenerstellung

Zusammenführen (Android 12)

Sobald der Bootvorgang abgeschlossen ist, markiert die Update-Engine den Slot als Bootmodus. erfolgreich ist und initiiert die Zusammenführung, indem das dm-snapshot-Ziel auf den dm-snapshot-merge Ziel.

dm-snapshot geht die Metadaten durch und initiiert für jedes Laufwerk eine Zusammenführungs-E/A Ausnahme. Im Folgenden finden Sie eine allgemeine Übersicht über den Zusammenführungs-E/A-Pfad.

Abbildung 5: AA-Pfad zusammenführen – Übersicht

Wird das Gerät während der Zusammenführung neu gestartet, wird die Zusammenführung auf der und die Zusammenführung ist abgeschlossen.

Device Mapper-Ebenen erstellen

Bei Geräten mit Android 13 und höher Es werden Snapshot- und Snapshot-Zusammenführungsprozesse bei der virtuellen A/B-Komprimierung ausgeführt. durch die Userspace-Komponente snapuserd. Für Geräte mit Upgrade auf Android 13 oder höher muss diese Funktion aktiviert sein. Für Weitere Informationen zum Userspace zu verbinden.

Im Folgenden wird der virtuelle A/B-Komprimierungsprozess beschrieben:

1. Das Framework stellt die Partition /system eines dm-verity-Geräts bereit. der über einem dm-user-Gerät gestapelt ist. Das bedeutet, dass jede E/A vom Stammdateisystem an dm-user weitergeleitet.
2. dm-user leitet die E/A an den Daemon snapuserd weiter, der das der E/A-Anfrage.
3. Wenn der Zusammenführungsvorgang abgeschlossen ist, minimiert das Framework dm-verity auf am oberen Rand von dm-linear (system_base) und entfernt dm-user.

Abbildung 6: Virtuelles A/B-Komprimierungsverfahren

Die Snapshot-Zusammenführung kann unterbrochen werden. Wird das Gerät während eines wird der Zusammenführungsprozess nach dem Neustart fortgesetzt.

Init-Übergänge

Beim Booten mit komprimierten Snapshots muss die Initialisierung der ersten Phase gestartet werden. snapuserd zum Bereitstellen von Partitionen. Dies stellt ein Problem dar: Wenn sepolicy geladen wird, und erzwungen wird, snapuserd wird in den falschen Kontext gestellt und seine Leseanfragen mit Selinux-Ablehnungen fehl.

Um dieses Problem zu beheben, wird snapuserd beim Verriegelungsschritt so auf init umgestellt:

1. Die erste Phase init startet snapuserd von der Ramdisk und speichert eine offene Datei-Deskriptor in einer Umgebungsvariablen.
2. In der ersten Phase init wechselt das Root-Dateisystem auf die Systempartition. führt dann die Systemkopie von init aus.
3. Die Systemkopie von init liest die kombinierte Richtlinie in einen String ein.
4. Init ruft mlock() auf allen ext4-unterstützten Seiten auf. Anschließend werden alle device-mapper-Tabellen für Snapshot-Geräte und beendet snapuserd. Danach aus Partitionen lesen, da dies zu einem Deadlock führt.
5. Open-Deskriptor für die Ramdisk-Kopie von snapuserd, init verwenden startet den Daemon mit dem richtigen Selinux-Kontext neu. Device Mapper-Tabellen für Snapshot-Geräte aktiviert werden.
6. Init ruft munlockall() auf. Die E/A kann problemlos noch einmal ausgeführt werden.

Speicherplatznutzung

Die folgende Tabelle bietet einen Vergleich der Speichernutzung für verschiedene OTA-Dateien mithilfe der Betriebssystem- und OTA-Größen von Pixel.

¹ Gibt ein angenommenes Layout basierend auf der Pixel-Zuordnung an.

² Es wird davon ausgegangen, dass das neue System-Image dieselbe Größe wie das Original hat.

³ Der Speicherplatz ist bis zum Neustart vorübergehend erforderlich.

Informationen zur Implementierung von Virtual A/B oder zur Verwendung von komprimierten Snapshot-Funktionen finden Sie unter Virtuelles A/B implementieren