Esta página descreve como o GKI é lançado, 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.
| Builds certificados mensais do GKI | Data limite para check-in | Data de disponibilidade do pré-carregamento do GKI | Confirmado? |
|---|---|---|---|
| Novembro | 11 de novembro de 2024 | 27 de novembro de 2024 | Sim |
| Janeiro | 14 de janeiro de 2025 | 31 de janeiro de 2025 | Sim |
| Março | 14 de março de 2025 | 31 de março de 2025 | Sim |
A tabela a seguir é aplicável apenas a
android14-6.1
e
android15-6.6.
| Builds certificados mensais do GKI | Data limite para check-in | Data de disponibilidade do pré-carregamento do GKI | Confirmado? |
|---|---|---|---|
| Outubro | 1º de outubro de 2024 | 14 de outubro de 2024 | Sim |
| Novembro | 1º de novembro de 2024 | 15 de novembro de 2024 | Sim |
| Dezembro | 2 de dezembro de 2024 | 16 de dezembro de 2024 | Sim |
| Janeiro | 6 de janeiro de 2025 | 22 de janeiro de 2025 | Sim |
Versão do 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 ao
android12-5.10.
| Builds certificados mensais do GKI | Data limite para check-in | Data de disponibilidade do pré-carregamento do GKI | Confirmado? |
|---|---|---|---|
| Novembro | 1º de novembro de 2024 | 15 de novembro de 2024 | Sim |
| Fevereiro | 3 de fevereiro de 2025 | 17 de fevereiro de 2025 | Sim |
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).
Lançamentos de desenvolvimento semanais
As versões são testadas com o Cuttlefish para garantir que elas atendam a um padrão mínimo de qualidade.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 com base em um perfil de referência
de código-fonte conhecido.
A cada mês, um candidato de lançamento mensal do 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 mensal candidata for selecionada, não serão aceitas novas mudanças na versão daquele 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 respingo de emergência
Um respin se refere ao processo de reemersão, 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.
- Para adicionar um gancho 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 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 um respin, observe as seguintes diretrizes:
Os respins são permitidos apenas em filiais de lançamento depois que uma versão pública inicial de um build mensal é lançada.
As solicitações de reversão são aceitas apenas para uma determinada versão por um máximo de seis meses após o lançamento público inicial. Após seis meses, as ramificações só podem ser reenviadas 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çãoandroid12-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 ser mesclados na ramificação de desenvolvimento principal do GKI. Por exemplo, se um patch for necessário para uma repetição de
android12-5.10-2022-09, ele já precisa ser mesclado emandroid12-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 reenvio, é necessário atribuir uma prioridade (urgência) à solicitação. Essa prioridade ajuda a equipe da GKI a prestar uma melhor assistência aos 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 a seguir fornece um mapeamento da prioridade do bug e do tempo de 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-08eandroid12-5.10-2022-09, você precisará criar duas solicitações de respin.Depois que um build for fornecido e uma solicitação de respinagem for marcada como corrigida, não reabra a solicitação de respinagem para adicionar outros 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 reenvio exigir uma resposta e você não responder em até três dias úteis, a prioridade será rebaixada 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 uma solicitação de respin
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:
- Preencha o formulário de solicitação de Respin do GKI
e entre em contato com seu 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.
- A equipe de GKI do Google analisa a solicitação e a aprova ou a atribui de volta a você se for necessário mais informações.
- Depois que uma correção é acordada, 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.
- 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 de builds de lançamento da imagem genérica do kernel (GKI).
Qualificações do GKI
| Tipos de builds de GKI | Aplicação da qualidade | Observações |
|---|---|---|
| Semanal | Teste do Cuttlefish
|
|
| Mensal (certificado) | Teste do Cuttlefish
|
|
| Respins (certificados) | Teste do Cuttlefish
|
|
Onde encontrar 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 do 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 os 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/manifestmv manifest_7364300.xml .repo/manifestsrepo init -m manifest_7364300.xml --depth=1repo sync # build the GKI images # You may want to use LTO=thin to build faster for developmentBUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh # (optional) build virtual platform modulesBUILD_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 respins contêm todas as correções de bugs de bloqueio de inicialização relatadas até um determinado momento pelos OEMs usando 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 dos respins unificados é 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 principais 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 e cenários de problemas de OEM para que eles possam avaliar o impacto e o risco da implementação dos patches nos produtos?
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 aparece no registro de alterações (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.