À 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)
Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Android 11 prend en charge 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 nécessitant un redémarrage (par exemple, les mises à jour des packages APEX). Actuellement, le redémarrage logiciel est limité aux processus qui ont démarré après le montage de userdata.

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

À partir de 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 logiciels, les appels à PowerManager.reboot(PowerManager.REBOOT_USERSPACE), adb reboot userspace et adb shell svc power reboot userspace échouent.

Exécution du redémarrage silencieux

Une fois qu'un redémarrage en douceur est demandé (via PowerManager ou à partir d'un shell), 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 le montage de userdata et attend qu'ils s'arrêtent.
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. Repasse à l'espace de noms d'installation de démarrage.
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.

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 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 est compatible avec:

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é pour le démarrage normal du 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 clés, 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.

Passer au redémarrage forcé

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ésinstallation de l'appareil zRAM échoue.
Un package APEX actif est mal démonté.
Toute tentative de remise en place de userdata en mode de point de contrôle échoue.
L'appareil ne démarre pas (sys.boot_completed=1) dans un délai donné.

Configuration par appareil

Certains aspects du redémarrage logiciel peuvent être affiné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 non 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 spécifié, un redémarrage forcé est déclenché.
init.userspace_reboot.sigterm.timeoutmillis contrôle le délai avant expiration (en millisecondes) pour les processus qui ont reçu un signal SIGTERM pour s'arrêter. Tous les processus qui n'ont pas pu s'arrêter dans le délai spécifié 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 logiciel

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

À 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 logiciel. De plus, vous pouvez vérifier un redémarrage logiciel à l'aide de tests CTS dans UserspaceRebootHostTest.