Processo de lançamento da imagem genérica do kernel (GKI, na sigla em inglês)

Esta página descreve como a GKI é lançada, incluindo lançamentos semanais, mensais e fora da banda de emergência. O objetivo deste documento é fornecer aos OEMs uma orientação sobre onde encontrar o GKI, bem como o processo para correções de emergência fora da banda. Os OEMs também podem usar o desenvolvimento do GKI para saber mais sobre como trabalhar com a equipe do kernel do Android para otimizar o kernel do GKI para os produtos.

Cadência de lançamento do GKI

O GKI é lançado em uma cadência mensal após o congelamento do KMI.

Lançamento da GKI do Android 13, 14 e 15

A tabela a seguir é aplicável apenas a android13-5.10, android13-5.15 e android14-5.15.

A tabela a seguir é aplicável apenas a android14-6.1 e android15-6.6.

Lançamento da GKI do Android 12

Após maio de 2024, os lançamentos do GKI android12-5.10 serão em uma cadência trimestral e publicados no meio do mês. A tabela a seguir é aplicável apenas a android12-5.10.

Validade do build do GKI para OEMs

Os OEMs podem usar um GKI do Android lançado recentemente. Os OEMs podem lançar com builds certificados pelo GKI, desde que estejam em conformidade com os requisitos de LTS no boletim de segurança do Android (ASB).

Versões de desenvolvimento semanais

Os binários do GKI estão disponíveis para autoatendimento no CI do Android à medida que as mudanças são mescladas. Os builds semanais não serão certificados, mas podem ser usados como uma referência para desenvolvimento e teste. Os builds semanais não podem ser usados para builds de dispositivos de produção para usuários finais.

Versões certificadas 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 um perfil 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, somente correções de bugs que causam falhas no teste podem ser resolvidas. O candidato à versão passa por garantia de qualidade, conforme descrito na seção de qualificação do GKI, para garantir que os testes de compliance sejam aprovados no build do GSI+GKI com um dispositivo de referência e o cuttlefish.

Figura 1. Cronograma de lançamento do GKI

Processo de resposta de emergência

Um respin se refere ao processo de reemergência, reconstrução, reavaliação e recertificação de um binário após uma versão pública do kernel do GKI. É possível solicitar uma nova versão de um binário certificado para qualquer uma das seguintes circunstâncias:

• Para atualizar uma lista de símbolos.
• Para corrigir um bug, incluindo bugs encontrados durante a aprovação de laboratório da operadora.
• Adicionar um gancho para fornecedores.
• Para 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 período de seis meses, é necessário solicitar uma nova versão para aplicar patches de segurança a uma ramificação.

Diretrizes para solicitações de repetiçã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 estarão qualificadas para respin apenas para patches de segurança citados em um Boletim de segurança do Android.

• Quando os requisitos do 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. Pedidos de repetição para filiais descontinuadas não são aceitos. A data de descontinuação de uma determinada ramificação de lançamento do GKI é incluída nas notas mensais do build de lançamento do GKI em Lançamentos. Para planejamentos futuros, os requisitos de LTS são atualizados em maio e novembro anualmente. Por exemplo, a ramificação android12-5.10-2023-07 (5.10.177) não tem suporte para respins após 1º de maio de 2024, porque a ramificação android12-5.10-2023-07 (5.10.177) não está em conformidade com os requisitos de LTS do ASB-2024-05.

• Os repins são aplicáveis apenas para 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 uma repetição de android12-5.10-2022-09, ele já precisa ser mesclado em android12-5.10.

• Você precisa escolher patches do branch de desenvolvimento principal do GKI e fazer o upload deles para o branch 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

• Você precisa enviar uma solicitação de respin separada por ramificação de lançamento. Por exemplo, se um respin for necessário para android12-5.10-2022-08 e android12-5.10-2022-09, você precisará 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. Você precisa enviar uma nova solicitação de repetição se houver outros patches que precisem ser mesclados.

