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

Esta página descreve como o GKI é lançado, incluindo versões trimestrais e de emergência fora da banda. O objetivo desta página é 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 da 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 do kernel com suporte de longo prazo (LTS) no Boletim de Segurança do Android (ASB).

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 do 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, só é possível corrigir bugs que causam falha no teste. A versão candidata a lançamento passa por controle de qualidade, conforme descrito na seção de qualificação da 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 do GKI

Onde conseguir artefatos de build

Os OEMs podem acessar artefatos de todas as versões 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).

É 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 contêm apenas os 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 e foram informadas até um determinado momento por OEMs que usam a versão trimestral de base correspondente. Confira 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.
• 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 que bloqueiam o lançamento informadas pelo OEM1 e pelo OEM2 durante a janela de nova versão, mas nada mais.
• 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 para OEMs individuais não é escalonável. Em vez disso, a equipe do GKI analisa cada mudança que entra em builds de nova rotação 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 poderá verificar se o código adicionado pela mudança é executado apenas no dispositivo, modelo ou SKU afetado.

O principal benefício das novas versões 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. Bugs do kernel principal 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 nova geração até que a equipe do GKI entenda o problema e colete todos os detalhes. Você pode conferir isso no changelog (mensagem de commit). O Google não revela qual dispositivo específico é afetado, mas os OEMs sempre podem encontrar a descrição do problema e a solução no changelog.