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

Reinicios suaves

Android 11 admite reinicios suaves, que son reinicios en tiempo de ejecución de procesos en el espacio de usuario que se utilizan para aplicar actualizaciones que requieren un reinicio (por ejemplo, actualizaciones de paquetes APEX). Actualmente, el reinicio suave se limita a los procesos que se iniciaron después de userdata se ha montado.

Se solicita un reinicio suave de las siguientes formas:

  • De PowerManager , llamando PowerManager.reboot(PowerManager.REBOOT_USERSPACE)

  • De cáscara, usando adb shell svc power reboot userspace o adb reboot userspace

Después de un reinicio suave, el almacenamiento cifrado con credenciales permanece desbloqueado.

Si un dispositivo soporta reinicia suave, luego los PowerManager.isRebootingUserspace() de método API devuelve 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 suaves, luego llama a PowerManager.reboot(PowerManager.REBOOT_USERSPACE) , adb reboot userspace , y adb shell svc power reboot userspace falle.

Ejecución de reinicio suave

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

  1. Recibe sys.powerctl=reboot,userspace .

  2. Forks una separada UserspaceRebootWatchdogThread() proceso para supervisar el reinicio suave.

  3. Desencadena un userspace-reboot-requested la acción, 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 deben establecerse nuevamente durante la secuencia de arranque. Si es necesario, puede restablecer propiedades adicionales. Para obtener ejemplos, consulte la on userspace-reboot-requested acción en rootdir/init.rc .

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

    1. Envía SIGTERM a los procesos iniciados después de userdata ha sido montado y espera a que se detengan.
    2. Una vez alcanzado el tiempo de espera, envía SIGKILL a interrumpir los procesos que se ejecutan.
    3. Llamadas /system/bin/vdc volume reset .
    4. Desmonta el dispositivo de respaldo zRAM.
    5. Desmonta paquetes APEX activos.
    6. Vuelve al espacio de nombres de montaje de arranque.
    7. Pone en marcha el userspace-reboot-resume acción.

Si se solicitó los puntos de control del sistema de archivos antes del reinicio suave, userdata se vuelve a montar en modo de puntos de control durante el userspace-reboot-fs-remount la acción (ver la siguiente sección para más detalles). Un reinicio suave se considera después de la sys.boot_completed property se establece en 1 . Al final del reinicio suave, la pantalla se mantiene apagada y se requiere la interacción explícita del usuario para activarla.

Punto de control del sistema de archivos

Si se solicitó un puesto de control del sistema de archivos antes del reinicio suave, userdata se vuelve a montar en modo de puntos de control durante el reinicio suave. Lógica Reensamblaje se implementa en el fs_mgr_remount_userdata_into_checkpointing función, y se diferencia entre los métodos de los puntos de control. Específicamente, cuando userdata soportes:

  • Puntos de control de nivel del sistema de archivos (por ejemplo, f2fs ), userdata se vuelve a montar con el checkpoint=disable opción.

  • Bloquear los puntos de control de nivel (por ejemplo, ext4 ), entonces /data se desmonta y todos los dispositivos de mapeador de dispositivos matriz se montó en la parte superior de son destruidos. A continuación, userdata se monta utilizando la misma ruta de código, como se usa en el maletero de puntos de control normal.

Si se utiliza un anillo de claves a nivel de sistema de archivos para gestionar las claves de cifrado de credenciales-(CE) y de dispositivos encriptados (DE), a continuación, las llaves se pierden después de userdata se desmonta. Para permitir la restauración clave, al instalar una llave en un llavero sistema de archivos, vold también instala la misma clave de tipo fscrypt-provisioning al anillo de claves a nivel de sesión. Cuando init_user0 se llama, vold vuelve a instalar las llaves en el llavero del sistema de archivos.

Retorno a reinicio completo

Para garantizar que un reinicio suave no deje un dispositivo en un estado inutilizable, Android 11 incluye una alternativa al reinicio completo que se activa cuando se cumple una de las siguientes condiciones:

  • Un dispositivo no se 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.
  • El /system/bin/vdc volume reset de operación fallida.
  • El desmontaje del dispositivo zRAM falla.
  • Un paquete APEX activo se desmonta incorrectamente.
  • Un intento de volver a montar userdata en el modo de punto de comprobación falla.
  • Un dispositivo no arranque con éxito (es decir, sys.boot_completed=1 ) dentro de un tiempo de espera determinado.

Configuración por dispositivo

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

  • init.userspace_reboot.is_supported controles cuando 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 los procesos que recibieron una SIGKILL señal de parar. Si uno de los procesos no se detiene en el tiempo de espera especificado, se activa un retroceso al reinicio completo.
  • init.userspace_reboot.sigterm.timeoutmillis controla el tiempo de espera en milisegundos para los procesos que recibieron una SIGTERM señal para terminar. Todos los procesos que no lograron terminar en el tiempo de espera determinado reciben un SIGKILL señal.
  • init.userspace_reboot.started.timeoutmillis controla el tiempo de espera en milisegundos para reiniciar suave para empezar (es decir, sys.init.userspace_reboot.in_progress=1 ). Si un dispositivo no inicia el reinicio suave dentro del tiempo de espera dado, se activa una reserva para reinicio completo.
  • init.userspace_reboot.userdata_remount.timeoutmillis controla el tiempo de espera en milisegundos para desmontar userdata . Si un dispositivo no unmout userdata dentro del tiempo de espera determinado, un repliegue de reinicio duro se dispara.
  • init.userspace_reboot.watchdog.timeoutmillis controla el tiempo de espera para que un dispositivo de arranque con éxito (es decir, sys.boot_completed=1 ). Si un dispositivo no se inicia dentro del tiempo de espera dado, se activa una alternativa al reinicio completo.

Personalización de 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 del userspace-reboot-fs-remount la acción, init inicia el bootanim servicio. 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 reinicio suave, bootanim muestra un defecto android animación.

Pruebas

Android 11 incluye una implementación de referencia de un reinicio suave. Además, se puede verificar un reinicio por software mediante pruebas de CTS en UserspaceRebootHostTest .