Virtuelles A/B implementieren

Um ein virtuelles A/B auf einem neuen Gerät zu implementieren oder ein bereits veröffentlichtes Gerät nachzurüsten, müssen Änderungen am gerätespezifischen Code vornehmen.

Build-Flags

Geräte mit virtuellem A/B müssen als A/B konfiguriert werden Gerät und muss mit dem dynamisch Partitionen

Geräte, die mit virtuellem A/B gestartet werden, müssen festlegen, dass das virtuelle A/B übernommen wird. Konfiguration der Gerätebasis:

$(call inherit-product, \
    $(SRC_TARGET_DIR)/product/virtual_ab_ota.mk)

Geräte, die mit virtuellem A/B auf den Markt kommen, benötigen nur halb so viel Boardgröße BOARD_SUPER_PARTITION_SIZE, weil sich B-Slots nicht mehr im Super Chat befinden. Das heißt: BOARD_SUPER_PARTITION_SIZE muss größer oder gleich sein sum(Größe der Aktualisierungsgruppen) + Aufwand, die wiederum größer sein müssen ist als oder gleich sum(size of partitions) +over.

Bei Android 13 und höher wird die komprimierte Ansicht aktiviert. für Snapshots mit virtuellem A/B wird die folgende Basiskonfiguration übernommen:

$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)
$(call inherit-product, \
    $(SRC_TARGET_DIR)/product/virtual_ab_ota/android_t_baseline.mk)

Dies ermöglicht Userspace-Snapshots mit virtuellem A/B bei Verwendung einer No-Op Komprimierungsmethode. Anschließend können Sie die Komprimierungsmethode auf eine der unterstützten Methoden gz, zstd und lz4.

PRODUCT_VIRTUAL_AB_COMPRESSION_METHOD := lz4

Um bei Android 12 komprimierte Snapshots mit Virtuelles A/B, übernehmen Sie die folgende Basiskonfiguration:

$(call inherit-product, $(SRC_TARGET_DIR)/product/generic_ramdisk.mk)
$(call inherit-product, \
    $(SRC_TARGET_DIR)/product/virtual_ab_ota/compression.mk)

XOR-Komprimierung

Bei Geräten mit einem Upgrade auf Android 13 und höher Die XOR-Komprimierungsfunktion ist nicht ist standardmäßig aktiviert. Fügen Sie zur Aktivierung der XOR-Komprimierung Folgendes zur .mk-Datei.

PRODUCT_VENDOR_PROPERTIES += ro.virtual_ab.compression.xor.enabled=true

Die XOR-Komprimierung ist standardmäßig für Geräte aktiviert, die Werte von android_t_baseline.mk

Zusammenführung von Userspaces

Bei Geräten mit einem Upgrade auf Android 13 und höher Vorgang zum Zusammenführen von Userspaces, wie unter Device Mapper beschrieben Layering wird nicht durch Standardeinstellung. Fügen Sie die folgende Zeile in die .mk des Geräts ein, um das Zusammenführen von Nutzerbereichen zu aktivieren Datei:

PRODUCT_VENDOR_PROPERTIES += ro.virtual_ab.userspace.snapshots.enabled=true

Das Zusammenführen von Benutzerbereichen ist standardmäßig auf Geräten aktiviert, die mit 13 und höher.

Bootsteuerungs-HAL

Über die Bootsteuerung HAL bietet eine Schnittstelle für OTA-Clients zur Steuerung von Boot-Slots. Virtuelles A/B erfordert ein Upgrade der Nebenversion des HAL für die Bootsteuerung, da zusätzliche APIs sind erforderlich, damit der Bootloader während des Flashens oder Zurücksetzens auf die Werkseinstellungen geschützt ist. Weitere Informationen finden Sie unter iBootControl.hal und types.hal finden Sie die neueste Version der HAL-Definition.

// hardware/interfaces/boot/1.1/types.hal
enum MergeStatus : uint8_t {
    NONE, UNKNOWN, SNAPSHOTTED, MERGING, CANCELLED };

