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

Nesta página, descrevemos como a GKI é lançada, incluindo lançamentos trimestrais e de emergência fora de banda. O objetivo desta página é 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 e 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 da KMI.

Validade do build da GKI para OEMs

Os OEMs podem usar uma GKI do Android lançada recentemente. Os OEMs podem lançar builds certificados pela GKI desde que estejam em conformidade com os requisitos do kernel de suporte de longo prazo (LTS) no Boletim de Segurança do Android (ASB).

Versões de GKI de 16 KB

A equipe de lançamento do GKI lida com as versões de 16 KB usando a mesma cadência de lançamento trimestral, testes de qualificação e processo de nova versão que as versões de 4 KB:

• Ramificações compatíveis:
  • android15-6.6 (a partir de janeiro de 2026)
  • android16-6.12 (a partir de março de 2026)
  • android17-6.18 (a partir de junho de 2026)
• Paridade e certificação de build:os binários GKI de 16 KB usam a mesma tag de origem e o mesmo ID de build do kernel que a versão correspondente de 4 KB. Até 2027, a guia Build de lançamento de 16 KB nas páginas de build de lançamento do android15-6.6, android16-6.12 e android17-6.18 vai fornecer binários de lançamento do GKI de 16 KB não certificados. Não é necessário atualizar os kernels de 4 KB e 16 KB juntos, mas recomendamos que você faça isso.
• Respines sob demanda:solicite respines de GKI de 16 KB usando o mesmo processo e formulário de solicitação de respin que as versões de 4 KB.

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, uma versão candidata a lançamento trimestral da GKI (não certificada) é selecionada após a data limite de check-in. Depois que a versão candidata a lançamento trimestral for selecionada, novas mudanças não serão aceitas na versão daquele mês. Durante o período de janela fechada, apenas as correções de bugs que causam falhas de teste podem ser resolvidas. A versão candidata a lançamento passa por controle de qualidade, conforme descrito na seção de qualificação do GKI, para verificar se os testes de conformidade são aprovados em um build GSI+GKI com um dispositivo de referência e com o Cuttlefish.

Figura 1. Cronograma de lançamento do GKI

Qualificações da GKI

Onde encontrar artefatos de build

Os OEMs podem acessar artefatos de todas as versões em ci.android.com.

Para mais informações sobre a CI, incluindo os resultados dos testes, acesse o painel de 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 da GKI com base em uma GKI já lançada?

Sim, isso é conhecido como uma nova rotação. O processo de respin é aceito desde que o build da GKI lançado (em que o respin é solicitado) esteja em conformidade com os requisitos de LTS no Boletim de Segurança do Android (ASB).

É possível reproduzir binários da GKI?

Sim, veja 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 da GKI em out/.../dist.

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

Não. As novas versões contêm apenas os patches que estão sobre os kernels certificados trimestrais que foram escolhidos. Essas novas versões contêm todas as correções de bugs que impedem o lançamento informadas até um determinado momento por OEMs que usam a versão trimestral de base correspondente. Veja o exemplo a seguir 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.
• O OEM1 e o 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 lançamento informadas pelo OEM1 e pelo OEM2 durante a janela de nova versão, mas nada mais.
• Os problemas mencionados no segundo marcador 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 respin para OEMs individuais não é escalonável. Em vez disso, a equipe da GKI analisa cada mudança que entra nas versões de respin e testa as mudanças com todo o hardware disponível antes de criar uma nova versão. Se a equipe do GKI descobrir que o problema é específico de um OEM, dispositivo ou modelo, ela poderá verificar se o código adicionado pela mudança é 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 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 de kernel principais encontrados em testes de operadoras são um exemplo específico desse conceito.

Há situações em que o Google fornece informações específicas sobre patches de OEMs 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 a equipe do GKI entenda o problema e colete todos os detalhes. Isso pode ser visto no registro de alterações (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 registro de alterações.