Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Se usó la API de Cloud Translation para traducir esta página.

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 para implementar actualizaciones que requieran 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 activó userdata.

Se solicita un reinicio suave 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 suave, el almacenamiento encriptado por credenciales permanece desbloqueado.

Si un dispositivo admite reinicios en segundo plano, el método de la 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 los admite, las llamadas a PowerManager.reboot(PowerManager.REBOOT_USERSPACE), adb reboot userspace y adb shell svc power reboot userspace fallarán.

Ejecución del reinicio en segundo plano

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

Recibe sys.powerctl=reboot,userspace.
Crea una bifurcación de un proceso UserspaceRebootWatchdogThread() independiente para supervisar el reinicio suave.
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 se deben volver a establecer durante la secuencia de inicio. Si es necesario, puedes restablecer propiedades adicionales. Para ver ejemplos, consulta la acción on userspace-reboot-requested en rootdir/init.rc.
Ejecuta la función DoUserspaceReboot, que realiza las siguientes acciones:
1. Envía SIGTERM a los procesos iniciados después de que se activa userdata y espera a que se detengan.
2. Una vez que se alcanza el tiempo de espera, envía SIGKILL para finalizar cualquier proceso en ejecución.
3. Llama a /system/bin/vdc volume reset.
4. Desactiva el dispositivo de copia de seguridad de zRAM.
5. Desmonta los paquetes de APEX activos.
6. Vuelve al espacio de nombres de activación de arranque.
7. Activa la acción userspace-reboot-resume.

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

Puntos de control del sistema de archivos

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

Punto de control a nivel del sistema de archivos (por ejemplo, f2fs), userdata se vuelve a activar con la opción checkpoint=disable.
Puntos de control a nivel de bloque (por ejemplo, ext4). Luego, se desactiva /data y se destruyen todos los dispositivos del asignador de dispositivos superiores en los que se activó. A continuación, userdata se activa con la misma ruta de código que se usa en el inicio normal de puntos de control.

Si se usa un llavero a nivel del sistema de archivos para administrar claves encriptadas con credenciales (CE) y encriptadas con el dispositivo (DE), las claves se pierden después de que se desmontó userdata. Para permitir el restablecimiento 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.

Recurre al reinicio forzado

Para garantizar que un reinicio suave no deje un dispositivo en un estado inutilizable, Android 11 incluye un resguardo para el reinicio forzado 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 puede desmontar el dispositivo zRAM.
Un paquete APEX activo se desmonta de forma incorrecta.
No se puede volver a activar 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

Para ajustar algunos aspectos del reinicio suave, cambia 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 de los procesos que recibieron una señal SIGKILL para detenerse. Si uno de los procesos no se detiene en el tiempo de espera determinado, se activa un resguardo para el reinicio forzado.
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 se 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 suave (es decir, sys.init.userspace_reboot.in_progress=1). Si un dispositivo no inicia el reinicio suave dentro del tiempo de espera determinado, se activa un resguardo para el reinicio forzado.
init.userspace_reboot.userdata_remount.timeoutmillis controla el tiempo de espera en milésimas de segundo para desmontar userdata. Si un dispositivo no desmonta userdata dentro del tiempo de espera determinado, se activa un resguardo para el reinicio forzado.
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 un resguardo para reiniciarlo de forma forzosa.

Cómo personalizar la animación durante el reinicio en segundo plano

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

Prueba

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