// hardware/interfaces/boot/1.1/IBootControl.hal
package android.hardware.boot@1.1;
interface IBootControl extends @1.0::IBootControl {
    setSnapshotMergeStatus(MergeStatus status)
        generates (bool success);
    getSnapshotMergeStatus()
        generates (MergeStatus status);
}

// Recommended implementation

Return<bool> BootControl::setSnapshotMergeStatus(MergeStatus v) {
    // Write value to persistent storage
    // e.g. misc partition (using libbootloader_message)
    // bootloader rejects wipe when status is SNAPSHOTTED
    // or MERGING
}

Fstab-Änderungen

Die Integrität der Metadatenpartition ist entscheidend für den Bootvorgang. vor allem direkt nach der OTA-Aktualisierung. Die Metadatenpartition muss also geprüft werden, bevor first_stage_init es bereitstellt. Fügen Sie dazu den check-Flag „fs_mgr“ für den Eintrag für /metadata. Im Folgenden finden Sie Beispiel:

/dev/block/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard,sync wait,formattable,first_stage_mount,check

Kernel-Anforderungen

Setzen Sie CONFIG_DM_SNAPSHOT auf true, um die Snapshot-Funktion zu aktivieren.

Fügen Sie bei Geräten mit F2FS das Flag f2fs: export FS_NOCOW_FL to user, um das Anpinnen von Dateien zu beheben. Fügen Sie den f2fs: support ausgerichteten angepinnten file.

Virtual A/B basiert auf Funktionen, die in der Kernel-Version 4.3 hinzugefügt wurden: dem Overflow Statusbit in den Zielen snapshot und snapshot-merge fest. Alle Geräte werden gestartet mit Android 9 oder höher sollte bereits die Kernel-Version 4.4 oder höher haben.

Zum Aktivieren komprimierter Snapshots wird mindestens Kernel-Version 4.19 unterstützt. Legen Sie CONFIG_DM_USER=m oder CONFIG_DM_USER=y fest. Wenn Sie die erste Variante (ein Modul) verwenden, muss das Modul in die Ramdisk in der ersten Phase geladen werden. Dies kann erreicht werden, indem Fügen Sie dem Makefile des Geräts die folgende Zeile hinzu:

BOARD_GENERIC_RAMDISK_KERNEL_MODULES_LOAD := dm-user.ko

Retrofit auf Geräten mit Upgrade auf Android 11

Beim Upgrade auf Android 11 können Geräte, die mit dynamischen Partitionen auf den Markt gekommen sind, das virtuelle A/B nachrüsten. Der Aktualisierungsprozess ist größtenteils derselbe wie bei Geräte, die mit virtuellem A/B auf den Markt gebracht wurden, mit einigen geringfügigen Unterschieden:

  • Speicherort der COW-Dateien – Für Startgeräte verwendet der OTA-Client den des gesamten verfügbaren Leerraums in der Superpartition, bevor er Speicherplatz in /data Für nachrüstbare Geräte ist immer genug Platz in der -Partition, sodass die COW-Datei niemals auf /data erstellt wird.

  • Funktions-Flags während der Build-Phase: Bei Geräten, die mit Virtual A/B nachgerüstet werden, PRODUCT_VIRTUAL_AB_OTA und PRODUCT_VIRTUAL_AB_OTA_RETROFIT sind festgelegt an true, wie hier gezeigt:

    (call inherit-product, \
  (SRC_TARGET_DIR)/product/virtual_ab_ota_retrofit.mk)

  • Superpartitionsgröße: Geräte, die mit virtuellem A/B gestartet werden, können reduziert werden. BOARD_SUPER_PARTITION_SIZE, weil sich B-Slots nicht im Superbereich befinden -Partition an. Geräte, die auf virtuelles A/B umrüsten, behalten die alte Super Partition bei Größe, sodass BOARD_SUPER_PARTITION_SIZE größer oder gleich 2 * sum(size of update groups) + Overhead, der wiederum größer oder gleich 2 * sum(size of partitions) + .

