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 a 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 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 pela GKI desde que estejam em conformidade com os requisitos de LTS no Boletim de segurança do Android (ASB, na sigla em inglês).

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 a versão candidata trimestral for selecionada, novas mudanças não serão aceitas na versão 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

Qualificações do GKI

Onde encontrar 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 da 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).

É 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 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 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 versão "por OEM" não é escalonável. Em vez disso, a equipe do 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 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.