Virtuelle A/B-Übersicht

Android hat zwei Update-Mechanismen: A/B (nahtlose) Updates und Nicht-A/B-Updates. Um die Codekomplexität zu reduzieren und den Update-Prozess zu verbessern, werden in Android 11 die beiden Mechanismen durch virtuelles A/B vereinheitlicht, um nahtlose Updates auf allen Geräten mit minimierten Speicherkosten bereitzustellen. Android 12 bietet die Option der virtuellen A/B-Komprimierung, um mit Snapshots erstellte Partitionen zu komprimieren. Sowohl für Android 11 als auch für Android 12 gilt Folgendes:

  • Virtuelle A / B - Updates sind nahtlos wie A / B - Updates. Virtuelle A/B-Updates minimieren die Zeit, die ein Gerät offline und unbrauchbar ist.
  • Virtuelle A / B - Updates kann rückgängig gemacht werden. Wenn das neue Betriebssystem nicht booten kann, rollen die Geräte automatisch auf die vorherige Version zurück.
  • Virtuelle A / B - Updates verwenden , um ein Minimum an zusätzlichem Platz , indem nur die Partitionen duplizieren , die vom Bootloader verwendet werden. Andere aktualisierbare Partitionen Snapshot von ihr erstellt .

Hintergrund und Terminologie

Dieser Abschnitt definiert die Terminologie und beschreibt die Technologie, die virtuelles A/B unterstützt.

Gerätezuordnung

Device-Mapper ist eine virtuelle Linux-Blockschicht, die häufig in Android verwendet wird. Mit dynamischen Partitionen , Trennwände wie /system zu einem Stapel von geschichteten Vorrichtungen:

  • An der Unterseite des Stapels ist die physikalische Super Partition (beispielsweise /dev/block/by-name/super ).
  • In der Mitte ist eine dm-linear Vorrichtung, welche Blöcke in der Super - Partition Form die gegebene Partition angeben. Dies erscheint als /dev/block/mapper/system_[a|b] an einem A / B - Gerät oder /dev/block/mapper/system auf einem Nicht-A / B - Gerät.
  • An der Spitze befindet sich ein dm-verity Gerät für geeichte Partitionen erstellt. Dieses Gerät prüft , ob die Blöcke auf dem dm-linear Gerät korrekt signiert. Es scheint , als /dev/block/mapper/system-verity und ist die Quelle des /system Einhängepunkt.

Abbildung 1 zeigt , was der Stapel unter dem /system wie Punkt aussieht montieren.

Partition stacking underneath system

Abbildung 1. Stapel unter dem / System Einhängepunkt

dm-Schnappschuss

Virtuelle A / B beruht auf dm-snapshot , einem geräte Mapper - Modul für Snapshot des Zustands einer Speichervorrichtung. Bei der Verwendung von dm-snapshot gibt es vier Geräte im Spiel:

  • Das Basisgerät ist das Gerät , das Snapshot von ihr erstellt wird . Auf dieser Seite ist das Basisgerät immer eine dynamische Partition, wie z. B. System oder Vendor.
  • Das Copy-on-Write (COW) Gerät, für Änderungen an das Basisgerät anmelden. Es kann eine beliebige Größe haben, muss jedoch groß genug sein, um alle Änderungen am Basisgerät aufzunehmen.
  • Die Snapshot - Gerät erstellt , um die Verwendung von snapshot - Ziels. Schreibvorgänge auf das Snapshot-Gerät werden auf das COW-Gerät geschrieben. Lesevorgänge vom Snapshot-Gerät lesen entweder vom Basisgerät oder vom COW-Gerät, je nachdem, ob die Daten, auf die zugegriffen wird, durch den Snapshot geändert wurden.
  • Die Ursprungsvorrichtung ist geschaffen , um die Verwendung von snapshot-origin Ziel. Liest auf das Ursprungsgerät, liest direkt vom Basisgerät. Schreibvorgänge auf das Ursprungsgerät schreiben direkt auf das Basisgerät, aber die Originaldaten werden durch Schreiben auf das COW-Gerät gesichert.

Device mapping for dm-snapshot

Abbildung 2. Gerätezuordnung für dm-snapshot

Komprimierte Schnappschüsse

In Android 12, da Platzbedarf auf der /data hoch sein kann, können Sie komprimieren Snapshots in Ihrem Build ermöglichen den höheren Platzbedarf der Adresse /data - Partition.