Bootloader-Änderungen

Während des Zusammenführungsschritts eines Updates enthält /data die einzige gesamte Instanz des Android-Betriebssystem Sobald die Migration gestartet wurde, werden system, vendor und product Partitionen sind unvollständig, bis der Kopiervorgang abgeschlossen ist. Wenn das Gerät währenddessen auf die Werkseinstellungen zurückgesetzt werden, entweder durch Wiederherstellung kann das Gerät nicht gestartet werden.

Schließen Sie vor dem Löschen von /data die Zusammenführung bei der Wiederherstellung oder im Rollback ab. Gerätestatus:

  • Wenn der neue Build zuvor erfolgreich gestartet wurde, schließen Sie die Migration ab.
  • Andernfalls führen Sie ein Rollback zur alten Anzeigenfläche durch: <ph type="x-smartling-placeholder">
      </ph>
    • Führen Sie bei dynamischen Partitionen ein Rollback zum vorherigen Status durch.
    • Stellen Sie bei statischen Partitionen den aktiven Slot auf den alten Slot ein.

Sowohl der Bootloader als auch fastbootd können die Partition /data löschen, wenn Gerät entsperrt ist. fastbootd kann zwar den Abschluss der Migration erzwingen, das Bootloader funktioniert nicht. Der Bootloader weiß nicht, ob sich eine Zusammenführung in oder welche Blöcke in /data die Betriebssystempartitionen darstellen. Geräte müssen Verhindern, dass der Nutzer das Gerät unwissentlich funktionsunfähig macht (Back-up) Dazu gehen Sie so vor:

  1. Implementieren Sie den Boot-Control-HAL, damit der Bootloader den festgelegten Wert lesen kann mit der Methode setSnapshotMergeStatus().
  2. Wenn der Zusammenführungsstatus MERGING oder SNAPSHOTTED lautet und der Slot wurde in den neu aktualisierten Slot geändert, dann wird eine Anfrage zum Löschen userdata, metadata oder die Partition, in der der Zusammenführungsstatus gespeichert ist, muss im Bootloader abgelehnt wird.
  3. Implementieren Sie den Befehl fastboot snapshot-update cancel, damit Nutzer signalisiert dem Bootloader, dass er diesen Schutzmechanismus umgehen möchte.
  4. Ändere die benutzerdefinierten Flash-Tools oder -Skripte so, dass beim Flashen des gesamten Geräts fastboot snapshot-update cancel ausgegeben wird. Diese Ausgabe ist sicher, weil Durch das Flashen des gesamten Geräts wird das OTA-Update entfernt. Tools können diesen Befehl erkennen zur Laufzeit durch Implementieren von fastboot getvar snapshot-update-status. Dieses können Sie zwischen Fehlerbedingungen unterscheiden.

Beispiel

struct VirtualAbState {
    uint8_t StructVersion;
    uint8_t MergeStatus;
    uint8_t SourceSlot;
};

bool ShouldPreventUserdataWipe() {
    VirtualAbState state;
    if (!ReadVirtualAbState(&state)) ...
    return state.MergeStatus == MergeStatus::MERGING ||
           (state.MergeStatus == MergeStatus::SNAPSHOTTED &&
            state.SourceSlot != CurrentSlot()));
}

Änderungen an Fastboot-Tools

