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

Redémarrages réversibles

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 appelant PowerManager.reboot(PowerManager.REBOOT_USERSPACE)
Depuis l'interface système, à l'aide de adb shell svc power reboot userspace ou adb 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 dans rootdir/init.rc
Exécute la DoUserspaceReboot , qui effectue les actions suivantes:
1. Envoie SIGTERM aux processus démarrés après l'installation de userdata et attend qu'il s'arrête.
2. Une fois le délai d'inactivité atteint, envoie SIGKILL pour arrêter toute activité en cours d'exécution. processus.
3. Appel du /system/bin/vdc volume reset
4. Désinstalle l'appareil de sauvegarde de la zRAM.
5. Désinstalle les packages APEX actifs.
6. Permet de revenir à l'espace de noms du montage d'amorçage.
7. Déclenche le userspace-reboot-resume action.

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'option checkpoint=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é est false, 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 signal SIGKILL 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 signal SIGTERM de se terminer. Tout les processus qui n'ont pas pu s'arrêter dans le délai imparti reçoivent une Signal SIGKILL.
init.userspace_reboot.started.timeoutmillis contrôle le délai avant expiration dans de millisecondes pour le démarrage progressif sys.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ésinstaller userdata. Si un appareil ne parvient pas à désinstaller 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 avant expiration d'une pour démarrer correctement (c'est-à-dire sys.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