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 einer UDC ein Android-OTA-Update fehlschlägt, kann das Gerät
auf den vorherigen Zustand zurücksetzen. Obwohl
A/B-Updates lösen dieses Problem für frühe Starts, Rollbacks
wird nicht unterstützt, wenn die Nutzerdatenpartition (bereitgestellt auf /data) geändert wird.
UDC ermöglicht es dem Gerät, die Partition der Nutzerdaten auch nach der geändert. Die UDC-Funktion erreicht dies mit Prüfpunktfunktionen zur Dateisystem, eine alternative Implementierung, wenn das Dateisystem Checkpoints, Integration mit dem Bootloader-A/B-Mechanismus und Nicht-A/B-Updates und Unterstützung für Schlüsselversionsbindung und Schlüssel-Rollback Prävention.
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 jedoch ein Onlinereisebüro ein Update fehlschlägt, kann es vorkommen, dass Nutzer feststellen, dass das Gerät mehrmals neu startet.
Funktionsweise
Prüfpunktfunktion in verschiedenen Dateisystemen
Beim F2FS-Dateisystem fügt UDC dem Upstream 4.20 Linux-Kernel und Backporting an alle gängigen Kernels, die von Geräten unterstützt werden mit Android 10.
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. Beim Bereitstellen einer Partition wird ein Trim ausgegeben, wodurch das Dateisystem
geben Sie Befehle zum Zuschneiden
für alle kostenlosen Blöcke aus. dm_bow fängt diese Schnitte und Verwendungen ab
um eine Sperrliste zu erstellen. Lese- und Schreibzugriffe werden dann an das Gerät gesendet.
unverändert, aber bevor ein Schreibvorgang erlaubt wird, werden für eine Wiederherstellung benötigte Daten gesichert.
bis zu einem kostenlosen Block.
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
Checkpoint. 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 einer der beiden Werte „true“ ist, ruft Android createCheckpoint auf, um die Bereitstellung hinzuzufügen
Flags erstellen oder ein dm_bow-Gerät 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, Android
ruft commitCheckpoint auf, um den aktuellen Prüfpunkt und das Update zu übergeben.
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.
Gesundheitszustand überwachen
Ein System-Daemon prüft, ob genügend Speicherplatz vorhanden ist, um eine
Checkpoint. Der System-Daemon befindet sich
cp_healthDaemon
in Checkpoint.cpp
Die folgenden Verhaltensweisen des System-Daemons können konfiguriert werden:
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 System-Daemon sucht.ro.sys.cp_commit_on_full: Steuert, ob der System-Daemon das Gerät neu startet oder den Commit und wird fortgesetzt, wenn der Datenträger voll ist.
Checkpoint-APIs
Checkpoint APIs werden von der UDC-Funktion verwendet. Informationen zu anderen von UDC verwendeten APIs finden Sie unter
IVold.aidl
void startCheckpoint(int wieder)
Erstellt einen Prüfpunkt.
Das Framework ruft diese Methode auf, wenn ein Update gestartet werden kann. Die
Prüfpunkt wird erstellt, bevor Prüfpunkt-Dateisysteme wie Nutzerdaten erstellt werden.
R/W nach dem Neustart bereitgestellt. 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, berücksichtigt 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 (z. B. Bilder, Videos, SMS, Serverdaten)
Empfangsbestätigung) wird in Nutzerdaten und vor BootComplete geschrieben.
Wenn kein aktives Update mit einem Prüfpunkt vorhanden ist, hat diese Methode keine Auswirkungen.
abbrechenChanges()
Erzwingt einen Neustart und kehrt zum Prüfpunkt 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 beim Aufruf dieser Methode verringert. Logeinträge sind
generiert.
bool erfordertRollback()
Bestimmt, ob ein Rollback erforderlich ist.
Auf Geräten ohne Prüfpunkt wird false zurückgegeben. Auf Checkpoint-Geräten wird true zurückgegeben
während eines Non-Checkpoint-Starts.
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 on fs in Ihrer init.hardware.rc-Datei Folgendes vorhanden 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
Stellen Sie bei Systemen, die F2FS zur Datenformatierung verwenden, sicher, dass Ihre Version von F2FS unterstützt Prüfpunkte. Weitere Informationen finden Sie unter Prüfpunktfunktion in verschiedene Dateisysteme.
Fügen Sie dem Abschnitt <fs_mgr_flags> von fstab das Flag checkpoint=fs für die
Gerät unter /data bereitgestellt.
Nicht-F2FS-Systeme
Für Nicht-F2FS-Systeme muss dm-bow in der Kernel-Konfiguration aktiviert sein.
Fügen Sie dem Abschnitt <fs_mgr_flags> von fstab das Flag checkpoint=block für die
Gerät unter /data bereitgestellt.
Logs prüfen
Logeinträge werden beim Aufrufen von Checkpoint APIs generiert.
Zertifizierungsstufe
Führen Sie den VTS-Satz VtsKernelCheckpointTest aus, um die UDC-Implementierung zu testen
Tests durchführen.