À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.

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

Redémarrages silencieux (<= AOSP 14)

Android 11 est compatible avec les redémarrages logiciels, qui sont des redémarrages d'exécution des processus dans l'espace utilisateur utilisés pour appliquer les mises à jour qui nécessitent un redémarrage (par exemple, les mises à jour des packages APEX). Actuellement, le redémarrage progressif est limité aux processus qui ont démarré après le montage de userdata.

Un redémarrage logiciel est demandé de l'une des manières suivantes :

À partir du PowerManager, en appelant le PowerManager.reboot(PowerManager.REBOOT_USERSPACE)
Depuis le 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 d'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 logiciels, les appels à PowerManager.reboot(PowerManager.REBOOT_USERSPACE), adb reboot userspace et adb shell svc power reboot userspace échouent.

Redémarrer l'exécution

Lorsqu'un redémarrage progressif est demandé (via PowerManager ou à partir d'un shell), init effectue les étapes suivantes :

Reçoit sys.powerctl=reboot,userspace.
Crée un processus UserspaceRebootWatchdogThread() distinct pour surveiller le redémarrage progressif.
Déclenche une action userspace-reboot-requested, qui réinitialise toutes les propriétés système susceptibles d'avoir un impact sur 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 à nouveau définies 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 le montage 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émonte le périphérique de stockage zRAM.
5. Démonte les packages APEX actifs.
6. Repasse à l'espace de noms de montage d'amorçage.
7. Déclenche l'action userspace-reboot-resume.

Si la création de points de contrôle du système de fichiers a été demandée avant le redémarrage logiciel, userdata est remonté en mode point de contrôle lors de l'action userspace-reboot-fs-remount (voir la section suivante pour plus d'informations). Un redémarrage logiciel est considéré comme effectué une fois que sys.boot_completed property est défini sur 1. À la fin du redémarrage logiciel, l'écran reste éteint et une interaction explicite de l'utilisateur est requise 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 en douceur, userdata est remonté en mode 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 checkpointing. Plus précisément, lorsque userdata est compatible avec :

La création de points de contrôle au niveau du système de fichiers (par exemple, f2fs), userdata est remontée 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 mappeur de périphériques parents sur lesquels il était monté sont détruits. Ensuite, userdata est monté en utilisant le même chemin de code que celui utilisé lors du démarrage normal de la création de points de contrôle.

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

Revenir à un redémarrage forcé

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

Un appareil ne parvient pas à effectuer un redémarrage logiciel (c'est-à-dire sys.init.userspace_reboot.in_progress=1) dans un délai donné.
Un processus ne s'arrête pas dans le délai imparti.
L'opération /system/bin/vdc volume reset échoue.
Le démontage du périphérique zRAM échoue.
Un package APEX actif est démonté de manière incorrecte.
Une tentative de remontage de userdata en mode de point de contrôle échoue.
Un appareil ne parvient pas à démarrer correctement (c'est-à-dire sys.boot_completed=1) dans un délai donné.

Configuration par appareil

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

init.userspace_reboot.is_supported contrôle le moment où un appareil peut effectuer un redémarrage logiciel. 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 imparti, un redémarrage forcé est déclenché.
init.userspace_reboot.sigterm.timeoutmillis contrôle le délai d'expiration en millisecondes pour les processus qui ont reçu un signal SIGTERM pour se terminer. Tous les processus qui n'ont pas pu s'arrêter dans le délai imparti reçoivent un signal SIGKILL.
init.userspace_reboot.started.timeoutmillis contrôle le délai d'attente en millisecondes avant le démarrage du redémarrage progressif (c'est-à-dire sys.init.userspace_reboot.in_progress=1). Si un appareil ne parvient pas à démarrer le redémarrage progressif dans le délai imparti, un retour au redémarrage forcé est déclenché.
init.userspace_reboot.userdata_remount.timeoutmillis contrôle le délai d'expiration en millisecondes pour démonter userdata. Si un appareil ne parvient pas à se démonter userdata dans le délai imparti, un redémarrage forcé est déclenché.
init.userspace_reboot.watchdog.timeoutmillis contrôle le délai d'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 imparti, un retour au redémarrage forcé est déclenché.

Personnaliser l'animation lors d'un redémarrage logiciel

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

À 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.

Tests

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