Reinicios en segundo plano

Android 11 admite reinicios en segundo plano, que son reinicios en tiempo de ejecución de procesos en el espacio de usuario utilizado para aplicar actualizaciones que requieren un reinicio (por ejemplo, actualizaciones de paquetes de APEX). Actualmente, las El reinicio se limita a los procesos que se iniciaron después de que se activó userdata.

Se solicita un reinicio en segundo plano de las siguientes maneras:

  • De PowerManager, llamando 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 por credenciales permanece desbloqueado.

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

Si el dispositivo no es compatible con reinicios en segundo plano, llama a PowerManager.reboot(PowerManager.REBOOT_USERSPACE), adb reboot userspace y adb shell svc power reboot userspace fallan.

Ejecución de 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 bloque separado UserspaceRebootWatchdogThread() para supervisar el reinicio en segundo plano.

  3. Activa una acción userspace-reboot-requested, que restablece todo el sistema. que pueden 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 establecer durante la secuencia de inicio. Si es necesario, restablecer propiedades adicionales. Para ver ejemplos, consulta el on userspace-reboot-requested acción en rootdir/init.rc

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

    1. Envía SIGTERM a los procesos iniciados después de que se activa userdata. espera a que se detengan.
    2. Después de que se alcanza el tiempo de espera, envía SIGKILL para finalizar cualquier ejecución procesos.
    3. Llama a /system/bin/vdc volume reset.
    4. Desactiva el dispositivo de copia de seguridad de zRAM.
    5. Desactiva paquetes de APEX activos.
    6. Vuelve al espacio de nombres de activación de arranque.
    7. Activa userspace-reboot-resume. acción.

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

Punto de control del sistema de archivos

Si se solicitó un punto de control del sistema de archivos antes del reinicio en segundo plano, userdata se vuelve a activar en modo de control durante el reinicio en segundo plano. Se implementa la lógica de reactivación de fs_mgr_remount_userdata_into_checkpointing y difiere entre los métodos de control. En concreto, cuando userdata admite lo siguiente:

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

  • Punto de control a nivel de bloque (por ejemplo, ext4); luego, /data se desactiva. y todos los dispositivos superiores en los que se montó son antes de que se destruyan. A continuación, userdata se activa con la misma ruta de código que se usa en inicio de punto de control normal.

Si se usa un llavero de claves a nivel del sistema de archivos para administrar la encriptación de credenciales (CE) y claves encriptadas por el dispositivo (DE), se pierden luego de desactivar userdata. Para permitir el restablecimiento de la clave, cuando se instala una clave en un llavero de claves del sistema de archivos, vold también instala la misma clave de tipo fscrypt-provisioning a nivel de sesión el llavero de claves. Cuando se llame a init_user0, vold reinstalará las claves en el archivo. el llavero de claves del sistema.

Recurre al reinicio forzado

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

  • Un dispositivo no inicia 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 puede desmontar el dispositivo zRAM.
  • Un paquete de APEX activo se desactiva de forma incorrecta.
  • Falla un intento de volver a activar userdata en el modo de control.
  • Un dispositivo no se inicia correctamente (es decir, sys.boot_completed=1) dentro de una tiempo de espera establecido.

Configuración por dispositivo

Algunos aspectos del reinicio en segundo plano se pueden ajustar si cambias los siguientes valores propiedades:

  • init.userspace_reboot.is_supported controla cuándo un dispositivo puede realizar una 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 los procesos que recibieron una señal SIGKILL para detenerse. Si uno de los procesos no se detienen en el tiempo de espera establecido y, luego, se activa el reinicio.
  • init.userspace_reboot.sigterm.timeoutmillis controla el tiempo de espera en milisegundos para los procesos que recibieron una señal SIGTERM para finalizar. Todo los procesos que no se pudieron finalizar en el tiempo de espera determinado recibirán un SIGKILL indicador.
  • init.userspace_reboot.started.timeoutmillis controla el tiempo de espera en milisegundos para que se inicie el reinicio en segundo plano (es decir, sys.init.userspace_reboot.in_progress=1). Si un dispositivo no se inicia de forma parcial reiniciar dentro del tiempo de espera determinado, se activa un resguardo de reinicio forzado.
  • init.userspace_reboot.userdata_remount.timeoutmillis controla el tiempo de espera en milisegundos para desactivar userdata. Si un dispositivo no puede desactivar userdata dentro del tiempo de espera determinado, se activa un resguardo de reinicio forzado.
  • init.userspace_reboot.watchdog.timeoutmillis controla el tiempo de espera de un se inicie correctamente (es decir, sys.boot_completed=1). Si un dispositivo no se inicia en el tiempo de espera establecido, se recurrirá a un reinicio forzado activa.

Cómo personalizar 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 animación que se muestra durante el reinicio en segundo plano.

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

  • /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 en segundo plano, bootanim muestra un 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 el CTS pruebas en UserspaceRebootHostTest