A partir del 27 de marzo de 2025, te recomendamos que uses android-latest-release en lugar de aosp-main para compilar y contribuir a AOSP. Para obtener más información, consulta Cambios en AOSP.

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 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 parcial 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 parcial, 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 de reinicio en segundo plano

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

Recibe sys.powerctl=reboot,userspace.
Bifurca un proceso UserspaceRebootWatchdogThread() independiente para supervisar el reinicio parcial.
Activa una acción de userspace-reboot-requested, que restablece todas las propiedades del sistema que podrían afectar el reinicio parcial. 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.
Ejecuta la función DoUserspaceReboot, que realiza las siguientes acciones:
1. Envía SIGTERM a los procesos que se inician después de que se haya activado userdata y espera a que se detengan.
2. Una vez que transcurre el tiempo de espera, envía SIGKILL para detener cualquier proceso en ejecución.
3. Llamadas a /system/bin/vdc volume reset.
4. Desmonta el dispositivo de respaldo 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ó un punto de control del sistema de archivos antes del reinicio parcial, userdata se vuelve a montar en el modo de punto de control durante la acción userspace-reboot-fs-remount (consulta la siguiente sección para obtener más detalles). Se considera un reinicio parcial después de que sys.boot_completed property se establece en 1. Al final del reinicio parcial, la pantalla permanece apagada y se requiere la interacción explícita del usuario 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 la misma ruta de código que se usa 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 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.

Cómo volver al reinicio forzado

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

Un dispositivo no puede iniciar el reinicio parcial (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 se inicia correctamente (es decir, sys.boot_completed=1) dentro de un tiempo de espera determinado.

Configuración por dispositivo

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

init.userspace_reboot.is_supported controla cuándo un dispositivo puede realizar un reinicio parcial. Si el valor de esta propiedad es false, 0 o no se especifica, se rechazarán 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 detiene en el tiempo de espera determinado, se activa un reinicio forzado como alternativa.
init.userspace_reboot.sigterm.timeoutmillis controla el tiempo de espera en milisegundos para los procesos que recibieron un indicador SIGTERM para finalizar. 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 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 determinado, se activa una alternativa de reinicio forzado.
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 parcial

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

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 parcial, 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 parcial con las pruebas de CTS en UserspaceRebootHostTest.