Reinicios en segundo plano (<= AOSP 14)

Android 11 admite reinicios en segundo plano, que son reinicios en tiempo de ejecución de procesos que se producen en el espacio del usuario con el fin de implementar actualizaciones que requieran un reinicio (por ejemplo, actualizaciones de paquetes APEX). Actualmente, el reinicio parcial se limita a los procesos que se iniciaron después de que se activó userdata.

El reinicio en segundo plano se solicita de las siguientes maneras:

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

  • Desde la shell, con adb shell svc power reboot userspace o adb reboot userspace

Después de un reinicio en segundo plano, el almacenamiento encriptado a través 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, fallarán las llamadas a PowerManager.reboot(PowerManager.REBOOT_USERSPACE), adb reboot userspace y adb shell svc power reboot userspace.

Ejecución del reinicio en segundo plano

Después de que se solicita un reinicio en segundo plano (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() independiente para supervisar el reinicio en segundo plano.

  3. Activa una acción de userspace-reboot-requested, que restablece todas las propiedades del sistema que podrían afectar el reinicio en segundo plano. 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 se deben volver a configurar durante la secuencia de arranque. Si es necesario, puedes restablecer propiedades adicionales. Para ver ejemplos, consulta 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 que se iniciaron después de que se montó userdata y espera a que se detengan.
    2. Una vez que se alcanza el tiempo de espera, envía SIGKILL para detener cualquier proceso en ejecución.
    3. Llamadas /system/bin/vdc volume reset.
    4. Desmonta el dispositivo de respaldo de zRAM.
    5. Desmonta los paquetes APEX activos.
    6. Vuelve al espacio de nombres de activación de arranque.
    7. Activa la acción userspace-reboot-resume.

Si se solicitó la creación de puntos de control del sistema de archivos antes del reinicio en segundo plano, userdata se vuelve a montar en el modo de creación de puntos de control durante la acción userspace-reboot-fs-remount (consulta la siguiente sección para obtener más detalles). Se considera un reinicio en segundo plano después de que sys.boot_completed property se establece en 1. Al final del reinicio en segundo plano, la pantalla permanece apagada y se requiere la interacción del usuario explícita para activarla.

Creación de puntos de control del sistema de archivos

Si se solicitó un punto de control del sistema de archivos antes del reinicio parcial, userdata se vuelve a activar en el modo de punto de control durante el reinicio parcial. La lógica de reajuste se implementa en la función fs_mgr_remount_userdata_into_checkpointing y difiere entre los métodos de creación de puntos de control. Específicamente, cuando userdata admite lo siguiente:

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

  • Puntos de control a nivel de bloque (por ejemplo, ext4), luego se desmonta /data y se destruyen todos los dispositivos de asignador de dispositivos principales sobre los que se montó. A continuación, se activa userdata con las mismas instrucciones de código que se usan en el inicio normal de la creación de puntos de control.

Si se usa un llavero a nivel del sistema de archivos para administrar las claves encriptadas con credenciales (CE) y las claves encriptadas con el dispositivo (DE), las claves se pierden después de que se desmonta userdata. Para permitir la restauración de claves, cuando se instala una clave en un llavero del sistema de archivos, vold también instala la misma clave de tipo fscrypt-provisioning en el llavero a nivel de la sesión. Cuando se llama a init_user0, vold reinstala las claves en el llavero del sistema de archivos.

Resguardo para reinicio forzado

Para garantizar que un reinicio en segundo plano no deje un dispositivo en un estado inutilizable, Android 11 incluye un reinicio forzado de resguardo que se activa cuando se cumple una de las siguientes condiciones:

  • Un dispositivo no puede iniciar el reinicio en segundo plano (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 /system/bin/vdc volume reset falla.
  • No se pudo desmontar el dispositivo zRAM.
  • Un paquete APEX activo se desmonta de forma incorrecta.
  • No se pudo volver a montar userdata en el modo de punto de control.
  • Un dispositivo no puede arrancar correctamente (es decir, sys.boot_completed=1) dentro de un tiempo de espera determinado.

Configuración por dispositivo

Algunos aspectos del reinicio en segundo plano se pueden ajustar cambiando los valores de las siguientes propiedades:

  • init.userspace_reboot.is_supported controla cuándo un dispositivo puede realizar un reinicio en segundo plano. 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 un indicador SIGKILL. Si uno de los procesos no se detiene en el tiempo de espera determinado, se activa una reversión al reinicio forzado.
  • init.userspace_reboot.sigterm.timeoutmillis controla el tiempo de espera en milisegundos para que finalicen los procesos que recibieron un indicador SIGTERM. Todos los procesos que no pudieron finalizar en el tiempo de espera determinado reciben una señal SIGKILL.
  • init.userspace_reboot.started.timeoutmillis controla el tiempo de espera en milisegundos para que se inicie el reinicio parcial (es decir, sys.init.userspace_reboot.in_progress=1). Si un dispositivo no puede iniciar el reinicio parcial dentro del tiempo de espera determinado, se activa una alternativa de reinicio completo.
  • init.userspace_reboot.userdata_remount.timeoutmillis controla el tiempo de espera en milisegundos para desmontar userdata. Si un dispositivo no puede desmontar userdata dentro del tiempo de espera determinado, se activa un reinicio forzado como alternativa.
  • 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 determinado, se activa una alternativa de reinicio forzado.

Personaliza la animación durante el reinicio en segundo plano

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

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 para el reinicio en segundo plano, bootanim muestra una animación android predeterminada.

Prueba

Android 11 incluye una implementación de referencia de un reinicio en segundo plano. Además, puedes verificar un reinicio en segundo plano con las pruebas de CTS en UserspaceRebootHostTest.