Cette page a été traduite par l'API Cloud Translation.

Redémarrages en douceur

Android 11 prend en charge les redémarrages progressifs, qui sont des redémarrages d'exécution de processus dans l'espace utilisateur utilisés pour appliquer les mises à jour nécessitant un redémarrage (par exemple, les mises à jour des packages APEX). Actuellement, le redémarrage logiciel est limité aux processus démarrés après le montage userdata .

Un redémarrage progressif est demandé des manières suivantes :

Depuis PowerManager , en appelant PowerManager.reboot(PowerManager.REBOOT_USERSPACE)
À partir du shell, en utilisant adb shell svc power reboot userspace ou adb reboot userspace

Après un redémarrage logiciel, le stockage crypté des informations d'identification reste déverrouillé.

Si un périphérique prend en charge les redémarrages progressifs, la méthode API PowerManager.isRebootingUserspace() renvoie true et la valeur de la propriété système init.userspace_reboot.is_supported est égale à 1 .

Si l'appareil ne prend pas en charge les redémarrages progressifs, les appels à PowerManager.reboot(PowerManager.REBOOT_USERSPACE) , adb reboot userspace et adb shell svc power reboot userspace échouent.

Exécution du redémarrage progressif

Après qu'un redémarrage logiciel soit demandé (via PowerManager ou depuis un shell), init effectue les étapes suivantes :

Reçoit sys.powerctl=reboot,userspace .
Crée un processus UserspaceRebootWatchdogThread() distinct pour surveiller le redémarrage logiciel.
Déclenche une action userspace-reboot-requested , qui réinitialise toutes les propriétés du système susceptibles d'avoir un impact sur le redémarrage logiciel. Propriétés concernées :
- sys.usb.config
- sys.usb.state
- sys.boot_completed
- dev.bootcomplete
- sys.init.updatable_crashing
- sys.init.updatable_crashing_process_name
- apexd.status
- sys.user.0.ce_available
- sys.shutdown.requested
- service.bootanim.exit
Les propriétés ci-dessus doivent être à nouveau définies lors de la séquence de démarrage. Si nécessaire, vous pouvez réinitialiser des propriétés supplémentaires. Pour des exemples, reportez-vous à l'action on userspace-reboot-requested dans rootdir/init.rc .
Exécute la fonction DoUserspaceReboot , qui effectue les actions suivantes :
1. Envoie SIGTERM aux processus démarrés après le montage userdata et attend qu'ils s'arrêtent.
2. Une fois le délai d'attente atteint, envoie SIGKILL pour arrêter tous les processus en cours.
3. Appelle /system/bin/vdc volume reset .
4. Démonte le périphérique de support zRAM.
5. Démonte les packages APEX actifs.
6. Revient à l'espace de noms de montage d'amorçage.
7. Déclenche l’action userspace-reboot-resume .

Si le point de contrôle du système de fichiers a été demandé avant le redémarrage logiciel, userdata sont remontées en mode de point de contrôle lors de l'action userspace-reboot-fs-remount (voir la section suivante pour plus de détails). Un redémarrage logiciel est envisagé une fois que la sys.boot_completed property est définie sur 1 . À la fin du redémarrage progressif, l'écran reste éteint et une interaction explicite de l'utilisateur est nécessaire pour le réactiver.

Point de contrôle du système de fichiers

Si un point de contrôle du système de fichiers a été demandé avant le redémarrage logiciel, userdata sont remontées en mode point de contrôle lors du redémarrage logiciel. La logique de remontage est implémentée dans la fonction fs_mgr_remount_userdata_into_checkpointing et diffère selon les méthodes de point de contrôle. Plus précisément, lorsque userdata prennent en charge :

Point de contrôle au niveau du système de fichiers (par exemple, f2fs ), userdata sont remontées avec l'option checkpoint=disable .
Point de contrôle au niveau du bloc (par exemple, ext4 ), puis /data est démonté et tous les périphériques de mappage de périphérique parent sur lesquels il a été monté sont détruits. Ensuite, userdata sont montées en utilisant le même chemin de code que celui utilisé lors du démarrage normal par points de contrôle.

