Android 11 prend en charge les redémarrages réversibles, qui sont
redémarrages pendant l'exécution des processus dans l'espace utilisateur utilisés pour appliquer les mises à jour
nécessitent un redémarrage (par exemple, les mises à jour des packages APEX). Actuellement,
redémarrer est limité aux processus qui ont démarré après l'installation de userdata
.
Un redémarrage à chaud est demandé de différentes manières:
Depuis
PowerManager
, en appelantPowerManager.reboot(PowerManager.REBOOT_USERSPACE)
Depuis l'interface système, à l'aide de
adb shell svc power reboot userspace
ouadb reboot userspace
Après un redémarrage progressif, le stockage chiffré par identifiants reste déverrouillé.
Si un appareil est compatible avec 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 égal à 1
.
Si l'appareil n'est pas compatible avec les redémarrages à la demande, les appels au
Échec de PowerManager.reboot(PowerManager.REBOOT_USERSPACE)
, adb reboot
userspace
et adb shell svc power reboot userspace
.
Exécuter un redémarrage progressif
Après la demande de redémarrage progressif (via PowerManager
ou une interface système),
init
effectue les étapes suivantes:
Reçoit
sys.powerctl=reboot,userspace
.Duplique un
UserspaceRebootWatchdogThread()
pour surveiller le redémarrage progressif.Déclenche une action
userspace-reboot-requested
, qui réinitialise tout le système qui peuvent affecter le redémarrage progressif. 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 définies à nouveau lors de la séquence de démarrage. Si nécessaire, vous pouvez peut réinitialiser des propriétés supplémentaires. Pour obtenir des exemples, consultez les
on userspace-reboot-requested
action dansrootdir/init.rc
Exécute la
DoUserspaceReboot
, qui effectue les actions suivantes:- Envoie
SIGTERM
aux processus démarrés après l'installation deuserdata
et attend qu'il s'arrête. - Une fois le délai d'inactivité atteint, envoie
SIGKILL
pour arrêter toute activité en cours d'exécution. processus. - Appel du
/system/bin/vdc volume reset
- Désinstalle l'appareil de sauvegarde de la zRAM.
- Désinstalle les packages APEX actifs.
- Permet de revenir à l'espace de noms du montage d'amorçage.
- Déclenche le
userspace-reboot-resume
action.
- Envoie
Si la création de points de contrôle du système
de fichiers a été demandée avant le redémarrage à chaud,
userdata
est réinstallé en mode point de contrôle pendant la
userspace-reboot-fs-remount
(pour en savoir plus, consultez la section suivante). A
Le redémarrage réversible est envisagé une fois que sys.boot_completed property
est défini.
à 1
. À la fin du redémarrage logiciel, l'écran reste éteint et
une interaction explicite de l'utilisateur est nécessaire pour le réactiver.
Création de points 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 à chaud,
userdata
est réinstallé en mode point de contrôle lors du redémarrage progressif.
La logique de réinstallation est implémentée dans
fs_mgr_remount_userdata_into_checkpointing
et diffère selon les méthodes de création de points de contrôle. Plus précisément,
userdata
est compatible avec:
Point de contrôle au niveau du système de fichiers (par exemple,
f2fs
),userdata
est réinstallé avec l'optioncheckpoint=disable
.Point de contrôle au niveau du bloc (par exemple,
ext4
), puis/data
est désinstallé et tous les appareils parents sur lesquels il était installé sont détruit. Ensuite,userdata
est installé à l'aide du même chemin de code que celui utilisé dans un démarrage de point de contrôle normal.
Si un trousseau de clés au niveau du système de fichiers est utilisé pour gérer les certificats chiffrés
les clés chiffrées de l'appareil (DE), les clés sont perdues après la désinstallation de userdata
. À
autoriser la restauration de clés lors de l'installation d'une clé dans un trousseau de systèmes de fichiers, vold
installe également la même clé de type fscrypt-provisioning
au niveau de la session
à l'aide d'un trousseau. Lorsque init_user0
est appelé, vold
réinstalle les clés du fichier.
le trousseau système.
Créer un remplacement en cas de redémarrage matériel
Pour éviter qu'un appareil ne laisse un appareil dans un état inutilisable lors d'un redémarrage progressif, Android 11 inclut une solution de secours au redémarrage matériel qui est déclenchée lorsque l'une des conditions suivantes est remplie:
- Un appareil ne démarre pas le redémarrage progressif
sys.init.userspace_reboot.in_progress=1
) dans un délai donné. - Un processus ne s'arrête pas dans un délai donné.
- L'opération
/system/bin/vdc volume reset
échoue. - Le démontage de l'appareil zRAM échoue.
- Un package APEX actif ne se désinstalle pas correctement.
- Une tentative de réinstallation de
userdata
en mode point de contrôle échoue. - Un appareil ne parvient pas à démarrer (c'est-à-dire
sys.boot_completed=1
) dans un délai délai avant expiration donné.
Configuration par appareil
Certains aspects du redémarrage progressif peuvent être réglés en modifiant les valeurs des éléments suivants : propriétés:
init.userspace_reboot.is_supported
contrôle quand un appareil peut effectuer une un redémarrage progressif. Si la valeur de cette propriété estfalse
,0
ou n'est pas spécifiée, les tentatives de redémarrage sont refusées.init.userspace_reboot.sigkill.timeoutmillis
contrôle le délai avant expiration dans millisecondes pour les processus qui ont reçu un signalSIGKILL
de s'arrêter. Si l'une des valeurs suivantes les processus ne s'arrêtent pas dans le délai imparti, alors un recours ou un redémarrage automatique.init.userspace_reboot.sigterm.timeoutmillis
contrôle le délai avant expiration dans millisecondes pour les processus qui ont reçu un signalSIGTERM
de se terminer. Tout les processus qui n'ont pas pu s'arrêter dans le délai imparti reçoivent une SignalSIGKILL
.init.userspace_reboot.started.timeoutmillis
contrôle le délai avant expiration dans de millisecondes pour le démarrage progressifsys.init.userspace_reboot.in_progress=1
). Si un appareil ne démarre pas en douceur redémarrer 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 avant expiration dans millisecondes pour désinstalleruserdata
. Si un appareil ne parvient pas à désinstalleruserdata
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 avant expiration d'une pour démarrer correctement (c'est-à-diresys.boot_completed=1
). Si un appareil ne démarre pas dans le délai imparti, une utilisation en remplacement d'un redémarrage matériel déclenchée.
Personnaliser l'animation lors du redémarrage progressif
L'implémentation de référence d'un redémarrage progressif permet de personnaliser s'affiche pendant le redémarrage progressif.
À la fin de l'action userspace-reboot-fs-remount
, init
démarre
Service bootanim
. Ce service vérifie l'existence des éléments suivants :
d'animation, dans l'ordre indiqué, et lance la lecture du 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 à chaud n'est spécifié, bootanim
affiche une
l'animation android
par défaut.
Tests
Android 11 inclut une implémentation de référence d'un
un redémarrage progressif. Vous pouvez également vérifier un redémarrage progressif à l'aide de CTS.
tests dans
UserspaceRebootHostTest