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

Motivo de inicialização canônica

O Android 9 inclui as seguintes alterações na especificação do motivo de inicialização do carregador de inicialização.

Motivos de inicialização

A usa bootloader exclusivamente-disponíveis de hardware e recursos de memória para determinar por que um dispositivo reiniciado, em seguida, comunica que a determinação adicionando androidboot.bootreason=<reason> para a linha de comando do kernel Android para o seu lançamento. init , em seguida, traduz essa linha de comando para propagar para a propriedade Android bootloader_boot_reason_prop ( ro.boot.bootreason ). Para dispositivos de lançamento com Android 12 ou mais tarde, o uso do kernel versão 5.10 ou superior, androidboot.bootreason=<reason> é adicionado à bootconfig em vez da linha de comando do kernel.

Especificações do motivo de inicialização

Versões anteriores do Android especificado um formato motivo de inicialização que é utilizado sem espaços, era tudo em minúsculas, incluídos alguns requisitos (como para relatar kernel_panic , watchdog , cold / warm / hard ), e que fez subsídios para outras razões únicas. Essa especificação solta resultou na proliferação de centenas de strings de razão de inicialização customizadas (e às vezes sem sentido), o que por sua vez levou a uma situação incontrolável. A partir da versão Android atual, o puro impulso de perto o conteúdo unparseable ou sem sentido movida pelo bootloader criou problemas de conformidade para bootloader_boot_reason_prop .

Com o lançamento Android 9, a equipe do Android reconhece que o legado bootloader_boot_reason_prop tem impulso substancial e não pode ser re-escrita em tempo de execução. Quaisquer melhorias na especificação do motivo de inicialização devem, portanto, vir de interações com os desenvolvedores do carregador de inicialização e ajustes no sistema existente. Para isso, a equipe do Android é:

  • Envolvendo os desenvolvedores de bootloader para incentivá-los a:
    • Fornecer razões canônicas, analisável e reconhecível para bootloader_boot_reason_prop .
    • Participar do system/core/bootstat/bootstat.cpp kBootReasonMap lista.
  • Adição de uma fonte de tempo de execução controlada e regravável do system_boot_reason_prop ( sys.boot.reason ). Um conjunto limitado de aplicações do sistema (como bootstat e init ) pode reescrever essa propriedade, mas todos os aplicativos podem ser concedidos direitos sepolicy para lê-la.
  • Informar os usuários da razão de inicialização que esperar até depois userdata é montado antes de confiar o conteúdo na inicialização do sistema propriedade razão system_boot_reason_prop .

Por que tão tarde? Enquanto bootloader_boot_reason_prop está disponível no início de boot, que é bloqueado pela política de segurança Android em uma base como-necessário porque representa informações imprecisas, unparseable e não-canônico. Na maioria das situações, apenas os desenvolvedores com profundo conhecimento do sistema de inicialização precisam acessar essas informações. Um refinado, analisável, e API canónica para a razão de inicialização através system_boot_reason_prop pode ser fiável e precisa apanhado só depois UserData tem montado. Especificamente:

  • Antes userdata montou, system_boot_reason_prop irá conter o valor de bootloader_boot_reason_prop .
  • Depois userdata montou, system_boot_reason_prop pode ser atualizado para ser compatível ou para relatar informações mais precisas.

Por esta razão, Android 9 estende o período de tempo antes que a razão de inicialização pode ser adquirido oficialmente, mudando-o de ser imediatamente precisos na inicialização (com bootloader_boot_reason_prop ) para estar disponível somente após userdata montou (com system_boot_reason_prop ).

Lógica Bootstat depende de um mais informativo e compatível bootloader_boot_reason_prop . Quando essa propriedade usa um formato previsível, melhora a precisão de todos os cenários de reinicialização e desligamento controlado, o que por sua vez refina e amplia a precisão e significado de system_boot_reason_prop .

Formato de motivo de inicialização canônico

O formato motivo de inicialização canônico para bootloader_boot_reason_prop no Android 9 usa a seguinte sintaxe:

<reason>,<subreason>,<detail>…

Regras de formatação:

  • Minúsculas
  • Sem espaços em branco (use sublinhado)
  • Todos os caracteres imprimíveis
  • Separados por vírgulas reason , subreason , e um ou mais detail (s).
    • Um exigido reason que representa a maior razão prioridade porque o dispositivo teve que reiniciar ou desligamento.
    • Um opcional subreason que representa um breve resumo de por que o dispositivo teve que reiniciar ou desligamento (ou quem reiniciado ou desligamento do dispositivo).
    • Um ou mais opcionais detail valores. Um detail podem apontar para um subsistema para ajuda na determinação de qual sistema específico resultou na subreason . Você pode especificar vários detail valores, que deve geralmente seguem uma hierarquia de importância. No entanto, também é aceitável para relatar múltiplas detail valores de igual importância.