Virtuelle A/B-komprimierte Snapshots basieren auf zwei neuen Komponenten, die in Android 12 verfügbar sind:

  • dm-user , ein Kernel - Modul ähnlich wie FUSE , die User - Space - Blockgeräte implementieren kann.
  • snapuserd , um ein Userspace - Daemon ein neues Snapshot - Format umzusetzen.

Diese Komponenten ermöglichen die Komprimierung. Die anderen erforderlichen Änderungen vorgenommen , die komprimierten Snapshots zu implementieren Fähigkeiten in den folgenden Abschnitten angegeben: KUH Format für komprimierte Snapshots , dm-Benutzer und Snapuserd .

COW-Format für komprimierte Snapshots

In Android 12 verwenden komprimierte Snapshots ein neues COW-Format. Ähnlich dem integrierten Format des Kernels, das für unkomprimierte Snapshots verwendet wird, enthält das COW-Format für die komprimierten Snapshots abwechselnde Abschnitte von Metadaten und Daten. Das ursprüngliche Format der Metadaten nur für „Ersetzen“ Operationen erlaubt: X - Block in dem Basisbild Ersetzen mit dem Inhalt von Block Y in der Momentaufnahme. Das COW-Format für komprimierte Snapshots ist ausdrucksstärker und unterstützt drei Operationen:

  • Kopieren - Block X in der Basisvorrichtung sollte mit Block Y in der Basisvorrichtung ersetzt werden.
  • Ersetzen - Block X in der Basisvorrichtung sollte mit dem Inhalt von Block Y in der Momentaufnahme ersetzt werden. Jeder dieser Blöcke ist gz-komprimiert.
  • Null - Block X in dem Basisgerät sollte mit allen Nullen ersetzt werden.

Vollständige OTA - Updates besteht aus nur ersetzen und Null - Operationen. Inkrementelle OTA - Updates können zusätzlich Kopiervorgänge haben.

dm-Benutzer in Android 12

Das dm-User - Kernel - Modul ermöglicht userspace - device-mapper Block - Geräte zu implementieren. A dm-Benutzer Tabelleneintrag erstellt ein sonstiges Gerät unter /dev/dm-user/<control-name> . Ein userspace - userspace - Prozess kann das Gerät abfragen , Lese- und Schreibanforderungen aus dem Kernel zu empfangen. Jede Anforderung hat einen zugeordneten Puffer für den Userspace, um ihn entweder aufzufüllen (für einen Lesevorgang) oder zu verbreiten (für einen Schreibvorgang).

Das dm-user - Kernelmodul liefert eine neue Benutzer sichtbare Schnittstelle zu dem Kernel, der nicht Teil der vorgeschalteten kernel.org Code - Basis ist. Bis es ist, behält sich Google das Recht vor, das zu ändern , dm-user - Interface in Android.

Snapuserd

Die snapuserd User - Space - Komponente zu dm-user implementiert virtuelle A / B - Komprimierung.

In der unkomprimierten Version von Virtual A/B (entweder in Android 11 und niedriger oder in Android 12 ohne komprimierte Snapshot-Option) ist das COW-Gerät eine Rohdatei. Wenn die Komprimierung aktiviert ist, die Kuh Funktionen stattdessen als eine dm-user die auf eine Instanz des verbunden ist snapuserd Daemon.

Der Kernel verwendet nicht das neue COW-Format. So ist die snapuserd Komponente übersetzt Anforderungen zwischen dem Android - KUH - Format und dem Kernel integrierten Format:

Snapuserd component translating requests between Android COW format and kernel built-in format

Abbildung 3. Flussdiagramm snapuserd als Übersetzer zwischen Android und Kernel - KUH - Formaten

Diese Übersetzung und Dekomprimierung erfolgt niemals auf der Festplatte. Die snapuserd Komponente fängt die Kuh liest und schreibt , die im Kernel auftreten, und setzt sie mit dem Android - KUH - Format.

Virtuelle A/B-Kompressionsprozesse

Diese Abschnitte enthalten Details zu den Prozessen, die bei der virtuellen A/B-Komprimierung verwendet werden: Lesen von Metadaten, Zusammenführen und Ausführen von Init-Übergängen.

Metadaten lesen

Metadaten werden von einem konstruierten snapuserd - Dämon. Die Metadaten sind in erster Linie eine Abbildung von 2 IDs mit jeweils 8 Bytes, die die zusammenzuführenden Sektoren darstellen. In dm-snapshot ist es als genannt disk_exception .

