Virtuelle A/B-Patches implementieren

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

Zuweisbaren Speicherplatz beim Sideloading korrekt prüfen

Das Sideloading eines vollständigen OTA-Pakets auf einem virtuellen A/B-Gerät mit einem Super- Partition mit einer Größe kleiner als *2 * sum(size of update groups)* kann fehlschlagen. durch den folgenden Wert im Wiederherstellungslog /tmp/recovery.log:

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.

Dieses Problem wurde durch Hinzufügen der Funktion StopActionInternal behoben. CleanupPreviousUpdateAction bricht ausstehende Aufgaben beim Löschen ab. Es hat eine Variable, die die Aufgaben-ID der ausstehenden Aufgabe in der Nachrichtenschleife verfolgt. Bei „destroy“ wird die ausstehende Aufgabe abgebrochen, um einen Segmentierungsfehler 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 gestartet wird (Android 11 und höher) und der Startvorgang abgeschlossen ist, update_engine ruft ScheduleWaitMarkBootSuccessful() auf und WaitForMergeOrSchedule() Dadurch wird der Zusammenführungsprozess gestartet. Das Gerät im alten Slot neu gestartet. Da die Zusammenführung bereits gestartet wurde, schlägt das Gerät und funktioniert nicht mehr.

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 (beheben Sie den Fehlercode potenzieller Platzhalterfehler bei Verspätung von markSlotSuccessful)
  • 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 der folgende dm-verity-Optionen:

  • 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, funktionieren möglicherweise auch A/B-Geräte. Verwenden Sie nur die AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO-Versionsmodus.

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

Weitere Informationen finden Sie in der Dokumentation zu Verity: Umgang mit dm-verity Fehler.

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 ausgefü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).