Reinicializações suaves

O Android 11 oferece suporte a reinicializações suaves, que são reinicializações em tempo de execução de processos no espaço do usuário usados ​​para aplicar atualizações que exigem reinicialização (por exemplo, atualizações em pacotes APEX). Atualmente, a reinicialização suave está limitada a processos iniciados após a montagem userdata .

Uma reinicialização suave é solicitada das seguintes maneiras:

  • Do PowerManager , chamando PowerManager.reboot(PowerManager.REBOOT_USERSPACE)

  • Do shell, usando adb shell svc power reboot userspace ou adb reboot userspace

Após uma reinicialização suave, o armazenamento criptografado de credenciais permanece desbloqueado.

Se um dispositivo suportar reinicializações suaves, o método da API PowerManager.isRebootingUserspace() retornará true e o valor da propriedade do sistema init.userspace_reboot.is_supported será igual a 1 .

Se o dispositivo não suportar reinicializações suaves, as chamadas para PowerManager.reboot(PowerManager.REBOOT_USERSPACE) , adb reboot userspace e adb shell svc power reboot userspace falharão.

Execução de reinicialização suave

Após a solicitação de uma reinicialização suave (através PowerManager ou de um shell), init executa as seguintes etapas:

  1. Recebe sys.powerctl=reboot,userspace .

  2. Bifurca um processo UserspaceRebootWatchdogThread() separado para monitorar a reinicialização suave.

  3. Aciona uma ação userspace-reboot-requested , que redefine todas as propriedades do sistema que podem afetar a reinicialização suave. Propriedades afetadas:

    • 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

    As propriedades acima devem ser definidas novamente durante a sequência de inicialização. Se necessário, você pode redefinir propriedades adicionais. Para obter exemplos, consulte a ação on userspace-reboot-requested em rootdir/init.rc .

  4. Executa a função DoUserspaceReboot , que executa as seguintes ações:

    1. Envia SIGTERM para processos iniciados após a montagem userdata e espera que eles parem.
    2. Depois que o tempo limite for atingido, envia SIGKILL para encerrar qualquer processo em execução.
    3. Chama /system/bin/vdc volume reset .
    4. Desmonta o dispositivo auxiliar zRAM.
    5. Desmonta pacotes APEX ativos.
    6. Volta para o namespace de montagem de bootstrap.
    7. Aciona a ação userspace-reboot-resume .

Se o ponto de verificação do sistema de arquivos tiver sido solicitado antes da reinicialização suave, userdata serão remontados no modo de ponto de verificação durante a ação userspace-reboot-fs-remount (consulte a seção a seguir para obter detalhes). Uma reinicialização suave é considerada depois que a sys.boot_completed property é definida como 1 . No final da reinicialização suave, a tela é mantida desligada e é necessária uma interação explícita do usuário para ativá-la.

Ponto de verificação do sistema de arquivos

Se um ponto de verificação do sistema de arquivos foi solicitado antes da reinicialização suave, userdata serão remontados no modo de ponto de verificação durante a reinicialização suave. A lógica de remontagem é implementada na função fs_mgr_remount_userdata_into_checkpointing e difere entre os métodos de checkpoint. Especificamente, quando userdata suporta:

  • Ponto de verificação no nível do sistema de arquivos (por exemplo, f2fs ), userdata é remontado com a opção checkpoint=disable .

  • Ponto de verificação em nível de bloco (por exemplo, ext4 ), então /data é desmontado e todos os dispositivos mapeadores de dispositivos pai sobre os quais ele foi montado são destruídos. Em seguida, userdata é montado usando o mesmo caminho de código usado na inicialização normal de checkpoint.

Se um conjunto de chaves no nível do sistema de arquivos for usado para gerenciar chaves criptografadas por credencial (CE) e criptografadas por dispositivo (DE), as chaves serão perdidas depois que userdata forem desmontados. Para permitir a restauração de chaves, ao instalar uma chave em um chaveiro do sistema de arquivos, vold também instala a mesma chave do tipo fscrypt-provisioning no chaveiro no nível da sessão. Quando init_user0 é chamado, vold reinstala as chaves no chaveiro do sistema de arquivos.

Fallback para reinicialização forçada

Para garantir que uma reinicialização suave não deixe um dispositivo inutilizável, o Android 11 inclui um substituto para reinicialização forçada que é acionado quando uma das seguintes condições é atendida:

  • Um dispositivo falha ao iniciar a reinicialização suave (ou seja, sys.init.userspace_reboot.in_progress=1 ) dentro de um determinado tempo limite.
  • Um processo não consegue parar dentro de um determinado tempo limite.
  • A operação /system/bin/vdc volume reset falha.
  • A desmontagem do dispositivo zRAM falha.
  • Um pacote APEX ativo é desmontado incorretamente.
  • Uma tentativa de remontar userdata no modo de ponto de verificação falha.
  • Um dispositivo não consegue inicializar com êxito (ou seja, sys.boot_completed=1 ) dentro de um determinado tempo limite.

Configuração por dispositivo

Alguns aspectos da reinicialização suave podem ser ajustados alterando os valores das seguintes propriedades:

  • init.userspace_reboot.is_supported controla quando um dispositivo pode executar uma reinicialização suave. Se o valor desta propriedade for false , 0 ou não for especificado, as tentativas de reinicialização serão rejeitadas.
  • init.userspace_reboot.sigkill.timeoutmillis controla o tempo limite em milissegundos para que os processos que receberam um sinal SIGKILL sejam interrompidos. Se um dos processos não parar no tempo limite determinado, será acionado um fallback para reinicialização forçada.
  • init.userspace_reboot.sigterm.timeoutmillis controla o tempo limite em milissegundos para processos que receberam um sinal SIGTERM para serem encerrados. Todos os processos que não conseguiram terminar no tempo limite determinado recebem um sinal SIGKILL .
  • init.userspace_reboot.started.timeoutmillis controla o tempo limite em milissegundos para o início da reinicialização suave (ou seja, sys.init.userspace_reboot.in_progress=1 ). Se um dispositivo não iniciar a reinicialização suave dentro do tempo limite determinado, um retorno à reinicialização forçada será acionado.
  • init.userspace_reboot.userdata_remount.timeoutmillis controla o tempo limite em milissegundos para desmontar userdata . Se um dispositivo não conseguir desmontar userdata dentro do tempo limite determinado, um retorno à reinicialização forçada será acionado.
  • init.userspace_reboot.watchdog.timeoutmillis controla o tempo limite para a inicialização bem-sucedida de um dispositivo (ou seja, sys.boot_completed=1 ). Se um dispositivo não inicializar dentro do tempo limite determinado, um retorno à reinicialização forçada será acionado.

Personalize a animação durante a reinicialização suave

A implementação de referência de uma reinicialização suave inclui a capacidade de personalizar a animação mostrada durante a reinicialização suave.

No final da ação userspace-reboot-fs-remount , init inicia o serviço bootanim . Este serviço procura a existência dos seguintes arquivos de animação, na ordem listada, e reproduz o primeiro que encontrar:

  • /product/media/userspace-reboot.zip
  • /oem/media/userspace-reboot.zip
  • /system/media/userspace-reboot.zip

Se nenhum arquivo de animação específico de reinicialização suave for especificado, bootanim mostrará uma animação android padrão.

Teste

O Android 11 inclui uma implementação de referência de reinicialização suave. Além disso, você pode verificar uma reinicialização suave usando testes CTS em UserspaceRebootHostTest .