Android 10 introduit un point de contrôle des données utilisateur (UDC), qui
permet à Android de revenir à l'état précédent lorsqu'une connexion Over The Air
(OTA) échoue. Avec l'UDC, si une mise à jour OTA d'Android échoue, l'appareil peut
en toute sécurité
à son état précédent. Bien que
Les mises à jour A/B résolvent ce problème pour le démarrage anticipé, le rollback.
n'est pas disponible lorsque la partition de données utilisateur (installée sur /data
) est modifiée.
UDC permet à l'appareil de rétablir la partition de données utilisateur même après avoir été modifiées. La fonctionnalité UDC y parvient grâce à des fonctionnalités de point de contrôle système de fichiers, une autre implémentation lorsque le système de fichiers n'est pas compatible les points de contrôle, l'intégration au mécanisme A/B du bootloader et la compatibilité mises à jour non-A/B, et compatibilité avec la liaison de version de clé et le rollback de clé la prévention.
Impact sur l'utilisateur
La fonctionnalité UDC améliore l'expérience de mise à jour OTA pour les utilisateurs, car le nombre de pertes d'utilisateurs diminue. leurs données en cas d'échec d'une mise à jour OTA. Cela peut réduire le nombre d'appels à l'assistance des utilisateurs qui rencontrent des problèmes pendant le processus de mise à jour. Toutefois, lorsqu'une agence de voyages en ligne la mise à jour échoue, les utilisateurs peuvent remarquer que l’appareil redémarre plusieurs fois.
Fonctionnement
Fonctionnalité de point de contrôle dans différents systèmes de fichiers
Pour le système de fichiers F2FS, UDC ajoute la fonctionnalité de point de contrôle au flux en amont 4.20 Linux et le rétroporte sur tous les noyaux courants compatibles avec les appareils exécutant Android 10.
Pour les autres systèmes de fichiers, l'UDC utilise un appareil virtuel de mappage d'appareils appelé dm_bow
.
pour la fonctionnalité de point de contrôle. dm_bow
se trouve entre l'appareil et le fichier
du système d'exploitation. Lorsqu'une partition est installée,
un ajustement est émis, ce qui provoque
des commandes d'édition pour tous les blocs libres ; dm_bow
intercepte ces finitions et utilise
pour établir une liste
de blocage sans frais. Les lectures et les écritures sont ensuite envoyées à l'appareil
non modifiées, mais avant qu'une écriture ne soit autorisée, les données nécessaires à une restauration sont sauvegardées
jusqu'à un bloc sans frais.
Processus de point de contrôle
Lorsqu'une partition avec l'indicateur checkpoint=fs/block
est installée, Android appelle
restoreCheckpoint
sur le disque pour permettre à l'appareil de restaurer les données
un point de contrôle. init
appelle ensuite la fonction needsCheckpoint
pour déterminer si
L'appareil est à l'état A/B du bootloader ou a défini une nouvelle tentative de mise à jour.
nombre. Si l'une de ces valeurs est vraie, Android appelle createCheckpoint
pour ajouter l'installation
des options ou créer un appareil dm_bow
.
Une fois la partition installée, le code de point de contrôle est appelé pour émettre des modifications.
Le processus de démarrage se poursuit ensuite normalement. Chez LOCKED_BOOT_COMPLETE
, Android
appelle commitCheckpoint
pour valider le point de contrôle actuel et la mise à jour
se poursuit normalement.
Gérer les clés Keymaster
Les clés Keymaster sont utilisées pour le chiffrement des appareils ou à d'autres fins. Pour les gérer, , Android retarde les appels de suppression de touches jusqu'à ce que le point de contrôle soit validé.
Surveiller l'état
Un daemon de santé vérifie que l'espace disque est suffisant pour créer
un point de contrôle. Le daemon de santé se trouve dans
cp_healthDaemon
dans Checkpoint.cpp
.
Le daemon d'état a les comportements suivants qui peuvent être configurés:
ro.sys.cp_msleeptime
: Contrôle la fréquence à laquelle l'appareil vérifie l'utilisation du disque.ro.sys.cp_min_free_bytes
: Contrôle la valeur minimale recherchée par le daemon d'état.ro.sys.cp_commit_on_full
: Détermine si le daemon d'état redémarre l'appareil ou valide l'état et se poursuit lorsque le disque est saturé.
API Checkpoint
Les API de point de contrôle sont utilisées par la fonctionnalité UDC. Pour les autres API utilisées par l'UDC, consultez
IVold.aidl
vide startCheckpoint(valeur de nouvelle tentative)
Crée un point de contrôle.
Le framework appelle cette méthode lorsqu'il est prêt à lancer une mise à jour. La
le point de contrôle est créé avant que les systèmes de fichiers avec point de contrôle, tels que userdata ne soient
monté en lecture/écriture après le redémarrage. Si le nombre de nouvelles tentatives est positif, l'API traite
le suivi des nouvelles tentatives, et le programme de mise à jour appelle needsRollback
pour vérifier si un rollback
de la mise à jour est requise. Si le nombre de nouvelles tentatives est -1
, l'API s'en remet à l'étape A/B
de bootloader.
Cette méthode n'est pas appelée lors d'une mise à jour A/B normale.
vide commitChanges()
Valide les modifications.
Le framework appelle cette méthode après le redémarrage lorsque les modifications sont prêtes à être
s'engagent. Elle est appelée avant les données (images, vidéos, SMS, serveurs
reçu de réception) est écrite dans les données utilisateur et avant BootComplete
.
Si aucune mise à jour active avec point de contrôle n'existe, cette méthode n'a aucun effet.
annuler les modifications()
Force le redémarrage et revient au point de contrôle. Abandonne toutes les modifications des données utilisateur depuis le premier redémarrage.
Le framework appelle cette méthode après le redémarrage, mais avant commitChanges
.
retry_counter
est diminué lorsque cette méthode est appelée. Les entrées de journal sont
générées.
bool needRollback()
Détermine si un rollback est nécessaire.
Sur les appareils sans point de contrôle, renvoie false
. Sur les appareils de point de contrôle, renvoie true
lors d'un démarrage sans point de contrôle.
Implémenter l'UDC
Implémentation de référence
Pour obtenir un exemple d'implémentation d'une UDC, consultez dm-bow.c. Pour en savoir plus sur cette fonctionnalité, consultez dm-bow.txt
Configuration
Dans le fichier init.hardware.rc
de on fs
, vérifiez que vous avez:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --early
Dans le fichier init.hardware.rc
de on late-fs
, vérifiez que vous avez:
mount_all /vendor/etc/fstab.${ro.boot.hardware.platform} --late
Dans votre fichier fstab.hardware
, assurez-vous que /data
est associé au tag latemount
.
/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
Ajouter une partition de métadonnées
L'UDC nécessite une partition de métadonnées pour stocker le nombre de nouvelles tentatives du nonbootloader et
clés. Configurez une partition de métadonnées et installez-la de manière anticipée sur /metadata
.
Dans votre fichier fstab.hardware
, assurez-vous que /metadata
est associé au tag earlymount
ou first_stage_mount
.
/dev/block/by-name/metadata /metadata ext4 noatime,nosuid,nodev,discard,sync wait,formattable,first_stage_mount
Initialisez la partition à tous les zéros.
Ajoutez les lignes suivantes à BoardConfig.mk
:
BOARD_USES_METADATA_PARTITION := true BOARD_ROOT_EXTRA_FOLDERS := existing_folders metadata
Mettre à jour les systèmes
Systèmes F2FS
Pour les systèmes qui utilisent F2FS pour formater les données, assurez-vous que votre version de F2FS prend en charge les points de contrôle. Pour en savoir plus, consultez la section Fonctionnalité de point de contrôle dans différents systèmes de fichiers.
Ajoutez l'option checkpoint=fs
à la section <fs_mgr_flags>
de fstab pour la
appareil installé à /data
.
Systèmes autres que F2FS
Pour les systèmes autres que F2FS, dm-bow
doit être activé dans la configuration du noyau.
Ajoutez l'option checkpoint=block
à la section <fs_mgr_flags>
de fstab pour la
appareil installé à /data
.
Vérifier les journaux
Les entrées de journal sont générées lorsque les API Checkpoint sont appelées.
Validation
Pour tester votre implémentation UDC, exécutez l'ensemble VtsKernelCheckpointTest
de VTS
tests.