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

Nesta página, descrevemos como o GKI é lançado, incluindo versões semanais, trimestrais e de emergência fora da banda. O objetivo deste documento é fornecer aos OEMs uma diretriz sobre onde buscar o GKI e o processo para correções de emergência fora da banda. Os OEMs também podem usar o desenvolvimento de GKI para saber mais sobre como trabalhar com a equipe do kernel do Android para otimizar o kernel da GKI para os produtos deles.

Cadência de lançamento do GKI

O GKI é lançado trimestralmente após o congelamento do KMI.

Validade da build do GKI para OEMs

Os OEMs podem usar uma GKI do Android lançada recentemente. Os OEMs podem lançar builds certificados pelo GKI desde que estejam em conformidade com os requisitos de LTS no Boletim de segurança do Android (ASB, na sigla em inglês).

Versões de desenvolvimento semanais

Os binários da GKI estão disponíveis para autoatendimento no Android CI à medida que as mudanças são mescladas. As builds semanais não são certificadas, mas podem ser usadas como uma referência para desenvolvimento e testes. As versões semanais não podem ser usadas para versões de dispositivos de produção para usuários finais.

Lançamentos certificados trimestrais

As versões trimestrais do 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 código-fonte conhecido.

A cada trimestre, um candidato a lançamento trimestral da GKI (não certificado) é selecionado após a data limite de check-in, que geralmente é o segundo build semanal daquele mês. Depois que o candidato a lançamento trimestral for selecionado, novas mudanças não serão aceitas no lançamento daquele mês. Durante o período da janela fechada, só é possível corrigir bugs que causam falha no teste. O candidato a lançamento passa por garantia de qualidade, conforme descrito na seção de qualificação do GKI, para garantir que os testes de conformidade sejam aprovados na build GSI+GKI com um dispositivo de referência e um cuttlefish.

Figura 1. Cronograma de lançamento do GKI

Processo de nova geração de emergência

Um respin se refere ao processo de remergir, reconstruir, testar novamente e recertificar um binário após um lançamento público do kernel GKI. É possível solicitar uma nova versão de um binário certificado em qualquer uma das seguintes circunstâncias:

• Para atualizar uma lista de símbolos.
• Para aplicar uma correção a um bug, incluindo os encontrados durante a aprovação do laboratório da operadora.
• Para adicionar um hook de fornecedor:
• Para aplicar um patch a um recurso atual.
• Para aplicar um patch de segurança (após 6 meses).

Os patches de segurança são mesclados automaticamente em uma ramificação de lançamento por até seis meses após o lançamento da ramificação. Após o corte de seis meses, você precisa solicitar uma nova rotação para aplicar patches de segurança a uma ramificação.

Diretrizes para pedir uma nova resposta

Antes de pedir uma nova versão, observe as seguintes diretrizes:

• Os respins só são permitidos em ramificações de lançamento depois que um lançamento público inicial de um build trimestral for lançado.

• As solicitações de nova versão só são aceitas para uma determinada ramificação de lançamento por um máximo de seis meses após o lançamento público inicial. Após seis meses, as ramificações só poderão ser retransmitidas 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), fazem com que a ramificação fique em não conformidade, ela é descontinuada. Não é possível fazer novas solicitações para ramificações descontinuadas. A data de suspensão de uma determinada ramificação de lançamento da GKI está incluída nas notas de build de lançamento trimestrais da GKI em Lançamentos. Para 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 é compatível com novas versões 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 da ASB-2024-05.

• As novas versões são aplicáveis apenas a correções urgentes de bugs, atualizações de lista de símbolos ou para aplicar um patch e corrigir um recurso existente.

• Todos os patches que entram na ramificação de lançamento trimestral já precisam estar mesclados na ramificação principal de desenvolvimento do GKI. Por exemplo, se um patch for necessário para uma nova geração de android12-5.10-2022-09, ele já precisará estar mesclado em android12-5.10.

• Você precisa selecionar patches da ramificação principal de desenvolvimento do GKI e fazer upload do patch para a ramificação de lançamento trimestral.