• Para cada CL em consideração, adicione as seguintes tags.

  • Bug: o ID do bug precisa ser adicionado à mensagem de confirmação de cada CL.
  • Change-Id: precisa ser idêntico ao Change-Id da mudança 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 em duas semanas, o bug será marcado como Won't Fix (Obsolete).

Enviar um pedido de reenvio

O diagrama a seguir mostra o processo de respin. O processo começa quando o parceiro OEM (você) envia a solicitação de respin.

Figura 2. O processo de respin

Para entrar no processo de respin:

1. 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 respinho do GKI. Os bugs de solicitação de repetição são visíveis para você (o solicitante), a equipe do GKI e pessoas específicas que você adicionar à lista de CC do bug.
   • Se você já tiver uma correção, a solicitação vai apontar para o envio do patch no AOSP para que o Google possa analisá-lo. Se não for possível enviar o patch, ele precisará ser anexado como um arquivo de texto à solicitação.
   • 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.
2. 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.
3. Depois que um fix é acordado, a equipe de GKI do Google analisa o código (CR+2) da mudança. A revisão inicia o período do ESRT. A equipe da GKI mescla, cria, testa para regressão e certifica a mudança.
4. O binário é lançado em ci.android.com. O período do ESRT termina, e a equipe do Google GKI marca a solicitação como corrigida e faz referência ao build de respin. O build de respin também será publicado na página Builds de lançamento da imagem genérica do kernel (GKI).

Qualificações do GKI

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 a CI, incluindo os resultados do teste no painel Integração contínua do Android.

Perguntas frequentes

Confira algumas perguntas frequentes relacionadas ao processo de lançamento da GKI.

É possível criar um novo binário da GKI com base em uma GKI já lançada?

Sim, isso é conhecido como respin. O processo de respin é aceito desde que o build GKI lançado (em que o respin é solicitado) esteja em conformidade com os requisitos de LTS no boletim de segurança do Android (ASB, na sigla em inglês).

É possível reproduzir binários de GKI?

Sim, confira um exemplo:

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/manifest
mv manifest_7364300.xml .repo/manifests
repo init -m manifest_7364300.xml --depth=1
repo sync
# build the GKI images
# You may want to use LTO=thin to build faster for development
BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
# (optional) build virtual platform modules
BUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.aarch64 build/build.sh

É possível recuperar a cópia do artefato do GKI em out/.../dist.

O binário GKI (incluindo o patch de emergência) foi criado na base de código mais recente?

Não. Os respins contêm apenas patches que estão acima dos kernels certificados mensais 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.

• OEM1 e OEM2 decidem usar a versão binária do GKI a partir de novembro de 2021.
• OEM1 e OEM2 encontram problemas que exigem patches para suporte. Esses patches podem ser diferentes ou iguais.
• As respins 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 respin, mas nada mais.
• Os problemas mencionados no segundo ponto também são incluídos nas versões mensais do GKI.

O respin de outubro tem todos os patches enviados pelo OEM, mas outros patches do OEM afetam nossos produtos porque não foram testados especificamente com eles. É possível incluir apenas nosso patch?

Isso não é possível. Um caminho de respin "por OEM" não é escalonável. Em vez disso, a equipe do GKI analisa cada mudança que vai para os builds de respingo e testa as mudanças com todo o hardware disponível antes de criar um novo build. Se a equipe do GKI descobrir que o problema é específico de um OEM, dispositivo ou modelo, ela pode garantir que o código adicionado pela mudança seja executado apenas no dispositivo, modelo ou 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 e cenários de problemas do OEM para que eles possam avaliar o impacto e o risco da implementação dos patches nos produtos deles?

O Google não vai adicionar uma mudança a um build de respin até que o problema seja entendido e todos os detalhes tenham sido coletados. Isso é visto no log de mudanças (mensagem de confirmação). O Google não revela qual dispositivo específico é afetado, mas os OEMs sempre podem encontrar a descrição e a solução do problema no registro de alterações.