Implementieren Sie virtuelle A/B-Patches

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

Überprüfen Sie den zuweisbaren Speicherplatz beim Seitenladen korrekt

Das Querladen eines vollständigen OTA-Pakets auf ein virtuelles A/B-Gerät, das über eine Superpartition mit einer Größe kleiner als *2 * sum(size of update groups)* verfügt, schlägt möglicherweise mit folgendem Fehler im Wiederherstellungsprotokoll /tmp/recovery.log fehl:

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

Hier ist ein Beispiel des Protokolls:

[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 es neu und flashen Sie die Startpartition oder Wiederherstellungspartition, wenn das Gerät die Wiederherstellung nicht als Startvorgang verwendet.

Segmentierungsfehler während der Zusammenführung behoben

Nach der Anwendung eines OTA-Updates während des VAB-Mergevorgangs führt ein Aufruf von update_engine_client --cancel zum Absturz von CleanupPreviousUpdateAction . Ein potenzieller Fehler durch einen wilden Zeiger besteht auch, wenn markSlotSuccessful zu spät kommt.

Dieses Problem wurde durch Hinzufügen der StopActionInternal Funktion behoben. CleanupPreviousUpdateAction bricht ausstehende Aufgaben beim Zerstören ab. Es verwaltet eine Variable, die die Aufgaben-ID der ausstehenden Aufgabe in der Nachrichtenschleife verfolgt. Beim Zerstören wird die ausstehende Aufgabe abgebrochen, um einen Segfault zu vermeiden.

Stellen Sie sicher, dass die folgenden Änderungen in Ihrem Android 11-Quellbaum vorhanden sind, um SIGSEGV Abstürze in update_engine während der Zusammenführung zu beheben:

  • CL 1439792 (Voraussetzung für CL 1439372)
  • CL 1439372 ( CleanupPreviousUpdateAction : Ausstehende Aufgaben beim Zerstören abbrechen)
  • CL 1663460 (behebt den potenziellen Wild-Pointer-Fehler, wenn markSlotSuccessful zu spät kommt)

Beheben Sie die fehlerhafte VAB-Slot-Umschaltung und veröffentlichen Sie das OTA-Update

In Android 11 und höher kann das Versäumnis, einen Slot-Switch in einem Gerät nach einem OTA-Update zu synchronisieren, ein Gerät in einen unbrauchbaren Zustand versetzen. Wenn die Slot-Switching-Implementierung Ihrer IBootControl HAL Schreibvorgänge ausführt, müssen Sie diese Schreibvorgänge sofort löschen. Wenn die Schreibvorgänge nicht gelöscht werden und das Gerät nach Beginn der Zusammenführung neu startet, die Hardware jedoch den Steckplatzschalter-Schreibvorgang nicht löschen kann, kehrt das Gerät möglicherweise zum vorherigen Steckplatz zurück und startet nicht.

Eine Beispielcodelösung finden Sie in diesem CL: CL 1535570 .

Verhindern Sie eine vorzeitige Zusammenführung von update_engine

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

Fügen Sie die folgenden Änderungen zu Ihrem Quellbaum hinzu. Beachten Sie, dass CL 1664859 optional ist.

  • CL 1439792 (Voraussetzung für CL 1439372)
  • CL 1439372 ( CleanupPreviousUpdateAction : Ausstehende Aufgaben beim Zerstören abbrechen)
  • CL 1663460 (behebt den potenziellen Wild-Pointer-Fehler, wenn markSlotSuccessful zu spät kommt)
  • CL 1664859 (optional – unittest für CleanupPreviousUpdateAction hinzufügen)

Verhindern Sie Datenverlust oder -beschädigung aufgrund übersprungener Metadaten

Wenn in Android 11 und höher ein Speichergerät über einen flüchtigen Write-Back-Cache verfügt, werden unter bestimmten Bedingungen die Metadaten einer abgeschlossenen Zusammenführung übersprungen, was zu Datenverlust oder -beschädigung führt.

Bedingungen:

  1. Nach Abschluss einer Zusammenführungsoperation einer Ausnahmegruppe wurde merge_callback() aufgerufen.
  2. Die Metadaten wurden im COW-Gerät aktualisiert, das den Abschluss der Zusammenführung verfolgt. (Dieses Update des COW-Geräts wird sauber gelöscht.)

Ergebnis: Das System stürzte ab, da der Cache des Speichergeräts der letzten Zusammenführung nicht geleert wurde.

Sehen Sie sich Folgendes an, um eine Lösung umzusetzen:

Stellen Sie sicher, dass die dm-verity-Konfiguration korrekt ist

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 Verity-Fehler dazu, dass die vbmeta-Partition beschädigt wird und Nicht-A/B-Geräte funktionsunfähig werden. Wenn eine Zusammenführung begonnen hat, könnten auch A/B-Geräte nicht mehr funktionsfähig sein. Verwenden Sie nur den Verity-Modus AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO .

  1. Legen Sie CONFIG_DM_VERITY_AVB=n im Kernel fest
  2. Konfigurieren Sie Geräte so, dass sie stattdessen den AVB_HASHTREE_ERROR_MODE_MANAGED_RESTART_AND_EIO -Modus verwenden.

Weitere Informationen und praktische Hinweise finden Sie in der Verity-Dokumentation: Umgang mit dm-verity-Fehlern .

Überspringen Sie Verity-Arbeiten als Reaktion auf einen E/A-Fehler beim Herunterfahren des Systems im Notfall

Wenn in Android 11 und höher eine Notabschaltung des Systems aufgerufen wird (wie im Fall einer thermischen Abschaltung), kann ein DM-Gerät aktiv sein, während das Blockgerät keine E/A-Anfragen mehr verarbeiten kann. In diesem Zustand können E/A-Fehler, die von neuen dm-E/A-Anforderungen oder von bereits laufenden E/A-Anfragen behandelt werden, zu einem Zustand der Verity Corruption führen, was eine Fehleinschätzung darstellt.

Um die eigentliche Arbeit als Reaktion auf einen E/A-Fehler beim Herunterfahren des Systems zu überspringen, verwenden Sie Folgendes:

CL 1847875 (Verity-Arbeit wird als Reaktion auf einen E/A-Fehler beim Herunterfahren übersprungen)

Stellen Sie sicher, dass DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED deaktiviert ist

Android Go-Geräte, auf denen der Kernel 4.19 oder früher ausgeführt wird, haben möglicherweise DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=y in ihrer Kernelkonfiguration. Diese Einstellung ist nicht mit Virtual A/B kompatibel und verursacht bekanntermaßen seltene Probleme mit der Beschädigung von Seiten, wenn beide zusammen aktiviert sind.

Deaktivieren Sie es für Kernel 4.19 und früher, indem Sie CONFIG_DM_ANDROID_VERITY_AT_MOST_ONCE_DEFAULT_ENABLED=n in der Kernel-Konfiguration festlegen.

Für Kernel 5.4 und höher wurde der Code entfernt und die Konfigurationsoption ist nicht verfügbar.

Bestätigen Sie, dass die zusammengeführte Datei korrekt konfiguriert ist

Wenn Sie System-Images und Anbieter-Images getrennt erstellen und dann merge_target_files verwenden, um sie zusammenzuführen, werden virtuelle A/B-Konfigurationen während des Zusammenführungsprozesses möglicherweise fälschlicherweise gelöscht. Um zu überprü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)

Aktualisieren Sie die erforderlichen Komponenten

Ab Android 13 wurde snapuserd von der Hersteller-Ramdisk auf die generische Ramdisk verschoben. Wenn Ihr Gerät auf Android 13 aktualisiert wird, ist es möglich, dass sowohl die Hersteller-Ramdisk als auch die generische Ramdisk eine Kopie von snapuserd enthalten. In dieser Situation benötigt Virtual A/B die Systemkopie von snapuserd . Um sicherzustellen, dass die richtige Kopie von snapuserd vorhanden ist, wenden Sie CL 2031243 an (kopieren Sie snapuserd nach first_stage_ramdisk).