Este documento descreve como o GKI v5.10 para Android 12 é lançado, incluindo lançamentos de emergência semanais, mensais e fora de banda. O objetivo deste documento é fornecer aos OEMs uma orientação sobre onde retirar o GKI, bem como o processo para correções de emergência fora de banda. Os OEMs também podem usar o guia GKI Development para saber mais sobre como podem trabalhar com a equipe do Android Kernel para otimizar o kernel GKI para seus produtos.
Cadência de lançamento do GKI
O GKI é lançado em uma cadência mensal após o KMI Freeze a partir de 14 de julho de 2021. O gráfico a seguir ilustra a cadência do cronograma de lançamento.
| Compilações certificadas mensais da GKI | Data limite de check-in | Data de pré-carregamento do GKI pronto | Etiqueta | Confirmado? | |
|---|---|---|---|---|---|
| Julho (Congelamento KMI) | 14 de julho de 2021 | Final de julho | Android 12 Versão certificada AOSP - julho | Sim | |
| Agosto | 16 de agosto de 2021 | Fim de agosto | Android 12 Compilação certificada AOSP - agosto | Sim | |
| Setembro | 17 de setembro de 2021 | Final de setembro | Android 12 Versão certificada AOSP - setembro | Sim | |
| Outubro | 15 de outubro de 2021 | 29 de outubro de 2021 | Android 12 Versão Certificada AOSP - Outubro | Sim | |
| novembro | 12 de novembro de 2021 | 30 de novembro de 2021 | Android 12 Versão certificada AOSP - novembro | Sim | |
| dezembro | 10 de dezembro de 2021 | 22 de dezembro de 2021 | Android 12 Versão Certificada AOSP - Dezembro | Sim | |
| Janeiro | 14 de janeiro de 2022 | 31 de janeiro de 2022 | Android 12 Versão Certificada AOSP - Janeiro | Sim | |
| Fevereiro | 14 de fevereiro de 2022 | 28 de fevereiro de 2022 | Android 12 Versão certificada AOSP - fevereiro | Sim | |
| Marchar | 16 de março de 2022 | 31 de março de 2022 | Android 12 Versão certificada AOSP - março | Sim | |
| abril | 15 de abril de 2022 | 29 de abril de 2022 | Android 12 Versão Certificada AOSP - Abril | Sim | |
| Poderia | 16 de maio de 2022 | 31 de maio de 2022 | Android 12 Versão Certificada AOSP - Maio | Sim | |
| Junho | 15 de junho de 2022 | 30 de junho de 2022 | Android 12 Versão Certificada AOSP - Junho | Sim | |
| Julho | 15 de julho de 2022 | 29 de julho de 2022 | Android 12 Versão certificada AOSP - julho | Sim | |
| Agosto | 15 de agosto de 2022 | 31 de agosto de 2022 | Android 12 Compilação certificada AOSP - agosto | Sim | |
| Setembro | 16 de setembro de 2022 | 30 de setembro de 2022 | Android 12 Versão certificada AOSP - setembro | Sim | |
| Outubro | 14 de outubro de 2022 | 31 de outubro de 2022 | Android 12 Versão Certificada AOSP - Outubro | Sim | |
| novembro | 14 de novembro de 2022 | 30 de novembro de 2022 | Android 12 Versão certificada AOSP - novembro | Sim | |
| dezembro | 9 de dezembro de 2022 | 21 de dezembro de 2022 | Android 12 Versão Certificada AOSP - Dezembro | Sim |
Validade de compilação do GKI para OEMs
Os OEMs podem usar um Android GKI lançado recentemente. Os OEMs podem ser lançados com compilações certificadas pela GKI, desde que estejam em conformidade com os requisitos LTS do Android Security Bulletin (ASB).
Política de recuperação de versão certificada
- Os binários certificados pela GKI não têm suporte para respins depois que não estão mais em conformidade com os requisitos LTS no ASB. Por exemplo, a ramificação
android12-5.10-2021-11(5.10.66) não é compatível com respins após novembro de 2022, porque a ramificaçãoandroid12-5.10-2021-11(5.10.66) não está em conformidade com os requisitos LTS de ASB-2022-11. - Consulte o processo de respingo de emergência para obter mais informações.
Lançamentos semanais de desenvolvimento
versões são testadas com choco para garantir que passam uma barra de qualidade mínima .Os binários do GKI estão disponíveis para autoatendimento em ci.android.com à medida que as alterações são mescladas. As compilações semanais não serão certificadas, embora possam ser usadas como linha de base para desenvolvimento e teste. As compilações semanais não podem ser usadas para compilações de dispositivos de produção para usuários finais.
Lançamentos certificados mensais
As versões mensais do GKI contêm um boot.img testado que inclui um certificado inserido pelo Google para atestar que os binários foram criados a partir de uma linha de base de código-fonte conhecida.
A cada mês, um candidato a lançamento mensal da GKI (não certificado) é selecionado após a data limite de check-in, que geralmente é a segunda compilação semanal daquele mês. Depois que o candidato a lançamento mensal for selecionado, novas alterações não serão aceitas no lançamento desse mês. Durante o período de janela fechada, apenas correções para bugs que causam falha no teste podem ser abordadas. O release candidate passa pela garantia de qualidade - conforme descrito na seção de qualificação GKI - para garantir que os testes de conformidade sejam aprovados na compilação GSI+GKI com um dispositivo de referência, bem como o choco.
Figura 1. Cronograma de lançamento do GKI
Processo de respingo de emergência
Figura 2. O processo de respingo de emergência
Os OEMs podem precisar refazer o kernel para Aprovações Técnicas (TA) que estão bloqueando o problema. Respins são compatíveis com compilações de versão certificadas mensais e têm um tempo de resolução padrão esperado (ESRT) de dois dias úteis no fuso horário dos EUA.
ESRT é definido como o tempo necessário para entregar um binário GKI certificado que contém a correção, desde que tenha sido aprovado pela equipe GKI e revisado pelo OEM afetado. O ESRT é apenas uma estimativa e não deve ser interpretado como uma garantia.
Os OEMs que precisam de uma nova rodada para uma correção de bloqueio de TA precisam fazer o seguinte:
- Registre um bug no Issue Tracker e entre em contato com seu ponto de contato do Google imediatamente.
- Se você já tiver uma correção, o bug deve apontar para o envio do patch no AOSP para que o Google possa revisá-lo. Se o envio do patch não for viável, anexe o patch como um arquivo de texto ao bug no Issue Tracker .
- Se você ainda não tiver uma correção, o bug deve incluir o máximo de informações possível, incluindo o número da versão do kernel e os registros, para que o Google possa ajudar a depurar o problema.
- Depois que uma correção é acordada, o código da equipe do Google GKI revisa (CR+2) a alteração e testa a regressão. O teste inicia a contagem regressiva da ESRT e termina quando o binário é publicado em ci.android.com .
Qualificações GKI
| Tipos de compilações do GKI | Aplicação de qualidade | Notas |
|---|---|---|
| Semanalmente | Teste de choco
|
|
| Mensal (certificado) | Teste de choco
| |
| Respins (certificado) | Teste de choco
|
|
Onde obter artefatos de compilação
Artefatos para todos os lançamentos podem ser obtidos em ci.android.com .
Você pode encontrar mais informações sobre o CI, incluindo os resultados do teste no painel de integração contínua do Android .
Perguntas frequentes
É possível construir um novo binário GKI baseado em um GKI já lançado?
Sim, isso é conhecido como um respin. O processo de renovação é compatível desde que a versão GKI lançada (na qual a renovação é solicitada) esteja em conformidade com os requisitos de LTS no Boletim de segurança do Android (ASB).
É possível reproduzir binários GKI?
Sim, consulte o exemplo abaixo.
GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest
Para reproduzir o exemplo, baixe manifest_$id.xml e execute o seguinte comando:
repo init -u https://android.googlesource.com/kernel/manifestmv manifest_7364300.xml .repo/manifestsrepo init -m manifest_7364300.xml --depth=1repo sync # build the GKI images # You may want to use LTO=thin to build faster for developmentBUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh # (optional) build virtual platform modulesBUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.aarch64 build/build.sh
Você pode recuperar sua cópia do artefato GKI de out/.../dist .
O binário GKI (incluindo o patch de rotação de emergência) foi construído no
base de código mais recente?
Não. Respins contêm apenas patches que estão no topo dos kernels certificados mensais que foram escolhidos. Esses respins contêm todas as correções de bugs de bloqueio de inicialização relatadas até um determinado momento pelos OEMs usando a versão mensal base correspondente. Veja o exemplo a seguir de como esse tipo de cenário acontece.
- OEM1 e OEM2 decidem usar a versão binária GKI a partir de novembro de 2021.
- OEM1 e OEM2 encontram problemas que exigem patches para suporte. Esses patches podem ser diferentes ou podem ser iguais.
- As repetições sobre o binário de novembro de 2021 têm correções de bloqueio de lançamento relatadas por OEM1 e OEM2 durante a janela de repetição, mas nada mais.
- Os problemas mencionados no segundo item também estão incluídos nas versões mensais subsequentes da GKI.
A nova rodada de outubro tem todos os patches enviados pelo OEM, mas outros patches OEM
nos afetam, porque não foram testados especificamente com nossos produtos. É possível incluir apenas o nosso patch?
Isso não é possível. Um caminho de respin "por OEM" atualmente não é escalável. Em vez disso, a equipe da GKI examina cada alteração que entra em compilações de nova versão e testa as alterações com todo o hardware disponível antes de criar uma nova compilação. Se a equipe da GKI descobrir que o problema é específico de um OEM/dispositivo/modelo, a equipe da GKI pode garantir que o código adicionado pela alteração seja executado apenas no dispositivo/modelo/SKU afetado.
O principal benefício dos respins unificados é que todos os dispositivos que usam a mesma base de lançamento se beneficiam uns dos outros, especialmente se os bugs descobertos forem genéricos e aplicáveis a todos os usuários. Os principais erros do kernel encontrados em testes de operadoras são um exemplo específico desse conceito.
Existem situações em que o Google fornece informações específicas sobre patches de OEM e cenários de problemas para que os OEMs possam avaliar o impacto e o risco de implementar os patches em seus produtos?
O Google nunca adicionará uma alteração a uma nova versão até que o problema seja entendido e todos os detalhes tenham sido coletados. Isso é visto no changelog (mensagem de confirmação). O Google não revela qual dispositivo específico isso afeta, mas os OEMs sempre podem encontrar a descrição do problema e a solução no registro de alterações.