struct disk_exception {
    uint64_t old_chunk;
    uint64_t new_chunk;
};

Eine Datenträgerausnahme wird verwendet, wenn ein alter Datenblock durch einen neuen ersetzt wird.

Ein Snapuserd Daemon liest die interne COW - Datei durch die COW - Bibliothek konstruiert und die Metadaten für jede der COW - Operationen in der COW - Datei.

Metadaten liest aus dem initiierten dm-snapshot im Kernel , wenn das dm- snapshot - Gerät erstellt wird.

Die folgende Abbildung zeigt ein Sequenzdiagramm für den IO-Pfad für die Metadatenerstellung.

Sequence diagram, IO path for metadata construction

Abbildung 4. Ablauffolge für den IO - Pfad in Metadaten Konstruktion

Zusammenführen

Nachdem der Startvorgang abgeschlossen ist , wird die Aktualisierungsmaschine markiert den Schlitz als Boot erfolgreich und initiiert die merge durch das Schalen dm-snapshot Ziel auf das dm-snapshot-merge Ziel.

dm-snapshot geht durch die Metadaten und initiiert eine merge IO für jede Platte Ausnahme. Eine allgemeine Übersicht über den Merge-E/A-Pfad wird unten gezeigt.

Merge IO path

Abbildung 5. Merge IO Pfad Überblick

Wenn das Gerät während des Zusammenführungsprozesses neu gestartet wird, wird die Zusammenführung beim nächsten Neustart fortgesetzt und die Zusammenführung ist abgeschlossen.

Init-Übergänge

Wenn mit Druck Snapshots starten, muß die erste Stufe der init startet snapuserd Partitionen zu mounten. Dies stellt ein Problem: Wenn sepolicy geladen und durchgesetzt werden , snapuserd im falschen Kontext gestellt wird, und seine Leseanforderungen fehlschlagen, mit SELinux Dementis.

Um dem abzuhelfen, snapuserd Übergänge im Gleichschritt mit init , wie folgt:

  1. Erste Phase der init startet snapuserd von der RAM - Disk und speichert eine geöffnete Datei-Beschreiber , um es in einer Umgebungsvariablen.
  2. Erststufen- init das Wurzeldateisystem in die Systempartition schaltet, führt dann die Systemkopie von init .
  3. Die Systemkopie von init liest die kombinierte sepolicy in einen String.
  4. Init Invokes mlock() auf alle ext4-backed - Seiten. Es deaktiviert dann alle Geräte-Mapper - Tabellen für Snapshot - Geräte und stoppt snapuserd . Danach ist es verboten, von Partitionen zu lesen, da dies zu einem Deadlock führt.
  5. Unter Verwendung des offenen Descriptor an die RAM - Disk Kopie snapuserd , init relauncht den Daemon mit dem richtigen SELinux Kontext. Device-Mapper-Tabellen für Snapshot-Geräte werden wieder aktiviert.
  6. Init Invokes munlockall() - es ist sicher IO wieder auszuführen.

Speicherplatznutzung

Die folgende Tabelle bietet einen Vergleich der Speicherplatznutzung für verschiedene OTA-Mechanismen, die die Betriebssystem- und OTA-Größen von Pixel verwenden.

Größeneinfluss Nicht-A/B A/B Virtuelles A/B Virtuelles A/B (komprimiert)
Originales Fabrikbild 4,5 GB Super (3.8G image + 700M reserviert) 1 9GB Super (3.8G + 700M reserviert, für zwei Slots) 4,5 GB Super (3,8 GB Bild + 700 MB reserviert) 4,5 GB Super (3,8 GB Bild + 700 MB reserviert)
Andere statische Partitionen /Zwischenspeicher Keiner Keiner Keiner
Zusätzlicher Speicher Während OTA (Raum zurück nach OTA Anwendung) 1,4 GB auf /Daten 0 3.8GB 2 auf / data 2,1 GB auf 2 / data
Gesamtspeicherbedarf für die Anwendung von OTA 5.9GB 3 (Super und Daten) 9GB (super) 8.3GB 3 (Super und Daten) 6.6GB 3 (Super und Daten)

1 Zeigt angenommener Layout basiert auf Pixel - Mapping.

2 Setzt neues System Bild die gleiche Größe wie Original.

3 Platzbedarf ist vorübergehend bis zum Neustart.

Um virtuelle A / B zu implementieren, oder um komprimierte Snapshot - Funktionen zu verwenden, finden Implementierung virtueller A / B