Mit Android 10 wird der Nutzerdaten-Prüfpunkt (User Data Checkpoint, UDC) eingeführt. Dadurch kann Android bei einem fehlgeschlagenen Over-the-air-Update (OTA) auf den vorherigen Zustand zurückgesetzt werden. Wenn bei der UDC ein Android-Over-the-air-Update fehlschlägt, kann das Gerät sicher auf den vorherigen Zustand zurückgesetzt werden. A/B-Updates lösen dieses Problem zwar beim frühen Start, aber ein Rollback wird nicht unterstützt, wenn die Partition mit Nutzerdaten (auf /data bereitgestellt) 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. So lässt sich die Anzahl der Supportanrufe von Nutzern reduzieren, die während des Updatevorgangs auf Probleme stoßen. 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
Für das F2FS-Dateisystem fügt UDC die Checkpoint-Funktion dem Upstream-Linux-Kernel 4.20 hinzu und backports sie in alle gängigen Kernel, 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 kostenlosen Blöcke ausgibt. dm_bow fängt diese Kürzungen ab und verwendet sie, um eine Liste mit kostenlosen Blöcken einzurichten. Lese- und Schreibvorgänge werden dann unverändert an das Gerät gesendet. Bevor ein Schreibvorgang jedoch erlaubt ist, werden die für eine 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 zu ermitteln, ob sich das Gerät im A/B-Status des Bootloaders befindet oder die Anzahl der Aktualisierungswiederholungen festgelegt wurde. Wenn eines dieser Kriterien erfüllt ist, ruft Android createCheckpoint auf, um entweder Bereitstellungsflags hinzuzufügen oder ein dm_bow-Gerät zu erstellen.
Nachdem die Partition bereitgestellt wurde, wird der Checkpoint-Code aufgerufen, um Trimmvorgänge auszuführen.
Der Bootvorgang wird dann wie gewohnt fortgesetzt. Bei LOCKED_BOOT_COMPLETE ruft Android commitCheckpoint auf, um den aktuellen Checkpoint zu bestätigen. Die Aktualisierung wird 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.
Gesundheit im Blick behalten
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.
Der Dienst „Dienststatus“ hat die folgenden Verhaltensweisen, die konfiguriert werden können:
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: Legt fest, ob der Dienst „Dienst für die Geräteintegrität“ das Gerät neu startet oder den Checkpoint festschreibt und fortfährt, wenn das Laufwerk voll ist.
Checkpoint-APIs
Prüfpunkt-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 checkpointte Dateisysteme wie userdata nach dem Neustart als beschreibbar 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 bereit für die Commit-Aktualisierung 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. Alle Änderungen an Nutzerdaten seit dem ersten Neustart werden verworfen.
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 Checkpoint-Geräten wird bei einem Start ohne Checkpoint true zurückgegeben.
UDC implementieren
Referenzimplementierung
Ein Beispiel für die Implementierung von UDC findest du unter dm-bow.c. Weitere Informationen zur Funktion findest du 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 in der Datei fstab.hardware /metadata 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 Checkpoint-Funktionen 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.