O Android 11 oferece suporte a reinicializações suaves, que são reinicializações de tempo de execução de processos no espaço do usuário usado para aplicar atualizações que exigem uma reinicialização (por exemplo, atualizações para pacotes APEX). Atualmente, a reinicialização suave é limitada a processos iniciados após a montagem de userdata
.
Uma reinicialização suave é solicitada das seguintes maneiras:
Do
PowerManager
, chamandoPowerManager.reboot(PowerManager.REBOOT_USERSPACE)
A partir do shell, usando o espaço de
adb shell svc power reboot userspace
de usuário deadb 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
Depois que uma reinicialização suave é solicitada (através do PowerManager
ou de um shell), o init
executa as seguintes etapas:
Recebe
sys.powerctl=reboot,userspace
.Bifurca um processo
UserspaceRebootWatchdogThread()
separado para monitorar a reinicialização suave.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
emrootdir/init.rc
.-
Executa a função
DoUserspaceReboot
, que executa as seguintes ações:- Envia
SIGTERM
para processos iniciados após a montagem deuserdata
e espera que eles parem. - Após o tempo limite ser atingido, envia
SIGKILL
para matar todos os processos em execução. - Chama
/system/bin/vdc volume reset
. - Desmonta o dispositivo auxiliar zRAM.
- Desmonta pacotes APEX ativos.
- Volta para o namespace de montagem de bootstrap.
- Aciona a ação
userspace-reboot-resume
.
- Envia
Se o ponto de verificação do sistema de arquivos foi solicitado antes da reinicialização suave, userdata
é remontado 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 após a sys.boot_completed property
ser definida como 1
. No final da reinicialização suave, a tela é mantida desligada e a interação explícita do usuário é necessária 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, os dados do userdata
sã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 verificação. Especificamente, quando userdata
suporta:
Ponto de verificação no nível do sistema de arquivos (por exemplo,
f2fs
),userdata
é remontado com a opçãocheckpoint=disable
.Ponto de verificação em nível de bloco (por exemplo,
ext4
), então/data
é desmontado e todos os dispositivos mapeadores de dispositivo 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 de ponto de verificação normal.
Se um chaveiro de nível de sistema de arquivos for usado para gerenciar chaves criptografadas por credencial (CE) e criptografadas por dispositivo (DE), as chaves serão userdata
após a desmontagem dos dados do usuário. Para permitir a restauração da chave, ao instalar uma chave em um chaveiro do sistema de arquivos, o vold
também instala a mesma chave do tipo fscrypt-provisioning
para o chaveiro em nível de 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 em um estado inutilizável, o Android 11 inclui um fallback para reinicialização forçada que é acionada 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 falha ao 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 os dados do
userdata
no modo de ponto de verificação falha. - Um dispositivo falha ao inicializar com êxito (ou seja,
sys.boot_completed=1
) dentro de um determinado tempo limite.
Configuração por dispositivo
Alguns aspectos de 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 dessa propriedade forfalse
,0
ou não especificado, as tentativas de reinicialização serão rejeitadas. -
init.userspace_reboot.sigkill.timeoutmillis
controla o tempo limite em milissegundos para os processos que receberam um sinalSIGKILL
para parar. Se um dos processos não parar no tempo limite determinado, um fallback para reinicialização forçada será acionado. -
init.userspace_reboot.sigterm.timeoutmillis
controla o tempo limite em milissegundos para processos que receberam um sinalSIGTERM
para encerrar. Todos os processos que falharam ao terminar no tempo limite determinado recebem um sinalSIGKILL
. -
init.userspace_reboot.started.timeoutmillis
controla o tempo limite em milissegundos para a 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 fallback para reinicialização forçada será acionado. -
init.userspace_reboot.userdata_remount.timeoutmillis
controla o tempo limite em milissegundos para desmontaruserdata
. Se um dispositivo não conseguir liberar os dados douserdata
dentro do tempo limite determinado, um fallback para reinicialização forçada será acionado. -
init.userspace_reboot.watchdog.timeoutmillis
controla o tempo limite para um dispositivo inicializar com êxito (ou seja,sys.boot_completed=1
). Se um dispositivo não inicializar dentro do tempo limite determinado, um fallback para reinicialização forçada é acionado.
Personalizando 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
, o 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 padrão do android
.
Teste
O Android 11 inclui uma implementação de referência de uma reinicialização suave. Além disso, você pode verificar uma reinicialização suave usando testes CTS em UserspaceRebootHostTest
.