Este documento descreve como a GKI é lançada, incluindo lançamentos de emergência semanais, mensais e fora da banda. O objetivo deste documento é oferecer aos OEMs uma diretriz sobre onde coletar a GKI, bem como o processo para correções de emergência fora da banda. Os OEMs também podem usar o Guia de desenvolvimento de GKI para saber mais sobre como podem trabalhar com a equipe do kernel do Android para otimizar o kernel de GKI para os produtos deles.
Cadência de lançamento de GKI
O GKI é lançado mensalmente após o congelamento do KMI.
Versão 13, 14 e 15 da GKI do Android
A tabela a seguir é aplicável apenas a android13-5.10, android13-5.15 e android14-6.1.
| Builds mensais certificados de GKI | Data limite para check-in | Data de pré-carregamento de GKI | Confirmado? |
|---|---|---|---|
| Outubro | 14 de outubro de 2022 | 31 de outubro de 2022 | Sim |
| Novembro | 14 de novembro de 2022 | 30 de novembro de 2022 | Sim |
| Dezembro | 9 de dezembro de 2022 | 21 de dezembro de 2022 | Sim |
| Janeiro | 17 de janeiro de 2023 | 31 de janeiro de 2023 | Sim |
| Fevereiro | 15 de fevereiro de 2023 | 28 de fevereiro de 2023 | Sim |
| Março | 15 de março de 2023 | 31 de março de 2023 | Sim |
| Abril | 13 de abril de 2023 | 28 de abril de 2023 | Sim |
| Maio | 17 de maio de 2023 | 31 de maio de 2023 | Sim |
| Junho | 15 de junho de 2023 | 30 de junho de 2023 | Sim |
| Julho | 18 de julho de 2023 | 31 de julho de 2023 | Sim |
| Agosto | 16 de agosto de 2023 | 31 de agosto de 2023 | Sim |
| Setembro | 14 de setembro de 2023 | 29 de setembro de 2023 | Sim |
| Outubro | 18 de outubro de 2023 | 31 de outubro de 2023 | Sim |
| Novembro | 10 de novembro de 2023 | 30 de novembro de 2023 | Sim |
| Dezembro | 7 de dezembro de 2023 | 22 de dezembro de 2023 | Sim |
| Janeiro | 16 de janeiro de 2024 | 31 de janeiro de 2024 | Sim |
| Fevereiro | 13 de fevereiro de 2024 | 29 de fevereiro de 2024 | Sim |
| Março | 13 de março de 2024 | 29 de março de 2024 | Sim |
| Abril | 16 de abril de 2024 | 30 de abril de 2024 | Sim |
| Maio | 14 de maio de 2024 | 31 de maio de 2024 | Sim |
| Junho | 12 de junho de 2024 | 28 de junho de 2024 | Sim |
| Julho | 16 de julho de 2024 | 31 de julho de 2024 | Sim |
| Agosto | 15 de agosto de 2024 | 30 de agosto de 2024 | Sim |
| Setembro | 17 de setembro de 2024 | 30 de setembro de 2024 | Sim |
| Outubro | 15 de outubro de 2024 | 31 de outubro de 2024 | Sim |
| Novembro | 11 de novembro de 2024 | 27 de novembro de 2024 | Sim |
| Dezembro | 6 de dezembro de 2024 | 23 de dezembro de 2024 | Sim |
A partir de janeiro de 2024, vamos retomar os lançamentos mensais do android14-5.15
de acordo com a frequência mensal especificada na tabela abaixo.
android15-6.6 vai seguir a mesma cadência de lançamento a partir de julho de 2024.
| Builds mensais certificados de GKI | Data limite para check-in | Data de pré-carregamento de GKI | Confirmado? |
|---|---|---|---|
| Janeiro | 16 de janeiro de 2024 | 31 de janeiro de 2024 | Sim |
| Fevereiro | 13 de fevereiro de 2024 | 29 de fevereiro de 2024 | Sim |
| Março | 4 de março de 2024 | 15 de março de 2024 | Sim |
| Abril | 1º de abril de 2024 | 17 de abril de 2024 | Sim |
| Maio | 1o de maio de 2024 | 17 de maio de 2024 | Sim |
| Junho | 3 de junho de 2024 | 17 de junho de 2024 | Sim |
| Julho | 1º de julho de 2024 | 15 de julho de 2024 | Sim |
| Agosto | 1º de agosto de 2024 | 16 de agosto de 2024 | Sim |
| Setembro | 2 de setembro de 2024 | 16 de setembro de 2024 | Sim |
| Outubro | 1o de outubro de 2024 | 14 de outubro de 2024 | Sim |
| Novembro | 1º de novembro de 2024 | 15 de novembro de 2024 | Sim |
| Dezembro | 2 de dezembro de 2024 | 16 de dezembro de 2024 | Sim |
Versão GKI do Android 12
Após maio de 2024, os lançamentos da GKI android12-5.10 são trimestrais e
publicados no meio do mês.
A tabela a seguir é aplicável apenas ao android12-5.10.
| Builds mensais certificados de GKI | Data limite para check-in | Data de pré-carregamento de GKI | Confirmado? |
|---|---|---|---|
| Julho | 3 de julho de 2023 | 14 de julho de 2023 | Sim |
| Setembro | 1o de setembro de 2023 | 15 de setembro de 2023 | Sim |
| Novembro | 3 de novembro de 2023 | 17 de novembro de 2023 | Sim |
| Janeiro | 5 de janeiro de 2024 | 19 de janeiro de 2024 | Sim |
| Março | 4 de março de 2024 | 15 de março de 2024 | Sim |
| Maio | 1o de maio de 2024 | 17 de maio de 2024 | Sim |
| Agosto | 1º de agosto de 2024 | 16 de agosto de 2024 | Sim |
| Novembro | 1º de novembro de 2024 | 15 de novembro de 2024 | Sim |
| Fevereiro | 3 de fevereiro de 2025 | 17 de fevereiro de 2025 | Sim |
Validade do build de GKI para OEMs
OEMs podem usar uma GKI do Android lançada recentemente. Os OEMs podem ser lançados com builds certificados pela GKI, desde que estejam em conformidade com os requisitos de LTS no Boletim de segurança do Android (ASB).
Versões de desenvolvimento semanais
As versões são testadas com o Cuttlefish para garantir que passem em uma barra de qualidade mínima.Os binários de GKI estão disponíveis para autoatendimento em ci.android.com à medida que as mudanças são mescladas. Os builds semanais não serão certificados, mas podem ser usados como valor de referência para desenvolvimento e testes. Os builds semanais não podem ser usados em builds de dispositivos de produção para usuários finais.
Lançamentos certificados mensais
As versões mensais de GKI contêm um boot.img testado, que inclui um certificado
inserido pelo Google para atestar que os binários foram criados com base em um valor de referência
de código-fonte conhecido.
Todo mês, um candidato a lançamento mensal de GKI (não certificado) é selecionado após a data limite de check-in, que geralmente é o segundo build semanal do mês. Depois que o candidato a lançamento mensal for selecionado, novas mudanças não serão aceitas na versão desse mês. Durante o período de janela fechada, apenas correções de bugs que causam falhas no teste podem ser abordadas. O candidato a lançamento passa por um controle de qualidade, conforme descrito na seção de qualificação de GKI, para garantir que os testes de conformidade sejam aprovados no build de GSI+GKI com um dispositivo de referência, assim como o Cutlefish.
Figura 1. Cronograma de lançamento do GKI
Processo de resposta de emergência
Uma respin se refere ao processo de refusão, recriação, novo teste e recertificação de um binário após uma versão pública do kernel de GKI. É possível solicitar uma nova verificação de um binário certificado para qualquer uma das seguintes circunstâncias:
- Atualizar uma lista de símbolos.
- Para aplicar uma correção a um bug, incluindo bugs encontrados durante a aprovação do laboratório da operadora.
- Adicionar um gancho para fornecedores.
- Aplicar um patch a um recurso atual.
- Para aplicar um patch de segurança (após seis meses).
Os patches de segurança são mesclados automaticamente em um branch da versão por até seis meses após o lançamento. Após o limite de seis meses, você precisa solicitar uma nova resposta para aplicar patches de segurança a uma ramificação.
Antes de solicitar uma nova verificação, observe as seguintes diretrizes:
As respins são permitidas somente em ramificações de lançamento após o lançamento de uma versão pública inicial de um build mensal.
As solicitações de Respin são aceitas somente para uma determinada ramificação de versão por um máximo de seis meses após a versão pública inicial. Depois de seis meses, as ramificações ficam qualificadas para respin apenas para patches de segurança citados em um Boletim de segurança do Android.
Quando os requisitos de LTS definidos pelo Boletim de segurança do Android (ASB, na sigla em inglês) fazem com que a ramificação não esteja em conformidade, ela é descontinuada. Solicitações de respin para ramificações obsoletas não são aceitas. A data de descontinuação de uma determinada ramificação de GKI está incluída nas notas mensais de build da versão de GKI em Versões. Para o planejamento futuro, os requisitos de LTS são atualizados anualmente em maio e novembro. Por exemplo, a ramificação
android12-5.10-2023-07(5.10.177) não tem suporte para respins após 1o de maio de 2024 porque a ramificaçãoandroid12-5.10-2023-07(5.10.177) não está em conformidade com os requisitos de LTS do ASB-2024-05.As respins são aplicáveis apenas a correções de bugs urgentes, atualizações de listas de símbolos ou para aplicar um patch para corrigir um recurso existente.
Todos os patches que vão para a ramificação de lançamento mensal já precisam estar mesclados à ramificação principal de desenvolvimento de GKI. Por exemplo, se um patch for necessário para um respin de
android12-5.10-2022-09, ele já terá que estar mesclado comandroid12-5.10.Você precisa escolher a dedo os patches da ramificação principal de desenvolvimento de GKI e fazer upload do patch para a ramificação de lançamento mensal.
Na solicitação de resposta, você precisa atribuir uma prioridade (urgência) a ela. Essa prioridade ajuda a equipe de GKI a atender melhor os parceiros em tempo hábil. Para solicitações críticas ou urgentes, marque a prioridade como P0. Para solicitações P0 e P1, você também precisa justificar a urgência. A tabela abaixo fornece um mapeamento da prioridade do bug e do tempo para resolução (ESRT, na sigla em inglês):
Prioridade ESRT P0 2 dias úteis P1 5 dias úteis P2 10 dias úteis P3 15 dias úteis
É necessário enviar uma solicitação de respin separada para cada ramificação de lançamento. Por exemplo, se uma respin for necessária para
android12-5.10-2022-08eandroid12-5.10-2022-09, será preciso criar duas solicitações de respin.Depois que uma versão é fornecida e uma solicitação de respin é marcada como corrigida, não reabra a solicitação para adicionar mais CLs. Envie uma nova solicitação de respin se houver patches adicionais que precisam ser mesclados.
Para cada CL em questão, adicione as seguintes tags. O andamento na solicitação de respin é bloqueado sem essas informações.
Bug: o ID do bug precisa ser adicionado à mensagem de confirmação para cada CL.Change-Id: precisa ser idêntico ao Change-Id da alteração da ramificação base.
Se uma solicitação de respin exigir sua resposta e você não responder em até três dias úteis, a prioridade será reduzida em um nível (por exemplo, P0 será rebaixado para P1). Se você não responder por duas semanas, o bug será marcado como Sem correção (obsoleto).
Enviar uma solicitação de respin
O diagrama a seguir mostra o processo de respin. O processo começa quando o parceiro OEM (você) envia a solicitação de resposta.
Figura 2. O processo de respin
Para entrar no processo de respin, siga estas etapas:
- Preencha o formulário de solicitação de GKI Respin
e entre em contato com o gerente técnico de contas do Google imediatamente. Esse formulário
cria um bug de solicitação de respin de GKI. Os bugs da solicitação de respin ficam visíveis para você
(o requerente), a equipe de GKI e as pessoas específicas adicionadas à
lista de CC do bug.
- Se você já tiver uma correção, a solicitação precisará apontar para o envio de patch no AOSP para que o Google possa analisá-la. Se o envio do patch não for viável, ele precisará ser anexado à solicitação como um arquivo de texto.
- Se você não tiver uma correção, a solicitação precisará conter 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.
- A equipe de GKI do Google analisa e aprova a solicitação ou a atribui de volta a você se mais informações forem necessárias.
- Depois que uma correção for acordada, o código da equipe de GKI do Google vai analisar (CR+2) a mudança. A revisão começa o prazo da ESRT. A equipe de GKI mescla, cria, testa a regressão e certifica a mudança.
- O binário é liberado em ci.android.com. O período de ESRT termina, e a equipe de GKI do Google marca a solicitação como corrigida e faz referência ao build respin. O build respin também será postado na página de builds de lançamento da imagem genérica do kernel (GKI, na sigla em inglês).
Qualificações de GKI
| Tipos de builds de GKI | Aplicação da qualidade | Anotações |
|---|---|---|
| Semanal | Teste do Cuttlefish
|
|
| Mensalmente (certificado) | Teste do Cuttlefish
|
|
| Respins (certificado) | Teste do Cuttlefish
|
|
Onde conseguir artefatos de build
Os artefatos de todas as versões podem ser encontrados em ci.android.com.
Você pode encontrar mais informações sobre CI, incluindo os resultados do teste no painel de integração contínua do Android.
Perguntas frequentes
É possível criar um novo binário de GKI com base em uma GKI já lançada?
Sim, isso é conhecido como uma nova resposta. O processo de respin tem suporte, desde que o build GKI lançado (em que a respin seja solicitada) esteja em conformidade com os requisitos de LTS do Boletim de segurança do Android (ASB, na sigla em inglês).
É possível reproduzir binários de 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, faça o download de 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
É possível recuperar sua cópia do artefato de GKI em out/.../dist.
O binário GKI (incluindo o patch de rotação de emergência) foi criado na base de código mais recente?
Não. As respins contêm apenas patches que estão sobre os kernels certificados mensais que foram escolhidos. Essas respostas contêm todas as correções de bugs de bloqueio de lançamento informadas até qualquer momento pelos OEMs que usam a versão mensal básica correspondente. Confira o exemplo a seguir de como esse tipo de cenário acontece.
- O OEM1 e o OEM2 decidiram usar a versão do binário GKI a partir de novembro de 2021.
- O OEM1 e o OEM2 encontram problemas que exigem patches para compatibilidade. Esses patches podem ser diferentes ou iguais.
- Os respins sobre o binário de novembro de 2021 têm correções de bloqueio de inicialização informadas pelo OEM1 e OEM2 durante a janela de respin, mas nada além disso.
- Os problemas mencionados no segundo marcador também são incluídos nos próximos lançamentos mensais de GKI.
A respin de outubro tem todos os patches enviados pelo OEM, mas outros patches do OEM nos afetam porque eles não foram testados especificamente com nossos produtos. É possível incluir apenas nosso patch?
Isso não é possível. Um caminho de resposta "por OEM" não é escalonável no momento. Em vez disso, a equipe de GKI examina cada mudança realizada nos builds respinativos e testa as mudanças com todo o hardware disponível antes de criar um novo build. Se a equipe de GKI descobrir que o problema é específico a um OEM/dispositivo/modelo, ela poderá garantir que o código adicionado pela mudança seja executado apenas no dispositivo/modelo/SKU afetado.
O principal benefício das respins unificadas é que todos os dispositivos que usam a mesma base de versão se beneficiam uns dos outros, especialmente se os bugs descobertos forem genéricos e aplicáveis a todos os usuários. Os principais bugs do kernel encontrados nos testes da operadora são um exemplo específico desse conceito.
Há 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 da implementação dos patches nos produtos deles?
O Google nunca adicionará uma alteração a um build respin até que o problema seja compreendido e todos os detalhes tenham sido coletados. Isso é visto no registro de alterações (mensagem de confirmação). O Google não revela qual dispositivo específico ele afeta, mas os OEMs sempre podem encontrar a descrição e a solução do problema no registro de mudanças.