Android 11 nimmt folgende Änderungen am Fastboot-Modus vor Protokoll:

  • getvar snapshot-update-status: gibt den Wert zurück, den der Bootvorgang HAL, der an den Bootloader übermittelt wird: <ph type="x-smartling-placeholder">
      </ph>
    • Wenn der Status MERGING lautet, muss der Bootloader merging zurückgeben.
    • Wenn der Status SNAPSHOTTED lautet, muss der Bootloader snapshotted zurückgeben.
    • Andernfalls muss der Bootloader none zurückgeben.
  • snapshot-update merge: Führt einen Zusammenführungsvorgang aus und startet. Wiederherstellung bzw. Fastbootd ein, wenn nötig. Dieser Befehl ist nur gültig, wenn snapshot-update-status ist merging und wird nur in Fastbootd unterstützt.
  • snapshot-update cancel: Legt den Zusammenführungsstatus der HAL der Bootsteuerung auf CANCELLED. Dieser Befehl ist ungültig, wenn das Gerät gesperrt ist.
  • erase oder wipe: Ein erase oder wipe von metadata, userdata oder Eine Partition mit dem Zusammenführungsstatus für den HAL der Bootsteuerung sollte überprüft werden. Status der Snapshot-Zusammenführung. Lautet der Status MERGING oder SNAPSHOTTED, sollte der Vorgang abgebrochen werden.
  • set_active: Ein set_active-Befehl, mit dem der aktive Slot geändert wird sollte der Status der Snapshot-Zusammenführung überprüft werden. Wenn der Status MERGING lautet, sollte der Vorgang abgebrochen werden. Der Slot kann sicher im SNAPSHOTTED.

Durch diese Änderungen soll verhindert werden, dass ein Gerät versehentlich nicht mehr bootfähig ist. aber sie können automatisierte Tools stören. Wenn die Befehle als zum Flashen aller Partitionen, wie z. B. fastboot flashall, wird empfohlen, den folgenden Ablauf zu verwenden:

  1. Abfrage getvar snapshot-update-status.
  2. Wenn merging oder snapshotted, gib snapshot-update cancel aus.
  3. Fahren Sie dann mit den blinkenden Schritten fort.

Speicheranforderungen reduzieren

Geräte, die keinen vollen A/B-Speicher in Super zugewiesen haben und für die ein um bei Bedarf /data zu verwenden, wird dringend empfohlen, die Blockzuordnung zu verwenden. . Das Blockzuordnungstool sorgt für einheitliche Blockzuweisungen zwischen Builds. unnötige Schreibvorgänge in den Snapshot reduzieren. Dies wird unter Reduzierung OTA-Größe:

OTA-Komprimierungsmethoden

OTA-Pakete können für verschiedene Leistungsmesswerte abgestimmt werden. Android bietet mehrere unterstützte Komprimierungsmethoden (gz, lz4, zstd und none), die Kompromisse zwischen Installationszeit, COW-Speichernutzung, Startzeit und Snapshot. Zeitpunkt der Zusammenführung. Die Standardoption für virtuelle Abs mit Komprimierung ist die gz compression method (Hinweis: Die relative Leistung zwischen den Komprimierungsmethoden. variiert je nach CPU-Geschwindigkeit und Speicherdurchsatz. auf dem Gerät. Für alle unten generierten OTA-Pakete ist PostInstall deaktiviert, was verlangsamt die Startzeit leicht. Die dynamische Gesamtpartitionsgröße einer Das vollständige Kontingent ohne Komprimierung beträgt 4,81 GB.

Inkrementelles OTA-Update auf Pixel 6 Pro

Installationszeit ohne Phase nach der Installation COW-Speichernutzung Nach OTA-Startzeit Zeitpunkt der Snapshot-Zusammenführung
GZ 24 Min. 1,18 GB 40,2 Sek. 45,5 Sek.
lz4 13 Min. 1,49 GB 37,4 Sek. 37,1 Sek.
Keine 13 Min. 2,90 GB 37,6 Sek. 40,7 Sek.

Vollständiges OTA-Update auf Pixel 6 Pro

Installationszeit ohne Phase nach der Installation COW-Speicherplatznutzung Nach OTA-Startzeit Zeitpunkt der Snapshot-Zusammenführung
GZ 23 Min. 2,79 GB 24,9 Sek. 41,7 Sek.
lz4 12 Min. 3,46 GB 20,0 Sek. 25,3 Sek.
Keine 10 Min. 4,85 GB 20,6 Sek. 29,8 Sek.