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

Redémarrages réversibles (<= AOSP 14)

Android 11 est compatible avec les redémarrages réversibles, qui sont les redémarrages pendant l'exécution des processus de l'espace utilisateur permettant d'appliquer des mises à jour nécessitant un redémarrage (par exemple, des mises à jour de packages APEX). Actuellement, le redémarrage progressif est limité aux processus démarrés après l'installation de userdata.

Un redémarrage logiciel est demandé de la manière suivante:

Depuis PowerManager, en appelant PowerManager.reboot(PowerManager.REBOOT_USERSPACE)
Depuis l'interface shell, à l'aide de adb shell svc power reboot userspace ou adb reboot userspace

Après un redémarrage logiciel, le stockage chiffré par identifiants reste déverrouillé.

Si un appareil est compatible avec les redémarrages logiciels, 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 n'est pas compatible avec les redémarrages réversibles, les appels à PowerManager.reboot(PowerManager.REBOOT_USERSPACE), adb reboot userspace et adb shell svc power reboot userspace échouent.

Exécuter un redémarrage progressif

Une fois qu'un redémarrage progressif est demandé (via PowerManager ou à partir d'une interface système), init effectue les étapes suivantes:

Réçoit sys.powerctl=reboot,userspace.
Forque 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 système susceptibles d'affecter 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 définies à nouveau lors de la séquence de démarrage. Si nécessaire, vous pouvez réinitialiser d'autres propriétés. Pour obtenir des exemples, consultez 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 l'installation de userdata et attend leur arrêt.
2. Une fois le délai écoulé, envoie SIGKILL pour arrêter tous les processus en cours d'exécution.
3. Il appelle /system/bin/vdc volume reset.
4. Désinstalle l'appareil de sauvegarde zRAM.
5. Démonte les packages APEX actifs.
6. Permet de revenir à l'espace de noms du 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 est réinstallé en mode point de contrôle lors de l'action userspace-reboot-fs-remount (pour en savoir plus, consultez la section suivante). Un redémarrage en douceur est considéré après que sys.boot_completed property a été défini sur 1. À la fin du redémarrage logiciel, l'écran reste éteint et une interaction explicite de l'utilisateur est requise pour l'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 en douceur, userdata est réinstallé en mode de point de contrôle lors du redémarrage en douceur. 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 accepte:

Création de points 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émonté et tous les mappeurs d'appareils parents sur lesquels il était installé sont détruits. Ensuite, userdata est installé à l'aide du même chemin de code que celui utilisé dans le démarrage normal de point de contrôle.

Si un trousseau de clés au niveau du système de fichiers est utilisé pour gérer les clés chiffrées par identifiants (CE) et les clés chiffrées par appareil (DE), les clés sont perdues après le démontage de userdata. Pour permettre la restauration de la clé, lorsque vous installez une clé dans un trousseau de clés de 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.

Créer un remplacement en cas de redémarrage matériel

Pour s'assurer qu'un redémarrage logiciel ne laisse pas un appareil dans un état inutilisable, Android 11 inclut un retour au redémarrage forcé déclenché lorsque l'une des conditions suivantes est remplie:

Un appareil ne parvient pas à démarrer le redémarrage logiciel (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 est mal démonté.
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 donné.

Configuration par appareil

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

init.userspace_reboot.is_supported contrôle à quel moment un appareil peut effectuer 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 en millisecondes pour les processus qui ont reçu un signal SIGKILL pour s'arrêter. Si l'un des processus ne s'arrête pas dans le délai d'inactivité donné, un retour au redémarrage matériel est déclenché.
init.userspace_reboot.sigterm.timeoutmillis contrôle le délai avant expiration, en millisecondes, des processus ayant reçu un signal SIGTERM d'arrêt. 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'inactivité en millisecondes pour le démarrage du redémarrage logiciel (c'est-à-dire sys.init.userspace_reboot.in_progress=1). Si un appareil ne parvient pas à démarrer le redémarrage logiciel dans le délai d'inactivité donné, un redémarrage forcé est déclenché.
init.userspace_reboot.userdata_remount.timeoutmillis contrôle le délai avant expiration (en millisecondes) pour démonter userdata. Si un appareil ne parvient pas à démonter userdata dans le délai d'inactivité donné, un redémarrage forcé est déclenché.
init.userspace_reboot.watchdog.timeoutmillis contrôle le délai avant expiration pour qu'un appareil démarre correctement (c'est-à-dire sys.boot_completed=1). Si un appareil ne parvient pas à démarrer dans le délai donné, un redémarrage forcé est déclenché.

Personnaliser l'animation lors du redémarrage progressif

L'implémentation de référence d'un redémarrage logiciel inclut la possibilité de personnaliser l'animation affichée pendant ce redémarrage.

À 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

suivant.

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

Tests

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