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 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.

Dieses Problem wurde durch Hinzufügen der Funktion StopActionInternal behoben. CleanupPreviousUpdateAction storniert ausstehende Aufgaben beim Löschen. Er verwaltet 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 sich die folgenden Änderungen in der Android 11-Quellstruktur befinden, um SIGSEGV-Abstürze in update_engine während der Zusammenführung 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 der Quellstruktur 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)

Korrekte dm-verity-Konfiguration sicherstellen

In 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 Bestätigungsfehler dazu, dass die vbmeta-Partition beschädigt wird und Nicht-A/B-Geräte nicht funktionieren. 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 so, dass stattdessen der Modus AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO verwendet wird.

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-Images und Anbieter-Images separat erstellen und sie dann mit merge_target_files zusammenführen, werden virtuelle A/B-Konfigurationen möglicherweise während des Zusammenführungsprozesses fälschlicherweise verworfen. 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

Seit Android 13 wurde snapuserd vom Anbieter-Ramdisk zum generischen 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).