Um valor vazio para bootloader_boot_reason_prop é considerado ilegal (como este permite que outros agentes para injectar uma razão de arranque após o facto).

Requisitos de razão

O valor dado para a reason (primeiro período, antes da terminação ou vírgula) deve ser do seguinte conjunto dividido em kernel, forte, e razões rombas:

  • conjunto de kernel:
    • " watchdog"
    • "kernel_panic"
  • conjunto forte:
    • "recovery"
    • "bootloader"
  • conjunto sem corte:
    • "cold" . Geralmente indica uma reinicialização completa de todos os dispositivos, incluindo a memória.
    • "hard" . Geralmente indica o hardware tem a sua redefinição de Estado e ramoops deve reter o conteúdo persistente.
    • "warm" . Geralmente indica a memória e os dispositivos de manter algum estado, e os ramoops (ver pstore motorista em kernel) Backing Store contém conteúdo persistente.
    • "shutdown"
    • "reboot" . Geralmente significa que o ramoops estado é desconhecido e o estado hardware é desconhecida. Este valor é um genérico como a cold , hard , e warm valores proporcionar pistas sobre a profundidade da reinicialização para o dispositivo.

Bootloaders devem fornecer um conjunto de kernel ou um conjunto contundente reason , e são fortemente encorajados a fornecer uma subreason se ele pode ser determinado. Por exemplo, uma tecla de alimentação pressão longa que podem ou não podem ter ramoops de backup teria a razão de inicialização "reboot,longkey" .

Nenhum primeiro-span reason pode ser parte de qualquer subreason ou detail . No entanto, porque razões indicadas núcleo não pode ser produzido por espaço utilizador, "watchdog" pode ser reutilizada depois de um motivo conjunto romba, juntamente com um pormenor da fonte (por exemplo, "reboot,watchdog,service_manager_unresponsive" , ou "reboot,software,watchdog" )

Os motivos de inicialização não devem exigir conhecimento interno especializado para decifrar e / ou devem ser legíveis por humanos com um relatório intuitivo. Exemplos: "shutdown,vbxd" (ruim), "shutdown,uv" (melhor), "shutdown,undervoltage" (preferencial).

Combinações Razão-Sub-razão

Reservas Android um conjunto de reason - subreason combinações que não deve ser sobrecarregado em uso normal, mas pode ser usado em uma base caso a caso, se a combinação reflete com precisão a condição de associado. Exemplos de combinações reservadas incluem:

  • "reboot,userrequested"
  • "shutdown,userrequested"
  • "shutdown,thermal" (a partir de thermald )
  • "shutdown,battery"
  • "shutdown,battery,thermal" (de BatteryStatsService )
  • "reboot,adb"
  • "reboot,shell"
  • "reboot,bootloader"
  • "reboot,recovery"

Para mais detalhes, consulte kBootReasonMap no system/core/bootstat/bootstat.cpp ea história git changelog associado no repositório de origem Android.

Relatando motivos de inicialização

Todos os motivos de inicialização, a partir do bootloader ou registados a razão de inicialização canónico, deve ser registrado no kBootReasonMap seção do system/core/bootstat/bootstat.cpp . O kBootReasonMap lista é uma mistura de razões complacente e legado não conformes. Os desenvolvedores do bootloader devem registrar apenas os novos motivos de conformidade aqui (e não devem registrar os motivos de não conformidade, a menos que o produto já tenha sido enviado e não possa ser alterado).

É altamente recomendável usar entradas existentes, compatíveis no system/core/bootstat/bootstat.cpp e exercitar contenção antes de utilizar uma string não-conformes. Como diretriz, é:

  • OK para relatar "kernel_panic" do bootloader, como bootstat pode ser capaz de inspecionar ramoops para kernel_panic signatures para refinar os subreasons na canônica system_boot_reason_prop .
  • Não OK para informar uma string não conforme em kBootReasonMap (como "panic") a partir do bootloader, como isso acabará por quebrar a capacidade de refinar a reason .

Por exemplo, se kBootReasonMap contém "wdog_bark" , um desenvolvedor bootloader deve:

  • Alterar para "watchdog,bark" e adicionar à lista no kBootReasonMap .
  • Considere o que "bark" meios para aqueles não familiarizados com a tecnologia e determinar se a mais significativa subreason está disponível.

Verificando a conformidade do motivo de inicialização

No momento, o Android não fornece um teste CTS ativo que possa acionar ou inspecionar com precisão todos os motivos de inicialização possíveis que um carregador de inicialização poderia fornecer; os parceiros ainda podem tentar executar um teste passivo para determinar a compatibilidade.

Como resultado, a conformidade do bootloader exige que os desenvolvedores do bootloader sigam voluntariamente o espírito das regras e diretrizes descritas acima. Instamos esses desenvolvedores contribuem para AOSP (especificamente ao system/core/bootstat/bootstat.cpp ) e usar esta oportunidade como um fórum para discussões sobre questões razão boot.