Si un jeu de clés au niveau du système de fichiers est utilisé pour gérer les clés chiffrées par informations d'identification (CE) et chiffrées par périphérique (DE), les clés sont perdues une fois userdata démontées. Pour permettre la restauration de clé, lors de l'installation d'une clé dans un trousseau de clés du système de fichiers, vold installe également la même clé de type fscrypt-provisioning dans le trousseau de clés au niveau de la session. Lorsque init_user0 est appelé, vold réinstalle les clés dans le trousseau de clés du système de fichiers.

Revenir au redémarrage dur

Pour garantir qu'un redémarrage progressif ne laisse pas un appareil dans un état inutilisable, Android 11 inclut une solution de secours vers un redémarrage matériel qui se déclenche lorsque l'une des conditions suivantes est remplie :

Un périphérique ne parvient pas à démarrer le redémarrage logiciel (c'est-à-dire sys.init.userspace_reboot.in_progress=1 ) dans un délai d'attente donné.
Un processus ne parvient pas à s'arrêter dans un délai d'attente donné.
L’opération /system/bin/vdc volume reset échoue.
Le démontage du périphérique zRAM échoue.
Un package APEX actif ne se démonte pas correctement.
Une tentative de remonter userdata en mode de point de contrôle échoue.
Un périphérique ne parvient pas à démarrer correctement (c'est-à-dire sys.boot_completed=1 ) dans un délai d'expiration donné.

Configuration par appareil

Certains aspects du redémarrage progressif peuvent être ajustés en modifiant les valeurs des propriétés suivantes :

init.userspace_reboot.is_supported contrôle le moment où un périphérique peut effectuer un redémarrage progressif. Si la valeur de cette propriété est false , 0 ou non spécifiée, les tentatives de redémarrage sont rejetées.
init.userspace_reboot.sigkill.timeoutmillis contrôle le délai d'attente en millisecondes pour les processus qui ont reçu un signal SIGKILL pour s'arrêter. Si l'un des processus ne parvient pas à s'arrêter dans le délai imparti, un retour au redémarrage matériel est déclenché.
init.userspace_reboot.sigterm.timeoutmillis contrôle le délai d'attente en millisecondes pour les processus qui ont reçu un signal SIGTERM pour se terminer. Tous les processus qui n'ont pas réussi à se terminer dans le délai imparti reçoivent un signal SIGKILL .
init.userspace_reboot.started.timeoutmillis contrôle le délai d'attente en millisecondes pour le démarrage du redémarrage logiciel (c'est-à-dire sys.init.userspace_reboot.in_progress=1 ). Si un périphérique ne parvient pas à démarrer le redémarrage logiciel dans le délai imparti, un retour au redémarrage matériel est déclenché.
init.userspace_reboot.userdata_remount.timeoutmillis contrôle le délai d'attente en millisecondes pour démonter userdata . Si un appareil ne parvient pas à démonter userdata dans le délai imparti, un retour au redémarrage matériel est déclenché.
init.userspace_reboot.watchdog.timeoutmillis contrôle le délai d'attente nécessaire au démarrage réussi d'un périphérique (c'est-à-dire sys.boot_completed=1 ). Si un périphérique ne parvient pas à démarrer dans le délai imparti, un retour au redémarrage matériel est déclenché.

Personnaliser l'animation lors du redémarrage logiciel

L'implémentation de référence d'un redémarrage progressif inclut la possibilité de personnaliser l'animation affichée lors du redémarrage progressif.

A la fin de l'action userspace-reboot-fs-remount , init démarre le service bootanim . Ce service recherche l'existence des fichiers d'animation suivants, dans l'ordre indiqué, et lit le premier qu'il trouve :

/product/media/userspace-reboot.zip
/oem/media/userspace-reboot.zip
/system/media/userspace-reboot.zip

Si aucun fichier d'animation spécifique au redémarrage logiciel n'est spécifié, bootanim affiche une animation android par défaut.

Essai

Android 11 inclut une implémentation de référence d'un redémarrage progressif. De plus, vous pouvez vérifier un redémarrage logiciel à l'aide des tests CTS dans UserspaceRebootHostTest .