Redémarrages silencieux (<= AOSP 14)

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

Un redémarrage silencieux est demandé de différentes manières :

  • À partir de PowerManager, en appelant PowerManager.reboot(PowerManager.REBOOT_USERSPACE)

  • À partir du shell, à l'aide de adb shell svc power reboot userspace ou adb reboot userspace

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

Si un appareil est compatible avec les redémarrages silencieux, 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 silencieux, 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 silencieux est demandé (via PowerManager ou à partir d'un shell), init effectue les étapes suivantes :

  1. Reçoit sys.powerctl=reboot,userspace.

  2. Crée un processus distinct UserspaceRebootWatchdogThread() pour surveiller le redémarrage silencieux.

  3. 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 silencieux. 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 des propriétés supplémentaires. Pour obtenir des exemples, consultez l' on userspace-reboot-requested action dans rootdir/init.rc.

  4. Exécute la DoUserspaceReboot fonction, 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 d'inactivité atteint, envoie SIGKILL pour arrêter tous les processus en cours d'exécution.
    3. Appelle /system/bin/vdc volume reset.
    4. Démonte l'appareil de sauvegarde zRAM.
    5. Démonte les packages APEX actifs.
    6. Revient à l'espace de noms de montage bootstrap.
    7. Déclenche l'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 silencieux, userdata est remonté en mode de création de points de contrôle lors de l'action userspace-reboot-fs-remount (pour en savoir plus, consultez la section suivante). Un redémarrage silencieux est considéré comme terminé une fois que le sys.boot_completed property est défini sur 1. À la fin du redémarrage silencieux, 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 silencieux, userdata est remonté en mode de création de points de contrôle lors du redémarrage silencieux. La logique de remontage est implémentée dans la fs_mgr_remount_userdata_into_checkpointing fonction et diffère selon les méthodes de création de points de contrôle. 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é avec l'option checkpoint=disable.

  • La création de points de contrôle au niveau des blocs (par exemple, ext4), /data est démonté et tous les appareils de mappage de périphériques parents sur lesquels il était monté sont détruits. Ensuite, userdata est monté à l'aide du 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 de clés au niveau du système de fichiers est utilisé pour gérer les clés chiffrées par identifiants (CE) et chiffrées par appareil (DE), les clés sont perdues une fois que userdata est démonté. Pour autoriser la restauration des clés, lors de l'installation d'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 de clés du système de fichiers.

Retour au redémarrage matériel

Pour s'assurer qu'un redémarrage silencieux ne laisse pas un appareil dans un état 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 à démarrer le redémarrage silencieux (c'est-à-dire sys.init.userspace_reboot.in_progress=1) dans un délai donné.
  • Un processus ne parvient pas à s'arrêter 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 démonté de manière incorrecte.
  • Une tentative de remontage de userdata en mode de création de points 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 silencieux 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 silencieux. Si la valeur de cette propriété est false, 0 ou n'est pas spécifiée, les tentatives de redémarrage sont rejetées.
  • init.userspace_reboot.sigkill.timeoutmillis contrôle le délai d'inactivité en millisecondes pour les processus qui ont reçu un signal SIGKILL afin de s'arrêter. Si l'un des processus ne parvient pas à s'arrêter dans le délai d'inactivité spécifié, un retour au redémarrage matériel est déclenché.
  • init.userspace_reboot.sigterm.timeoutmillis contrôle le délai d'inactivité en millisecondes pour les processus qui ont reçu un signal SIGTERM afin de s'arrêter. Tous les processus qui n'ont pas pu s'arrêter dans le délai d'inactivité 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 silencieux (c'est-à-dire sys.init.userspace_reboot.in_progress=1). Si un appareil ne parvient pas à démarrer le redémarrage silencieux dans le délai d'inactivité spécifié, un retour au redémarrage matériel est déclenché.
  • init.userspace_reboot.userdata_remount.timeoutmillis contrôle le délai d'inactivité en millisecondes pour démonter userdata. Si un appareil ne parvient pas à démonter userdata dans le délai d'inactivité spécifié, un retour au redémarrage matériel est déclenché.
  • init.userspace_reboot.watchdog.timeoutmillis contrôle le délai d'inactivité 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 d'inactivité spécifié, un retour au redémarrage matériel est déclenché.

Personnaliser l'animation lors du redémarrage silencieux

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

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