Virtuelle A/B-Patches implementieren

Wählen Sie die folgenden Patches aus, um die folgenden bekannten Probleme zu beheben.

Zuweisbaren Speicherplatz beim Sideloading richtig prüfen

Das Sideloading eines vollständigen OTA-Pakets auf einem virtuellen A/B-Gerät mit einer Superpartition, deren Größe kleiner als * 2 * Summe(Größe der Updategruppen) ist, kann fehlschlagen. Im Wiederherstellungsprotokoll /tmp/recovery.log wird dann Folgendes angezeigt:

The maximum size of all groups with suffix _b (...) has exceeded half of allocatable space for dynamic partitions ...

Hier ein Beispiel für das Protokoll:

[INFO:dynamic_partition_control_android.cc(1020)] Will overwrite existing partitions. Slot A may be unbootable until update finishes!
[...]
[ERROR:dynamic_partition_control_android.cc(803)] The maximum size of all groups with suffix _b (2147483648) has exceeded half of allocatable space for dynamic partitions 1073741824.

Wenn dieses Problem auftritt, wählen Sie CL 1399393 aus, erstellen Sie die Boot- oder Wiederherstellungspartition neu und flashen Sie sie, falls das Gerät nicht die Wiederherstellung zum Booten verwendet.

Segmentierungsfehler beim Zusammenführen beheben

Nach der Anwendung eines OTA-Updates führt ein Aufruf von update_engine_client --cancel während des VAB-Merge-Prozesses dazu, dass CleanupPreviousUpdateAction abstürzt. Ein potenzieller Fehler des Wild Pointers kann auch auftreten, wenn markSlotSuccessful zu spät kommt.

Das Problem wurde durch Hinzufügen der Funktion StopActionInternal behoben. CleanupPreviousUpdateAction storniert ausstehende Aufgaben beim Löschen. Es wird eine Variable verwaltet, die die Aufgaben-ID der ausstehenden Aufgabe im Nachrichten-Loop verfolgt. Bei „destroy“ wird die ausstehende Aufgabe abgebrochen, um einen Segmentfehler zu vermeiden.

Achten Sie darauf, dass die folgenden Änderungen in Ihrem Android 11-Quellbaum enthalten sind, um SIGSEGV-Abstürze in update_engine während des Zusammenführens zu beheben:

  • CL 1439792 (Voraussetzung für CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: cancel pending tasks on destroy)
  • CL 1663460 (potenzieller Fehler bei Wild Pointers beheben, wenn markSlotSuccessful zu spät kommt)

Vorzeitige Zusammenführung von update_engine verhindern

Wenn ein Gerät (Android 11 und höher) gestartet wird und der Startvorgang abgeschlossen ist, ruft update_engine ScheduleWaitMarkBootSuccessful() und WaitForMergeOrSchedule() auf. Dadurch wird der Zusammenführungsprozess gestartet. Das Gerät wird jedoch mit dem alten Steckplatz neu gestartet. Da die Zusammenführung bereits gestartet wurde, kann das Gerät nicht gestartet werden und ist nicht mehr funktionsfähig.

Fügen Sie Ihrem Quellbaum die folgenden Änderungen hinzu. Hinweis: CL 1664859 ist optional.

  • CL 1439792 (Voraussetzung für CL 1439372)
  • CL 1439372 (CleanupPreviousUpdateAction: cancel pending tasks on destroy)
  • CL 1663460 (potenzieller Fehler bei Wild Pointers beheben, wenn markSlotSuccessful zu spät kommt)
  • CL 1664859 (optional – unittest für CleanupPreviousUpdateAction hinzufügen)

Prüfen Sie die korrekte dm-verity-Konfiguration.

Unter Android 11 und höher können Geräte versehentlich mit den folgenden dm-verity-Optionen konfiguriert werden:

  • CONFIG_DM_VERITY_AVB=y im Kernel
  • Der Bootloader ist für die Verwendung eines beliebigen Verity-Modus (z. B. AVB_HASHTREE_ERROR_MODE_RESTART_AND_INVALIDATE) ohne AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO konfiguriert.

Bei dieser Gerätekonfiguration führt jeder Verity-Fehler dazu, dass die vbmeta-Partition beschädigt wird und Nicht-A/B-Geräte unbrauchbar werden. Wenn eine Zusammenführung gestartet wurde, können auch A/B-Geräte nicht mehr verwendet werden. Verwenden Sie nur den Verifizierungsmodus AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

  1. Legen Sie CONFIG_DM_VERITY_AVB=n im Kernel fest.
  2. Konfigurieren Sie die Geräte stattdessen für den Modus AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO.

Weitere Informationen finden Sie in der Verity-Dokumentation: dm-verity-Fehler beheben.

Prüfen, ob die zusammengeführte Datei richtig konfiguriert ist

Wenn Sie System- und Anbieter-Images separat erstellen und dann mit merge_target_files zusammenführen, werden virtuelle A/B-Konfigurationen möglicherweise während des Zusammenführungsvorgangs fälschlicherweise gelöscht. Um zu prüfen, ob die virtuellen A/B-Konfigurationen in der zusammengeführten Zieldatei korrekt sind, wenden Sie die folgenden Patches an: CL 2084183 (identische Schlüssel/Wert-Paare in dynamischen Partitionsinformationen zusammenführen)

Erforderliche Komponenten aktualisieren

Ab Android 13 wurde snapuserd aus dem Anbieter-Ramdisk in das generisch verwendete Ramdisk verschoben. Wenn auf Ihrem Gerät ein Upgrade auf Android 13 durchgeführt wird, ist es möglich, dass sowohl das RAM-Disk des Anbieters als auch das generisch verwendete RAM-Disk eine Kopie von snapuserd enthalten. In diesem Fall benötigt Virtual A/B die Systemkopie von snapuserd. Um sicherzustellen, dass die richtige Kopie von snapuserd vorhanden ist, wenden Sie CL 2031243 an (snapuserd in first_stage_ramdisk kopieren).