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 appelantPowerManager.reboot(PowerManager.REBOOT_USERSPACE)
À partir du shell, en utilisant
adb shell svc power reboot userspace
ouadb 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
dansrootdir/init.rc
.-
Exécute la fonction
DoUserspaceReboot
, qui effectue les actions suivantes :- Envoie
SIGTERM
aux processus démarrés après le montageuserdata
et attend qu'ils s'arrêtent. - Une fois le délai d'attente atteint, envoie
SIGKILL
pour arrêter tous les processus en cours. - Appelle
/system/bin/vdc volume reset
. - Démonte le périphérique de support zRAM.
- Démonte les packages APEX actifs.
- Revient à l'espace de noms de montage d'amorçage.
- Déclenche l’action
userspace-reboot-resume
.
- Envoie
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'optioncheckpoint=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é estfalse
,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 signalSIGKILL
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 signalSIGTERM
pour se terminer. Tous les processus qui n'ont pas réussi à se terminer dans le délai imparti reçoivent un signalSIGKILL
. -
init.userspace_reboot.started.timeoutmillis
contrôle le délai d'attente en millisecondes pour le démarrage du redémarrage logiciel (c'est-à-diresys.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émonteruserdata
. Si un appareil ne parvient pas à démonteruserdata
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-à-diresys.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
.