Reinicialização em segundo plano (<= AOSP 14)

O Android 11 oferece suporte à reinicialização em segundo plano, que são reinicializações de tempo de execução de processos no espaço do usuário usados para aplicar atualizações que exigem uma reinicialização, por exemplo, atualizações para pacotes APEX. Atualmente, a reinicialização em segundo plano é limitada a processos iniciados após a montagem do userdata.

Uma reinicialização em segundo plano é solicitada das seguintes maneiras:

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

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

Após uma reinicialização parcial, o armazenamento criptografado por credenciais continua desbloqueado.

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

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

Execução de reinício em segundo plano

Depois que uma reinicialização suave é solicitada (por PowerManager ou por um shell), init executa as seguintes etapas:

  1. Recebe sys.powerctl=reboot,userspace.

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

  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 precisam ser definidas novamente durante a sequência de inicialização. Se necessário, é possível redefinir outras propriedades. Para ver exemplos, consulte a ação on userspace-reboot-requested em rootdir/init.rc.

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

    1. Envia SIGTERM para processos iniciados após a montagem de userdata e espera que eles parem.
    2. Depois que o tempo limite é atingido, o SIGKILL é enviado para encerrar todos os processos em execução.
    3. Liga para /system/bin/vdc volume reset.
    4. Desmonta o dispositivo de suporte da zRAM.
    5. Desmonta pacotes APEX ativos.
    6. Volta ao namespace de montagem de inicialização.
    7. Aciona a ação userspace-reboot-resume.

Se o checkpointing do sistema de arquivos foi solicitado antes da reinicialização suave, userdata será remontado no modo de checkpointing durante a ação userspace-reboot-fs-remount. Consulte a seção a seguir para saber mais. Uma reinicialização suave é considerada depois que o sys.boot_completed property é definido como 1. No final da reinicialização, a tela permanece desligada e é necessária uma interação explícita do usuário para ativá-la.

Pontos 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 é remontado no modo de checkpoint durante a reinicialização suave. A lógica de remontagem é implementada na função fs_mgr_remount_userdata_into_checkpointing e varia de acordo com os métodos de checkpoint. Especificamente, quando userdata oferece suporte a:

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

  • Ponto de verificação no nível do bloco (por exemplo, ext4). Em seguida, /data é desmontada e todos os dispositivos pai do mapeador de dispositivos em que ela foi montada são destruídos. Em seguida, userdata é ativado usando o mesmo caminho de código usado na inicialização normal do checkpoint.

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

Substituto para reinicialização forçada

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

  • Um dispositivo não consegue iniciar uma reinicialização suave (ou seja, sys.init.userspace_reboot.in_progress=1) dentro de um determinado tempo limite.
  • Um processo não é interrompido dentro de um determinado tempo limite.
  • A operação /system/bin/vdc volume reset falhou.
  • Falha ao desconectar o dispositivo zRAM.
  • Um pacote APEX ativo é desconectado incorretamente.
  • Uma tentativa de reativar userdata no modo de checkpoint vai falhar.
  • Um dispositivo não inicializa (ou seja, sys.boot_completed=1) dentro de um tempo limite.

Configuração por dispositivo

Alguns aspectos de reinicialização flexível podem ser ajustados alterando os valores das seguintes propriedades:

  • O init.userspace_reboot.is_supported controla quando um dispositivo pode fazer uma reinicialização suave. Se o valor dessa propriedade for false, 0 ou não especificado, as tentativas de reinicialização serão rejeitadas.
  • O 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 for interrompido no tempo limite especificado, uma substituição para uma reinicialização forçada será acionada.
  • init.userspace_reboot.sigterm.timeoutmillis controla o tempo limite em milissegundos para que os processos que receberam um sinal SIGTERM sejam encerrados. Todos os processos que não foram encerrados no tempo limite especificado recebem um sinal SIGKILL.
  • O init.userspace_reboot.started.timeoutmillis controla o tempo limite em milissegundos para que a reinicialização suave seja iniciada, ou seja, sys.init.userspace_reboot.in_progress=1. Se um dispositivo não conseguir iniciar a reinicialização suave dentro do tempo limite especificado, uma substituição para a reinicialização forçada será acionada.
  • init.userspace_reboot.userdata_remount.timeoutmillis controla o tempo limite em milissegundos para desmontar userdata. Se um dispositivo não desconectar o userdata dentro do tempo limite especificado, uma substituição para a reinicialização forçada será acionada.
  • O init.userspace_reboot.watchdog.timeoutmillis controla o tempo limite para que um dispositivo seja inicializado (ou seja, sys.boot_completed=1). Se um dispositivo não for inicializado dentro do tempo limite especificado, uma substituição para a reinicialização forçada será acionada.

Personalizar 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. Esse serviço procura a existência dos arquivos de animação a seguir, na ordem listada, e exibe o primeiro que encontra:

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

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

Teste

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