Reinicios suaves

Android 11 admite reinicios suaves, que son reinicios en tiempo de ejecución de procesos en el espacio del usuario que se usan para aplicar actualizaciones que requieren un reinicio (por ejemplo, actualizaciones de paquetes APEX). Actualmente, el reinicio suave se limita a los procesos que se iniciaron después de que se userdata los datos de usuario.

Se solicita un reinicio suave de las siguientes maneras:

  • Desde PowerManager , llamando a PowerManager.reboot(PowerManager.REBOOT_USERSPACE)

  • Desde shell, usando adb shell svc power reboot userspace o adb reboot userspace

Después de un reinicio suave, el almacenamiento cifrado de credenciales permanece desbloqueado.

Si un dispositivo admite reinicios suaves, el método de la API PowerManager.isRebootingUserspace() devuelve true y el valor de la propiedad del sistema init.userspace_reboot.is_supported es igual a 1 .

Si el dispositivo no admite reinicios suaves, las llamadas a PowerManager.reboot(PowerManager.REBOOT_USERSPACE) , adb reboot userspace y adb shell svc power reboot userspace fallan.

Ejecución de reinicio suave

Después de solicitar un reinicio suave (a través de PowerManager o desde un shell), init realiza los siguientes pasos:

  1. Recibe sys.powerctl=reboot,userspace .

  2. Bifurca un proceso UserspaceRebootWatchdogThread() separado para monitorear el reinicio suave.

  3. Activa una acción userspace-reboot-requested , que restablece todas las propiedades del sistema que podrían afectar el reinicio suave. Propiedades afectadas:

    • 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

    Las propiedades anteriores deben establecerse nuevamente durante la secuencia de arranque. Si es necesario, puede restablecer propiedades adicionales. Para ver ejemplos, consulte la acción on userspace-reboot-requested en rootdir/init.rc .

  4. Ejecuta la función DoUserspaceReboot , que realiza las siguientes acciones:

    1. Envía SIGTERM a los procesos iniciados después de que se hayan montado los datos de userdata y espera a que se detengan.
    2. Una vez que se alcanza el tiempo de espera, envía SIGKILL para eliminar cualquier proceso en ejecución.
    3. /system/bin/vdc volume reset llamadas.
    4. Desmonta el dispositivo de respaldo zRAM.
    5. Desmonta paquetes APEX activos.
    6. Vuelve al espacio de nombres de montaje de arranque.
    7. Activa la acción userspace-reboot-resume .

Si se solicitó el punto de control del sistema de archivos antes del reinicio suave, los datos de userdata se vuelven a montar en el modo de punto de control durante la acción userspace-reboot-fs-remount (consulte la siguiente sección para obtener más detalles). Se considera un reinicio suave después de que la sys.boot_completed property se establezca en 1 . Al final del reinicio suave, la pantalla se mantiene apagada y se requiere una interacción explícita del usuario para reactivarla.

Puntos de control del sistema de archivos

Si se solicitó un punto de control del sistema de archivos antes del reinicio suave, los datos de userdata se vuelven a montar en el modo de punto de control durante el reinicio suave. La lógica de montaje se implementa en la función fs_mgr_remount_userdata_into_checkpointing y difiere entre los métodos de puntos de control. Específicamente, cuando los datos de userdata admiten:

  • Puntos de control a nivel del sistema de archivos (por ejemplo, f2fs ), los datos de usuario se userdata a montar con la opción checkpoint=disable .

  • Puntos de control de nivel de bloque (por ejemplo, ext4 ), luego /data se desmonta y todos los dispositivos mapeadores de dispositivos principales sobre los que se montó se destruyen. A continuación, los datos de userdata se montan utilizando la misma ruta de código que se utiliza en el inicio de punto de control normal.

Si se usa un conjunto de claves a nivel de sistema de archivos para administrar claves cifradas por credencial (CE) y cifradas por dispositivo (DE), las claves se pierden después de que se desmontan los datos de userdata . Para permitir la restauración de claves, al instalar una clave en un conjunto de claves del sistema de archivos, vold también instala la misma clave de tipo fscrypt-provisioning en el conjunto de claves a nivel de sesión. Cuando se llama a init_user0 , vold reinstala las claves en el conjunto de claves del sistema de archivos.

Retroceder al reinicio completo

Para asegurarse de que un reinicio suave no deje un dispositivo en un estado inutilizable, Android 11 incluye una alternativa al reinicio completo que se activa cuando se cumple una de las siguientes condiciones:

  • Un dispositivo no puede iniciar el reinicio suave (es decir, sys.init.userspace_reboot.in_progress=1 ) dentro de un tiempo de espera determinado.
  • Un proceso no se detiene dentro de un tiempo de espera determinado.
  • La operación de /system/bin/vdc volume reset falla.
  • El desmontaje del dispositivo zRAM falla.
  • Un paquete APEX activo se desmonta incorrectamente.
  • Falla un intento de volver a montar los datos de userdata en el modo de puntos de control.
  • Un dispositivo no se inicia correctamente (es decir, sys.boot_completed=1 ) dentro de un tiempo de espera determinado.

Configuración por dispositivo

Algunos aspectos del reinicio suave se pueden ajustar cambiando los valores de las siguientes propiedades:

  • init.userspace_reboot.is_supported controla cuándo un dispositivo puede realizar un reinicio suave. Si el valor de esta propiedad es false , 0 , o no se especifica, se rechazan los intentos de reinicio.
  • init.userspace_reboot.sigkill.timeoutmillis controla el tiempo de espera en milisegundos para que se detengan los procesos que recibieron una señal SIGKILL . Si uno de los procesos no se detiene en el tiempo de espera dado, se activa un reinicio completo.
  • init.userspace_reboot.sigterm.timeoutmillis controla el tiempo de espera en milisegundos para que finalicen los procesos que recibieron una señal SIGTERM . Todos los procesos que no terminaron en el tiempo de espera dado reciben una señal SIGKILL .
  • init.userspace_reboot.started.timeoutmillis controla el tiempo de espera en milisegundos para que comience el reinicio suave (es decir, sys.init.userspace_reboot.in_progress=1 ). Si un dispositivo no puede iniciar el reinicio suave dentro del tiempo de espera dado, se activa un reinicio completo.
  • init.userspace_reboot.userdata_remount.timeoutmillis controla el tiempo de espera en milisegundos para desmontar los datos de userdata . Si un dispositivo no puede desmontar los datos de userdata dentro del tiempo de espera dado, se activa un reinicio completo.
  • init.userspace_reboot.watchdog.timeoutmillis controla el tiempo de espera para que un dispositivo se inicie correctamente (es decir, sys.boot_completed=1 ). Si un dispositivo no se inicia dentro del tiempo de espera dado, se activa un reinicio completo.

Personalización de la animación durante el reinicio suave

La implementación de referencia de un reinicio suave incluye la capacidad de personalizar la animación que se muestra durante el reinicio suave.

Al final de la acción userspace-reboot-fs-remount , init inicia el servicio bootanim . Este servicio busca la existencia de los siguientes archivos de animación, en el orden indicado, y reproduce el primero que encuentra:

  • /product/media/userspace-reboot.zip
  • /oem/media/userspace-reboot.zip
  • /system/media/userspace-reboot.zip

Si no se especifican archivos de animación específicos de reinicio suave, bootanim muestra una animación predeterminada de android .

Pruebas

Android 11 incluye una implementación de referencia de un reinicio suave. Además, puede verificar un reinicio suave mediante pruebas CTS en UserspaceRebootHostTest .