O Android 9 inclui as seguintes mudanças na especificação do motivo de inicialização do carregador de inicialização:
Motivos da inicialização
Um carregador de inicialização usa recursos de memória e hardware disponíveis de forma exclusiva para
determina por que um dispositivo foi reiniciado e comunica essa determinação pelo
adicionando androidboot.bootreason=<reason>
ao Android
kernel para lançamento. Depois, init
traduz isto
a linha de comando a ser propagada para a propriedade do Android
bootloader_boot_reason_prop
(ro.boot.bootreason
).
Para dispositivos lançados com o Android 12 ou mais recente,
usando a versão 5.10 ou mais recente do kernel, androidboot.bootreason=<reason>
é adicionado ao bootconfig em vez da linha de comando do kernel.
Especificações do motivo de inicialização
As versões anteriores do Android especificavam um formato de motivo de inicialização que não usava
espaços, era tudo em letras minúsculas, incluía poucos requisitos (como para
kernel_panic
, watchdog
.
cold
/warm
/hard
) e quais fizeram
permissões por outros motivos exclusivos. Essa especificação flexível resultou na
de centenas de motivos de inicialização personalizados (e às vezes insignificantes)
strings, o que, por sua vez, levou a uma situação impossível de gerenciar. A partir da data
Uma versão do Android, o grande impulso de conteúdo quase não analisável ou sem sentido
pelo carregador de inicialização criou problemas de conformidade para
bootloader_boot_reason_prop
:
Com o lançamento do Android 9, a equipe do Android
reconhece que o bootloader_boot_reason_prop
legado
muito importante e não pode ser reescrito em tempo de execução. Qualquer melhoria feita
a especificação do motivo da inicialização precisa vir das interações com
desenvolvedores de carregadores de inicialização
e ajustes no sistema existente. Para isso, o
A equipe do Android é:
- Interagir com desenvolvedores de carregadores de inicialização para incentivá-los a:
- Forneça motivos canônicos, analisáveis e reconhecíveis para
bootloader_boot_reason_prop
: - Participe do
system/core/bootstat/bootstat.cpp
ListakBootReasonMap
.
- Forneça motivos canônicos, analisáveis e reconhecíveis para
- Adicionar uma fonte controlada e gravável do ambiente de execução
system_boot_reason_prop
(sys.boot.reason
). Um conjunto limitado de apps do sistema (comobootstat
einit
) pode reescrever essa propriedade, mas todos os aplicativos podem ser receberam direitos sepolicy para lê-lo. - Informar aos usuários o motivo da inicialização para aguardar até que os dados do usuário sejam montados
antes de confiar no conteúdo da propriedade do motivo de inicialização do sistema
system_boot_reason_prop
:
Por que tão tarde? Enquanto o bootloader_boot_reason_prop
está disponível antes do lançamento
na inicialização, ele é bloqueado pela política de segurança do Android conforme necessário.
porque representa informações imprecisas, não analisáveis e não canônicas.
Na maioria das situações, somente desenvolvedores com profundo conhecimento do sistema de inicialização
precisa para acessar essas informações. Um modelo refinado, analisável e canônico
A API por motivo de inicialização com system_boot_reason_prop
pode ser confiável
e coletados com precisão somente após a montagem dos dados do usuário.
Especificamente:
- Antes dos dados do usuário serem montados,
system_boot_reason_prop
conterá o valor debootloader_boot_reason_prop
. - Depois que os dados do usuário forem montados,
system_boot_reason_prop
pode ser atualizado para ficar em conformidade ou para passar informações mais precisas.
Por esse motivo, o Android 9 estende o período de
antes que o motivo da inicialização possa ser oficialmente adquirido, mudando-o de
imediatamente preciso na inicialização (com bootloader_boot_reason_prop
).
para estar disponível somente após a montagem dos dados do usuário (com
system_boot_reason_prop
).
A lógica do bootstat depende de um modelo mais informativo e
bootloader_boot_reason_prop
: Quando essa propriedade usa um
previsível, melhora a precisão de todas as reinicializações controladas
de encerramento, o que refina e aumenta a precisão e o significado
de system_boot_reason_prop
.
Formato do motivo de inicialização canônico
O formato canônico do motivo de inicialização para bootloader_boot_reason_prop
no Android 9 usa a seguinte sintaxe:
<reason>,<subreason>,<detail>…
Regras de formatação:
- Letra minúscula
- Sem espaços em branco (usar sublinhado)
- Todos os caracteres para impressão
reason
,subreason
e um ou separados por vírgula maisdetail
instâncias.- Um
reason
obrigatório que representa a prioridade mais alta. motivo pelo qual o dispositivo teve que ser reinicializado ou desligado. - Um
subreason
opcional que representa um breve resumo de por que o dispositivo teve que ser reiniciado ou desligado (ou quem reinicializou ou encerrou o dispositivo). - Um ou mais valores
detail
opcionais. Umdetail
pode apontar para um subsistema para ajudar a determinar qual sistema específico resultou emsubreason
. É possível especificar váriosdetail
, que geralmente seguem uma hierarquia de importância. No entanto, também é aceitável denunciar várias Valores dedetail
com a mesma importância.
- Um
Um valor vazio para bootloader_boot_reason_prop
é considerado
ilegal (porque permite que outros agentes injetem um motivo de inicialização após o fato).
Requisitos de motivo
O valor atribuído para reason
(primeiro período, antes do encerramento ou
vírgula) precisa ser um dos seguintes conjuntos dividido em kernel, forte e contundente
motivos:
- conjunto de kernels:
- "
watchdog"
"kernel_panic"
- "
- conjunto forte:
"recovery"
"bootloader"
- sem fio:
"cold"
: Geralmente indica uma redefinição completa de todos os dispositivos, incluindo a memória."hard"
: Geralmente indica que o hardware tem o estado redefinido, eramoops
precisa reter conteúdo persistente."warm"
: Geralmente indica a memória e os dispositivos manter algum estado, e aramoops
(consultepstore
driver no kernel) contém conteúdo persistente."shutdown"
"reboot"
: Geralmente significa que o estadoramoops
é é desconhecido e o estado do hardware é desconhecido. Esse valor é genérico, Os valorescold
,hard
ewarm
fornecem pistas sobre a profundidade da redefinição do dispositivo.
Os carregadores de inicialização precisam fornecer um conjunto de kernel ou um conjunto sem fio reason
e
recomendamos que você forneça um subreason
se puder ser
determinados. Por exemplo, tocar e manter pressionado a tecla liga/desliga, que pode ou não ter
O backup do ramoops
teria o motivo de inicialização
"reboot,longkey"
.
Nenhum reason
do primeiro período pode fazer parte de nenhum subreason
ou
detail
No entanto, como os motivos do conjunto do kernel não podem ser produzidos pelo
espaço do usuário, "watchdog"
pode ser reutilizado após um motivo não definido,
junto com um detalhe da fonte (por exemplo,
"reboot,watchdog,service_manager_unresponsive"
ou
"reboot,software,watchdog"
).
Os motivos da inicialização não podem exigir conhecimento interno de especialistas para decifrar e/ou
os dados devem ser legíveis com um relatório intuitivo. Exemplos:
"shutdown,vbxd"
(ruim), "shutdown,uv"
(melhor),
"shutdown,undervoltage"
(preferencial).
Combinações de motivo/submotivo
O Android reserva um conjunto de reason
-subreason
que não devem ficar sobrecarregadas no uso normal, mas que podem ser usadas em
caso a caso se a combinação refletir com precisão os dados
condição. Confira alguns exemplos de combinações reservadas:
"reboot,userrequested"
"shutdown,userrequested"
"shutdown,thermal"
(dethermald
)"shutdown,battery"
"shutdown,battery,thermal"
(deBatteryStatsService
)"reboot,adb"
"reboot,shell"
"reboot,bootloader"
"reboot,recovery"
Para mais detalhes, consulte kBootReasonMap
em
system/core/bootstat/bootstat.cpp
e o git associado
histórico do registro de mudanças no repositório de origem do Android.
Relatar motivos de inicialização
Todos os motivos de inicialização, seja do carregador de inicialização ou gravados na inicialização canônica
motivo, precisa ser registrada na seção kBootReasonMap
do
system/core/bootstat/bootstat.cpp
. A
A lista kBootReasonMap
é uma mistura de apps compatíveis e legados
por motivos de não conformidade. Os desenvolvedores de carregadores de inicialização devem registrar
motivos de conformidade aqui (e não deve registrar motivos de não conformidade, a menos
o produto já foi enviado e não pode ser alterado).
Recomendamos o uso de entradas existentes e compatíveis em
system/core/bootstat/bootstat.cpp
e restrição de exercícios antes
usando uma string não compatível. A diretriz é:
- OK para informar
"kernel_panic"
do carregador de inicialização, já que obootstat
pode inspecionarramoops
parakernel_panic signatures
a fim de refinar a submotivos nosystem_boot_reason_prop
canônico. - Não certo para informar uma string que não está em conformidade em
kBootReasonMap
(como"panic")
da o carregador de inicialização, já que isso acabará invalidando a capacidade de refinarreason
.
Por exemplo, se kBootReasonMap
contiver "wdog_bark"
,
um desenvolvedor de carregadores de inicialização deve:
- Mude para
"watchdog,bark"
e adicione à lista emkBootReasonMap
. - Considere o que
"bark"
significa para quem não está familiarizado com a tecnologia e determinar se umsubreason
mais significativo é disponíveis.
Verificar a conformidade do motivo de inicialização
No momento, o Android não oferece um teste de CTS ativo que possa identificar acionar ou inspecionar todos os possíveis motivos que um carregador de inicialização pode apresentar; os parceiros ainda podem tentar executar um teste passivo para determinar a compatibilidade.
Como resultado, a conformidade com o carregador de inicialização exige que os desenvolvedores desse carregador
ade voluntariamente ao espírito das regras e diretrizes descritas acima.
Incentivamos esses desenvolvedores a contribuir com o AOSP (especificamente para
system/core/bootstat/bootstat.cpp
) e aproveite essa oportunidade como
para discussões sobre problemas relacionados à inicialização.