Mit Android 10 führen wir User Data Checkpoint (UDC) ein,
ermöglicht es Android, auf den vorherigen Zustand zurückzusetzen, wenn ein Android over-the-air
(OTA)-Update schlägt fehl. 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.
UDC ermöglicht es dem Gerät, die Partition der Nutzerdaten auch nach der geändert. 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 die OTA-Aktualisierung für Nutzer, da weniger Nutzer verlieren wenn bei einem OTA-Update ein Fehler auftritt. Dadurch kann die Anzahl der Supportanrufe reduziert werden von Nutzern, bei denen während des Update-Vorgangs 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
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 Device Mapper-Gerät namens dm_bow
für die Prüfpunktfunktionalität. dm_bow befindet sich zwischen dem Gerät und der Datei
System. 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 kostenlose Blockliste 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 freien Block gesichert.
Prüfpunktprozess
Wenn eine Partition mit dem Flag checkpoint=fs/block bereitgestellt wird, ruft Android
restoreCheckpoint auf dem Laufwerk, damit das Gerät den aktuellen
Prüfpunkt festlegen. init ruft dann die Funktion needsCheckpoint auf, um festzustellen,
Das Gerät befindet sich entweder im Bootloader-A/B-Status oder hat den Aktualisierungsversuch festgelegt.
Anzahl. 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 zur Geräteverschlüsselung und für andere Zwecke verwendet. So verwalten Sie diese Schlüssel gelöscht, verzögert Android Schlüssellöschaufrufe, bis der Prüfpunkt festgeschrieben ist.
Gesundheit im Blick behalten
Ein Dienst zur Systemüberwachung prüft, ob genügend Speicherplatz vorhanden ist, um einen Checkpoint zu erstellen. Der System-Daemon befindet sich
cp_healthDaemon
in Checkpoint.cpp
Der Dienst „Dienststatus“ hat die folgenden Verhaltensweisen, die konfiguriert werden können:
ro.sys.cp_msleeptime: Steuert, wie oft das Gerät die Laufwerksnutzung überprü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 „healthd“ das Gerät neu startet oder den Checkpoint festschreibt und fortfährt, 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 wieder)
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. Ist die Anzahl der Wiederholungen positiv, verarbeitet die API
und der Updater ruft needsRollback auf, um zu prüfen,
des Updates erforderlich ist. Wenn die Anzahl der Wiederholungen -1 ist, verschiebt die API den A/B-Wert
das Urteil des Bootloaders.
Bei einem normalen A/B-Update wird diese Methode nicht aufgerufen.
void commitChanges()
Übernimmt die Änderungen.
Das Framework ruft diese Methode nach dem Neustart auf, wenn die Änderungen bereit sind.
verpflichtet. Dies wird vor Daten (wie Bilder, Video, SMS, Serverdaten)
Empfangsbestätigung) wird in Nutzerdaten und vor BootComplete geschrieben.
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 neededRollback()
Bestimmt, ob ein Rollback erforderlich ist.
Auf Geräten ohne Checkpoint wird false zurückgegeben. Auf Checkpoint-Geräten wird true zurückgegeben
während eines Nicht-Checkpoint-Starts.
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 on late-fs in Ihrer init.hardware.rc-Datei Folgendes vorhanden ist:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late
Achten Sie darauf, dass /data in der Datei fstab.hardware 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 Nicht-Bootloader-Wiederholungen zu speichern.
Schlüssel. 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 getaggt ist
oder first_stage_mount.
/dev/block/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard,sync wait,formattable,first_stage_mount
Initialisieren Sie die Partition auf alle Nullen.
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 beim Aufrufen von Checkpoint APIs generiert.
Zertifizierungsstufe
Führen Sie zum Testen Ihrer UDC-Implementierung die VtsKernelCheckpointTest VTS-Tests aus.