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)
Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

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, usa 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 suaves, 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 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 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 configurar 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 haya activado userdata y espera a que se detengan.
2. Una vez que se alcanza el tiempo de espera, envía SIGKILL para finalizar todos los procesos 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. Regresa al espacio de nombres de activación.
7. Activa la acción userspace-reboot-resume.

Si se solicitó el punto de control del sistema de archivos antes del reinicio suave, userdata se vuelve a activar en el modo de punto de control durante la acción userspace-reboot-fs-remount (consulta la siguiente sección para obtener más información). 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 reconexión se implementa en la función fs_mgr_remount_userdata_into_checkpointing y difiere entre los métodos de puntos 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.

Resguardo para el 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 suave (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 para que se detengan los procesos que recibieron una señal SIGKILL. 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 suave

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 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 suave, 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.