O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Esta página foi traduzida pela API Cloud Translation.

Reinícios em segundo plano

O Android 11 oferece suporte a reinicializações em segundo plano, que são reinicializações durante a execução de processos no espaço do usuário utilizado para aplicar atualizações que exigir uma reinicialização (por exemplo, atualizações para pacotes APEX). Atualmente, leve A reinicialização é 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 flexível, o armazenamento criptografado por credenciais permanece desbloqueado.

Se um dispositivo oferecer suporte a reinicializações em segundo plano, o O método de API PowerManager.isRebootingUserspace() retorna true, e o valor da propriedade do sistema init.userspace_reboot.is_supported é igual a 1.

Se o dispositivo não oferecer suporte à reinicialização em segundo plano, a chamada será feita para PowerManager.reboot(PowerManager.REBOOT_USERSPACE), adb reboot userspace e adb shell svc power reboot userspace falham.

Execução de reinicialização em segundo plano

Depois que uma reinicialização flexível for solicitada (por meio do PowerManager ou de um shell), O init executa as seguintes etapas:

Recebe sys.powerctl=reboot,userspace.
Bifurca um UserspaceRebootWatchdogThread() para monitorar a reinicialização forçada.
Aciona uma ação userspace-reboot-requested, que redefine todo o sistema. propriedades que podem afetar a reinicialização flexível. 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, redefinir outras propriedades. Para ver exemplos, consulte a on userspace-reboot-requested ação em rootdir/init.rc.
Executa o DoUserspaceReboot que executa as seguintes ações:
1. Envia SIGTERM para processos iniciados após a montagem do userdata e espera eles parar.
2. Depois que o tempo limite for atingido, envia SIGKILL para encerrar qualquer execução processos de negócios seguros.
3. Liga para /system/bin/vdc volume reset.
4. Desmonta o dispositivo de apoio da zRAM.
5. Desmonta pacotes APEX ativos.
6. Muda de volta para o namespace de montagem de inicialização.
7. Aciona o userspace-reboot-resume. à ação.

Se o checkpoint do sistema de arquivos tiver sido solicitado antes da reinicialização gradual, userdata é remontada no modo de checkpoint durante a userspace-reboot-fs-remount. Consulte a seção a seguir para mais detalhes. Um A reinicialização em segundo plano é considerada depois que o sys.boot_completed property é definido para 1. Ao final da reinicialização gradual, o visor é mantido desligado e interação explícita do usuário é necessária para despertá-lo.

Checkpoint do sistema de arquivos

Se um checkpoint do sistema de arquivos for solicitado antes dessa reinicialização, O userdata é remontado no modo de checkpoint durante a reinicialização restrita. A lógica de remontagem é implementada fs_mgr_remount_userdata_into_checkpointing função 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 é remontados com a opção checkpoint=disable.
Checkpoint no nível do bloco (por exemplo, ext4), depois o /data é desconectado. e todos os dispositivos mapeadores de dispositivos principais nos quais ele foi instalado são destruídos. Em seguida, userdata é montado usando o mesmo caminho de código usado em na inicialização normal do checkpoint.

Se um keyring no nível do sistema de arquivos for usado para gerenciar credenciais criptografadas (CE) e chaves criptografadas pelo dispositivo (DE), elas são perdidas depois que userdata é desconectado. 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 nível da sessão keyring Quando init_user0 for chamado, vold reinstala as chaves no arquivo. keyring do sistema.

Substituto para reinicialização forçada

Para garantir que uma reinicialização em segundo plano não deixe um dispositivo inutilizável, faça o seguinte: O Android 11 inclui um substituto para a reinicialização forçada que é acionada quando uma das seguintes condições é atendida:

Um dispositivo falha ao iniciar uma reinicialização flexível (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 falha.
Falha ao desconectar o dispositivo zRAM.
Um pacote APEX ativo é desconectado incorretamente.
Uma tentativa de reativar userdata no modo de checkpoint vai falhar.
Falha na inicialização de um dispositivo (ou seja, sys.boot_completed=1) dentro de uma devido ao tempo limite.

Configuração por dispositivo

Alguns aspectos de reinicialização flexível podem ser ajustados com a mudança dos valores dos seguintes propriedades:

O init.userspace_reboot.is_supported controla quando um dispositivo pode realizar uma "reinicialização em segundo plano". Se o valor dessa 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 milésimos de segundo para processos que receberam um sinal SIGKILL sejam interrompidos. Se um dos se os processos não forem interrompidos no tempo limite determinado, uma substituição por a reinicialização for acionada.
init.userspace_reboot.sigterm.timeoutmillis controla o tempo limite em milissegundos para processos que receberam um sinal SIGTERM sejam encerrados. Tudo os processos que não foram encerrados no tempo limite determinado recebem uma SIGKILL indicador.
init.userspace_reboot.started.timeoutmillis controla o tempo limite em milissegundos para a reinicialização flexível começar (ou seja, sys.init.userspace_reboot.in_progress=1). Se um dispositivo não iniciar de forma reversível reiniciar dentro do tempo limite determinado, uma substituição para uma reinicialização forçada será acionada.
init.userspace_reboot.userdata_remount.timeoutmillis controla o tempo limite em milissegundos para desconectar userdata. Se não for possível desconectar o dispositivo userdata dentro do tempo limite determinado, uma substituição para uma reinicialização forçada será acionada.
init.userspace_reboot.watchdog.timeoutmillis controla o tempo limite de um dispositivo seja inicializado corretamente (ou seja, sys.boot_completed=1). Se um dispositivo não inicializar dentro do tempo limite, uma alternativa para a reinicialização forçada será acionada.

Personalizar animação durante uma reinicialização leve

A implementação de referência de uma reinicialização flexível inclui a possibilidade de personalizar animação mostrada durante a reinicialização forçada.

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

/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 flexível for especificado, o bootanim vai mostrar uma animação android padrão.

Teste

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