Mit Android 10 wird User Data Checkpoint (UDC) eingeführt, mit dem Android auf den vorherigen Zustand zurückgesetzt werden kann, wenn eine Android-Over-the-Air-Aktualisierung fehlschlägt. Wenn bei der UDC ein Android-Over-the-air-Update fehlschlägt, kann das Gerät sicher auf den vorherigen Zustand zurückgesetzt werden. Obwohl A/B-Updates dieses Problem für den frühen Start lösen, wird das Rollback nicht unterstützt, wenn die auf /data bereitgestellte Nutzerdatenpartition geändert wird.
Mit UDC kann das Gerät die Partition für Nutzerdaten auch nach einer Änderung wiederherstellen. Die UDC-Funktion erreicht dies durch Checkpoint-Funktionen für das Dateisystem, eine alternative Implementierung, wenn das Dateisystem keine Checkpoints unterstützt, die Integration in den A/B-Mechanismus des Bootloaders und die Unterstützung von nicht A/B-Updates sowie die Unterstützung der Bindung von Schlüsselversionen und der Vermeidung von Schlüssel-Rollbacks.
Auswirkungen auf Nutzer
Die UDC-Funktion verbessert das OTA-Update für Nutzer, da bei einem fehlgeschlagenen OTA-Update weniger Nutzer ihre Daten verlieren. Dies kann die Anzahl der Supportaufrufe von Nutzern reduzieren, bei denen während des Aktualisierungsvorgangs Probleme auftreten. Wenn ein Over-the-air-Update jedoch fehlschlägt, kann es sein, dass das Gerät mehrmals neu gestartet wird.
Funktionsweise
Prüfpunktfunktion in verschiedenen Dateisystemen
Beim F2FS-Dateisystem fügt UDC dem vorgelagerten Linux-Kernel 4.20 die Prüfpunktfunktion hinzu und portiert sie an alle gängigen Kernels, die von Geräten mit Android 10 unterstützt werden.
Bei anderen Dateisystemen verwendet UDC ein virtuelles Gerät des Geräte-Mappers namens dm_bow für die Checkpoint-Funktion. dm_bow befindet sich zwischen dem Gerät und dem Dateisystem. Wenn eine Partition bereitgestellt wird, wird ein Trim-Befehl ausgegeben, wodurch das Dateisystem Trim-Befehle für alle freien Blöcke ausgibt. dm_bow fängt diese Kürzungen ab und verwendet sie, um eine Liste mit freien Blöcken einzurichten. Lese- und Schreibvorgänge werden dann unverändert an das Gerät gesendet, aber bevor ein Schreibvorgang zugelassen wird, werden die für die Wiederherstellung erforderlichen Daten in einem kostenlosen Block gesichert.
Prüfpunktverfahren
Wenn eine Partition mit dem Flag checkpoint=fs/block bereitgestellt wird, ruft Android restoreCheckpoint auf dem Laufwerk auf, damit das Gerät den aktuellen Checkpoint wiederherstellen kann. init ruft dann die Funktion needsCheckpoint auf, um festzustellen, ob sich das Gerät entweder im Bootloader-A/B-Status befindet oder die Anzahl der Aktualisierungsversuche festgelegt hat. Wenn einer der beiden Werte „true“ ist, ruft Android createCheckpoint auf, um entweder Bereitstellungs-Flags hinzuzufügen oder ein dm_bow-Gerät zu erstellen.
Nachdem die Partition bereitgestellt wurde, wird der Checkpoint-Code aufgerufen, um Schnitte auszugeben.
Der Bootvorgang wird dann wie gewohnt fortgesetzt. Bei LOCKED_BOOT_COMPLETE ruft Android commitCheckpoint auf, um den aktuellen Prüfpunkt mit Commit zu übergeben. Das Update wird dann wie gewohnt fortgesetzt.
Keymaster-Schlüssel verwalten
Keymaster-Schlüssel werden für die Geräteverschlüsselung oder andere Zwecke verwendet. Um diese Schlüssel zu verwalten, verzögert Android Schlüssellöschanrufe, bis der Checkpoint festgeschrieben wurde.
Gesundheitszustand überwachen
Ein Dienst zur Systemüberwachung prüft, ob genügend Speicherplatz vorhanden ist, um einen Checkpoint zu erstellen. Der Dienst befindet sich in cp_healthDaemon unter Checkpoint.cpp.
Die folgenden Verhaltensweisen des System-Daemons können konfiguriert werden:
ro.sys.cp_msleeptime: Mit dieser Einstellung wird festgelegt, wie oft das Gerät die Laufwerknutzung prüft.ro.sys.cp_min_free_bytes: Steuert den Mindestwert, nach dem der Dienst zur Systemdiagnose sucht.ro.sys.cp_commit_on_full: Steuert, ob der Systemdiagnose-Daemon das Gerät neu startet oder den Prüfpunkt festschreibt und fortgesetzt wird, wenn das Laufwerk voll ist.
Checkpoint-APIs
Checkpoint APIs werden von der UDC-Funktion verwendet. Weitere von UDC verwendete APIs finden Sie unter IVold.aidl.
void startCheckpoint(int retry)
Erstellt einen Checkpoint.
Das Framework ruft diese Methode auf, wenn es bereit ist, ein Update zu starten. Der Prüfpunkt wird erstellt, bevor prüfpunktbasierte Dateisysteme wie Nutzerdaten nach dem Neustart R/W bereitgestellt werden. Wenn die Anzahl der Wiederholungen positiv ist, überwacht die API die Wiederholungen und der Aktualisierer ruft needsRollback auf, um zu prüfen, ob ein Rollback des Updates erforderlich ist. Wenn die Anzahl der Wiederholungen -1 ist, greift die API auf die Entscheidung des A/B-Bootloaders zurück.
Diese Methode wird nicht bei einer normalen A/B-Aktualisierung aufgerufen.
void commitChanges()
Führt ein Commit der Änderungen durch.
Das Framework ruft diese Methode nach dem Neustart auf, wenn die Änderungen für den Commit bereit sind. Diese Funktion wird aufgerufen, bevor Daten wie Bilder, Videos, SMS und Serverempfangsbestätigungen in userdata und vor BootComplete geschrieben werden.
Wenn kein aktives Update mit Checkpoint vorhanden ist, hat diese Methode keine Auswirkungen.
abortChanges()
Erzwingt einen Neustart und kehrt zum Checkpoint zurück. Verwirft alle Änderungen an Nutzerdaten seit dem ersten Neustart.
Das Framework ruft diese Methode nach dem Neustart, aber vor commitChanges auf.
retry_counter wird verringert, wenn diese Methode aufgerufen wird. Logeinträge werden generiert.
bool needsRollback()
Bestimmt, ob ein Rollback erforderlich ist.
Auf Geräten ohne Checkpoint wird false zurückgegeben. Auf Prüfpunktgeräten wird während eines Nicht-Prüfpunkt-Starts true zurückgegeben.
UDC implementieren
Referenzimplementierung
Ein Beispiel für die Implementierung von UDC finden Sie unter dm-bow.c. Weitere Informationen zu dieser Funktion finden Sie unter dm-bow.txt.
Einrichten
Achten Sie darauf, dass in der Datei init.hardware.rc unter on fs Folgendes enthalten ist:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --early
Achten Sie darauf, dass in der Datei init.hardware.rc unter on late-fs Folgendes enthalten ist:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late
Achten Sie darauf, dass in der Datei fstab.hardware /data als latemount getaggt ist.
/dev/block/bootdevice/by-name/userdata /data f2fs noatime,nosuid,nodev,discard,reserve_root=32768,resgid=1065,fsync_mode=nobarrier latemount,wait,check,fileencryption=ice,keydirectory=/metadata/vold/metadata_encryption,quota,formattable,sysfs_path=/sys/devices/platform/soc/1d84000.ufshc,reservedsize=128M,checkpoint=fs
Metadatenpartition hinzufügen
Für UDC ist eine Metadatenpartition erforderlich, um die Anzahl der Wiederholungen und die Schlüssel für den Nicht-Bootloader zu speichern. Richten Sie eine Metadatenpartition ein und stellen Sie sie frühzeitig unter /metadata bereit.
Achten Sie darauf, dass /metadata in der Datei fstab.hardware als earlymount oder first_stage_mount getaggt ist.
/dev/block/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard,sync wait,formattable,first_stage_mount
Die Partition wird mit Nullen initialisiert.
Fügen Sie BoardConfig.mk die folgenden Zeilen hinzu:
BOARD_USES_METADATA_PARTITION := true BOARD_ROOT_EXTRA_FOLDERS := existing_folders metadata
Systeme aktualisieren
F2FS-Systeme
Bei Systemen, die F2FS zum Formatieren von Daten verwenden, muss Ihre F2FS-Version Checkpoints unterstützen. Weitere Informationen finden Sie unter Prüfpunktfunktion in verschiedenen Dateisystemen.
Fügen Sie dem Abschnitt <fs_mgr_flags> von fstab das Flag checkpoint=fs für das Gerät hinzu, das unter /data bereitgestellt wird.
Nicht F2FS-Systeme
Bei Nicht-F2FS-Systemen muss dm-bow in der Kernelkonfiguration aktiviert sein.
Fügen Sie dem Abschnitt <fs_mgr_flags> von fstab das Flag checkpoint=block für das Gerät hinzu, das unter /data bereitgestellt wird.
Protokolle prüfen
Logeinträge werden generiert, wenn Checkpoint APIs aufgerufen werden.
Zertifizierungsstufe
Führen Sie zum Testen Ihrer UDC-Implementierung die VtsKernelCheckpointTest VTS-Tests aus.