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
, llamandoPowerManager.reboot(PowerManager.REBOOT_USERSPACE)
Desde la shell, con
adb shell svc power reboot userspace
oadb 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:
Recibe
sys.powerctl=reboot,userspace
.Bifurca un bloque separado
UserspaceRebootWatchdogThread()
para supervisar el reinicio en segundo plano.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 enrootdir/init.rc
Ejecuta las
DoUserspaceReboot
función, que realiza las siguientes acciones:- Envía
SIGTERM
a los procesos iniciados después de que se activauserdata
. espera a que se detengan. - Después de que se alcanza el tiempo de espera, envía
SIGKILL
para finalizar cualquier ejecución procesos. - Llama a
/system/bin/vdc volume reset
. - Desactiva el dispositivo de copia de seguridad de zRAM.
- Desactiva paquetes de APEX activos.
- Vuelve al espacio de nombres de activación de arranque.
- Activa
userspace-reboot-resume
. acción.
- Envía
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óncheckpoint=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 esfalse
,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ñalSIGKILL
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ñalSIGTERM
para finalizar. Todo los procesos que no se pudieron finalizar en el tiempo de espera determinado recibirán unSIGKILL
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 desactivaruserdata
. Si un dispositivo no puede desactivaruserdata
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