Motivo de inicialização canônico

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 Lista kBootReasonMap.
• 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 (como bootstat e init) 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 de bootloader_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 mais detail 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. Um detail pode apontar para um subsistema para ajudar a determinar qual sistema específico resultou em subreason. É possível especificar vários detail, que geralmente seguem uma hierarquia de importância. No entanto, também é aceitável denunciar várias Valores de detail com a mesma importância.

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, e ramoops precisa reter conteúdo persistente.
  • "warm": Geralmente indica a memória e os dispositivos manter algum estado, e a ramoops (consulte pstore driver no kernel) contém conteúdo persistente.
  • "shutdown"
  • "reboot": Geralmente significa que o estado ramoops é é desconhecido e o estado do hardware é desconhecido. Esse valor é genérico, Os valores cold, hard e warm 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" (de thermald)
• "shutdown,battery"
• "shutdown,battery,thermal" (de BatteryStatsService)
• "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 o bootstat pode inspecionar ramoops para kernel_panic signatures a fim de refinar a submotivos no system_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 refinar reason.

Por exemplo, se kBootReasonMap contiver "wdog_bark", um desenvolvedor de carregadores de inicialização deve:

• Mude para "watchdog,bark" e adicione à lista em kBootReasonMap.
• Considere o que "bark" significa para quem não está familiarizado com a tecnologia e determinar se um subreason 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.