• Na solicitação de nova geração, você precisa atribuir uma prioridade (urgência) a ela. Essa prioridade ajuda a equipe da GKI a atender melhor os parceiros de maneira oportuna. Para solicitações urgentes ou críticas, marque a prioridade como P0. Para solicitações de P0 e P1, você também precisa justificar a urgência. A tabela a seguir fornece um mapeamento da prioridade do bug e do tempo até a 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 nova versão separada para cada ramificação de lançamento. Por exemplo, se for necessário um novo envio para android12-5.10-2022-08 e android12-5.10-2022-09, crie dois pedidos de novo envio.

• Depois que um build é fornecido e um pedido de nova versão é marcado como corrigido, não reabra o pedido para adicionar CLs extras. Envie uma nova solicitação de reversão se houver outros patches que precisam ser mesclados.

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

  • Bug: o ID do bug precisa ser adicionado à mensagem de commit de cada CL.
  • Change-Id: precisa ser idêntico ao Change-Id da mudança na ramificação de base.

• Se uma solicitação de nova geração 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á reduzida para P1). Se você não responder em duas semanas, o bug será marcado como Não será corrigido (obsoleto).

Enviar um pedido de nova versão

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

Figura 2. O processo de nova versão

Para iniciar o processo de nova rotação:

1. Preencha o formulário de solicitação de GKI Respin e entre em contato imediatamente com seu gerente técnico de contas do Google. Esse formulário cria um bug de solicitação de nova rotação da GKI. Os bugs de solicitação de nova tentativa ficam visíveis para você (o solicitante), a equipe do GKI e pessoas específicas que você adiciona à lista de cópias 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 precisa ser anexado como um arquivo de texto à solicitação.
   • Se você não tiver uma correção, a solicitação precisa 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 do GKI do Google analisa e aprova a solicitação ou a atribui de volta a você se forem necessárias mais informações.
3. Depois que uma correção é acordada, a equipe do Google GKI faz revisões de código (CR+2) da mudança. A revisão inicia o período do ESRT. A equipe do 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 nova rotação. O build de respin também será postado na página de builds de lançamento da imagem genérica do kernel (GKI).

Qualificações do GKI

Onde obter artefatos de build

Os artefatos de todas as versões podem ser obtidos em ci.android.com.

Você pode encontrar mais informações sobre a CI, incluindo os resultados dos testes, no painel Integração contínua do Android.

Perguntas frequentes

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

É possível criar um novo binário do GKI com base em um GKI já lançado?

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

É possível reproduzir binários do 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 sua cópia do artefato GKI em out/.../dist.

O binário do GKI (incluindo o patch de rotação de emergência) foi criado no codebase mais recente?

Não. As novas versões só contêm patches que estão acima dos kernels trimestrais certificados que foram escolhidos. Essas novas versões contêm todas as correções de bugs que impedem o lançamento e foram informadas até um determinado momento por OEMs usando a versão trimestral de base correspondente. Confira a seguir um exemplo de como esse tipo de cenário acontece.

• As OEMs 1 e 2 decidem usar a versão binária do GKI de novembro de 2021.
• OEM1 e OEM2 encontram problemas que exigem patches para suporte. Esses patches podem ser diferentes ou iguais.
• As novas versões do binário de novembro de 2021 têm correções de bloqueio de inicialização informadas pelo OEM1 e pelo OEM2 durante o período de nova versão, mas nada além disso.
• Os problemas mencionados no segundo item também estão incluídos nas versões trimestrais subsequentes do GKI.

A nova versão de outubro tem todos os patches enviados pelas OEMs, mas outros patches de OEMs nos afetam porque não foram testados especificamente com nossos produtos. É possível incluir apenas nosso patch?

Isso não é possível. Um caminho de nova rotação "por OEM" não é escalonável. Em vez disso, a equipe do GKI analisa cada mudança que entra em builds de respin e testa as mudanças com todo o hardware disponível antes de criar um novo build. Se a equipe da GKI descobrir que o problema é específico de um OEM, dispositivo ou modelo, ela poderá garantir que o código adicionado pela mudança seja executado apenas no dispositivo, modelo ou SKU afetado.

O principal benefício das novas tentativas unificadas é 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 bugs principais do kernel encontrados em testes de 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 de implementar os patches com os produtos deles?

O Google nunca adiciona uma mudança a um build de repetição até que o problema seja compreendido e todos os detalhes tenham sido coletados. Isso pode ser visto no changelog (mensagem de commit). 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 changelog.