Este documento descreve como o GKI é lançado, incluindo lançamentos de emergência semanais, mensais e fora de banda. O objetivo deste documento é fornecer aos OEMs uma orientação sobre onde obter o GKI, bem como o processo para correções de emergência fora de banda. Os OEMs também podem usar o guia de desenvolvimento do GKI para saber mais sobre como podem trabalhar com a equipe do Kernel do Android para otimizar o kernel do GKI para seus 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 do GKI do Android 13 e 14
A tabela a seguir é aplicável apenas a android13-5.10 , android13-5.15 e android14-6.1 .
| Compilações certificadas mensalmente pelo GKI | Data limite do check-in | Data de preparação do pré-carregamento do GKI | Confirmado? |
|---|---|---|---|
| Outubro | 14 de outubro de 2022 | 31 de outubro de 2022 | Sim |
| novembro | 14 de novembro de 2022 | 30 de novembro de 2022 | Sim |
| dezembro | 9 de dezembro de 2022 | 21 de dezembro de 2022 | Sim |
| Janeiro | 17 de janeiro de 2023 | 31 de janeiro de 2023 | Sim |
| Fevereiro | 15 de fevereiro de 2023 | 28 de fevereiro de 2023 | Sim |
| Marchar | 15 de março de 2023 | 31 de março de 2023 | Sim |
| abril | 13 de abril de 2023 | 28 de abril de 2023 | Sim |
| Poderia | 17 de maio de 2023 | 31 de maio de 2023 | Sim |
| Junho | 15 de junho de 2023 | 30 de junho de 2023 | Sim |
| Julho | 18 de julho de 2023 | 31 de julho de 2023 | Sim |
| Agosto | 16 de agosto de 2023 | 31 de agosto de 2023 | Sim |
| Setembro | 14 de setembro de 2023 | 29 de setembro de 2023 | Sim |
| Outubro | 18 de outubro de 2023 | 31 de outubro de 2023 | Sim |
| novembro | 10 de novembro de 2023 | 30 de novembro de 2023 | Sim |
| dezembro | 7 de dezembro de 2023 | 22 de dezembro de 2023 | Sim |
| Janeiro | 16 de janeiro de 2024 | 31 de janeiro de 2024 | Sim |
| Fevereiro | 13 de fevereiro de 2024 | 29 de fevereiro de 2024 | Sim |
| Marchar | 13 de março de 2024 | 29 de março de 2024 | Sim |
| abril | 16 de abril de 2024 | 30 de abril de 2024 | Sim |
| Poderia | 14 de maio de 2024 | 31 de maio de 2024 | Sim |
| Junho | 12 de junho de 2024 | 28 de junho de 2024 | Sim |
| Julho | 16 de julho de 2024 | 31 de julho de 2024 | Sim |
| Agosto | 15 de agosto de 2024 | 30 de agosto de 2024 | Sim |
| Setembro | 17 de setembro de 2024 | 30 de setembro de 2024 | Sim |
| Outubro | 15 de outubro de 2024 | 31 de outubro de 2024 | Sim |
| novembro | 11 de novembro de 2024 | 27 de novembro de 2024 | Sim |
| dezembro | 6 de dezembro de 2024 | 23 de dezembro de 2024 | Sim |
A partir de janeiro de 2024, retomaremos os lançamentos mensais do android14-5.15 de acordo com a cadência mensal especificada descrita na tabela abaixo.
| Compilações certificadas mensalmente pela GKI | Data limite do check-in | Data de preparação do pré-carregamento do GKI | Confirmado? |
|---|---|---|---|
| Janeiro | 16 de janeiro de 2024 | 31 de janeiro de 2024 | Sim |
| Fevereiro | 13 de fevereiro de 2024 | 29 de fevereiro de 2024 | Sim |
| Marchar | 4 de março de 2024 | 15 de março de 2024 | Sim |
| abril | 1º de abril de 2024 | 17 de abril de 2024 | Sim |
| Poderia | 1º de maio de 2024 | 17 de maio de 2024 | Sim |
| Junho | 3 de junho de 2024 | 17 de junho de 2024 | Sim |
| Julho | 1º de julho de 2024 | 15 de julho de 2024 | Sim |
| Agosto | 1º de agosto de 2024 | 16 de agosto de 2024 | Sim |
| Setembro | 2 de setembro de 2024 | 16 de setembro de 2024 | Sim |
| 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 |
Lançamento do Android 12 GKI
Depois de maio de 2023, os lançamentos android12-5.10 GKI ocorrerão em uma cadência de 2 meses e serão publicados no meio do mês. A tabela a seguir é aplicável apenas a android12-5.10 .
| Compilações certificadas mensalmente pela GKI | Data limite do check-in | Data de preparação do pré-carregamento do GKI | Confirmado? |
|---|---|---|---|
| Julho | 3 de julho de 2023 | 14 de julho de 2023 | Sim |
| Setembro | 1º de setembro de 2023 | 15 de setembro de 2023 | Sim |
| novembro | 3 de novembro de 2023 | 17 de novembro de 2023 | Sim |
| Janeiro | 5 de janeiro de 2024 | 19 de janeiro de 2024 | Sim |
| Marchar | 4 de março de 2024 | 15 de março de 2024 | Sim |
| Poderia | 1º de maio de 2024 | 17 de maio de 2024 | Sim |
Validade de compilação do GKI para OEMs
Os OEMs podem usar um Android GKI lançado recentemente. Os OEMs podem lançar compilações certificadas pela GKI, desde que estejam em conformidade com os requisitos LTS do Android Security Bulletin (ASB).
Lançamentos semanais de desenvolvimento
As liberações são testadas com chocos para garantir que passem por um padrão mínimo de qualidade .Os binários GKI estão disponíveis para autoatendimento em ci.android.com à medida que as alterações são mescladas. As compilações semanais não serão certificadas, mas podem ser usadas como base para desenvolvimento e testes. As compilações semanais não podem ser usadas para compilações de dispositivos de produção para usuários finais.
Lançamentos certificados 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 a partir de uma linha de base de código-fonte conhecida.
A cada mês, um release candidate mensal do GKI (não certificado) é selecionado após a data limite de check-in, que geralmente é a segunda compilação semanal daquele mês. Depois que o release candidate mensal for selecionado, novas alterações não serão aceitas no lançamento daquele mês. Durante o período de janela fechada, apenas correções de bugs que causam falha no teste podem ser corrigidas. O release candidate passa por garantia de qualidade — conforme descrito na seção de qualificação GKI — para garantir que os testes de conformidade sejam aprovados na construção GSI+GKI com um dispositivo de referência e também com choco.
Figura 1. Cronograma de lançamento do GKI
Processo de respin de emergência
Um respin refere-se ao processo de reintegração, reconstrução, novo teste e recertificação de um binário após um lançamento público do kernel GKI . Você pode solicitar uma nova rotaçã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 bugs encontrados durante a aprovação do laboratório da operadora.
- Para adicionar um gancho de fornecedor .
- Para aplicar um patch a um recurso existente.
- Para aplicar um patch de segurança (após 6 meses).
Os patches de segurança são automaticamente mesclados em uma ramificação de lançamento por até 6 meses após o lançamento da ramificação. Após o prazo de 6 meses, você deve solicitar uma nova rodada para aplicar patches de segurança a uma filial.
Antes de solicitar uma nova rodada, observe as seguintes diretrizes:
Respins são permitidos apenas em ramificações de lançamento após o lançamento público inicial de uma compilação mensal .
Solicitações de respin são aceitas apenas para um determinado branch de lançamento por no máximo seis meses após o lançamento público inicial. Após seis meses, as filiais são elegíveis para respin apenas para patches de segurança citados em um Boletim de Segurança do Android .
Quando os requisitos LTS , definidos pelo Android Security Bulletin (ASB), fazem com que o branch não esteja em conformidade, o branch é obsoleto. Solicitações de respin para ramificações obsoletas não são aceitas. A data de descontinuação de um determinado branch de lançamento do GKI está incluída nas notas mensais de compilação do lançamento do GKI em Releases . Para planejamento futuro, os requisitos do 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 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 o Requisitos LTS da ASB-2024-05.Os respins são aplicáveis apenas para correções urgentes de bugs, atualizações da lista de símbolos ou para aplicar um patch para corrigir um recurso existente.
Todos os patches que vão para o branch de lançamento mensal já devem estar mesclados no branch de desenvolvimento principal do GKI. Por exemplo, se um patch for necessário para uma nova rotação de
android12-5.10-2022-09, ele já deverá estar mesclado emandroid12-5.10.Você deve escolher os patches do branch de desenvolvimento principal do GKI e fazer upload do patch para o branch de lançamento mensal.
Na solicitação de respin, você deve atribuir uma prioridade (urgência) à solicitação. Esta prioridade ajuda a equipe da GKI a ajudar melhor os 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 deverá justificar a urgência. A tabela a seguir fornece um mapeamento da prioridade do bug e do tempo de resolução (ESRT):
Prioridade ESRT P0 2 dias úteis P1 5 dias úteis P2 10 dias úteis P3 15 dias úteis
Você deve enviar uma solicitação de respin separada por branch de lançamento. Por exemplo, se um respin for necessário para
android12-5.10-2022-08eandroid12-5.10-2022-09, você deverá criar duas solicitações de respin.Depois que uma compilação for fornecida e uma solicitação de respin for marcada como corrigida, você não deverá reabrir a solicitação de respin para adicionar CLs adicionais. Você deve enviar uma nova solicitação de respin se houver patches adicionais que precisem ser mesclados.
Para cada CL em consideração, adicione as tags a seguir. O progresso na solicitação de respin é bloqueado sem esta informação.
-
Bug: o ID do bug deve ser adicionado à mensagem de commit para cada CL. -
Change-Id: deve ser idêntico ao Change-Id da alteração do branch base.
-
Se uma solicitação de respin exigir sua resposta e você não responder dentro de três dias úteis, a prioridade será rebaixada em um nível (por exemplo, P0 será rebaixado para P1 ). Se você não responder por duas semanas, o bug será marcado como Não será corrigido (obsoleto) .
Envie 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 GKI Respin . e entre em contato com seu gerente técnico de contas do Google imediatamente. Este formulário cria um bug de solicitação de respin GKI. Os bugs de solicitação de respin são visíveis para você (o solicitante), para a equipe do GKI e para indivíduos específicos que você adiciona à lista de CC do bug.
- Se você já tiver uma correção, a solicitação deverá apontar para o envio do patch no AOSP para que o Google possa revisá-la. Se o envio do patch não for viável, o patch deverá ser anexado como um arquivo de texto à solicitação.
- Se você não tiver uma correção, a solicitação deverá 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 do Google GKI analisa a solicitação e a aprova ou a atribui de volta a você se mais informações forem necessárias.
- Depois que uma correção é acordada, o código da equipe do Google GKI analisa (CR+2) a alteração. A revisão inicia o prazo ESRT. A equipe do GKI mescla, cria, testa a regressão e certifica a mudança.
- O binário é lançado em ci.android.com . O prazo ESRT termina e a equipe do Google GKI marca a solicitação como corrigida e faz referência à compilação respin. A compilação respin também pode ser publicada na página de versões de versão da imagem genérica do kernel (GKI) .
Qualificações GKI
| Tipos de compilações GKI | Aplicação da qualidade | Notas |
|---|---|---|
| Semanalmente | Teste de choco
|
|
| Mensalmente (certificado) | Teste de choco
| |
| Respins (certificados) | Teste de choco
|
|
Onde obter artefatos de construção
Artefatos para todos os lançamentos podem ser obtidos em ci.android.com .
Você pode encontrar mais informações sobre o CI, incluindo os resultados do teste no painel de integração contínua do Android .
Perguntas frequentes
É possível construir um novo binário GKI baseado em um GKI já lançado?
Sim, isso é conhecido como respin. O processo de respin é suportado desde que a versão GKI lançada (na qual o respin é solicitado) esteja em conformidade com os requisitos LTS do Android Security Bulletin (ASB).
É possível reproduzir binários GKI?
Sim, consulte o exemplo abaixo.
GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest
Para reproduzir o exemplo, baixe 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
Você pode recuperar sua cópia do artefato GKI em out/.../dist .
O binário GKI (incluindo o patch de rotação de emergência) foi criado na base de código mais recente?
Os Respins contêm apenas patches que estão além dos kernels certificados mensalmente que foram escolhidos. Esses 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 base correspondente. Veja no exemplo a seguir como acontece esse tipo de cenário.
- OEM1 e OEM2 decidem usar a versão binária GKI a partir de novembro de 2021.
- OEM1 e OEM2 encontram problemas que exigem patches para suporte. Esses patches podem ser diferentes ou iguais.
- Os respins acima do binário de novembro de 2021 lançaram correções de bloqueio relatadas por OEM1 e OEM2 durante a janela de respins, mas nada mais.
- Os problemas mencionados no segundo item também estão incluídos nas versões mensais subsequentes do GKI.
O respin de outubro tem todos os patches enviados pelo OEM, mas outros patches OEM 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 "por OEM" atualmente não é escalável. Em vez disso, a equipe GKI examina cada alteração que ocorre nas compilações respin e testa as alterações com todo o hardware disponível antes de criar uma nova compilação. Se a equipe do GKI descobrir que o problema é específico de um OEM/dispositivo/modelo, a equipe do GKI poderá garantir que o código adicionado pela alteração seja executado apenas no dispositivo/modelo/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. Os principais bugs do kernel encontrados nos testes de operadora são um exemplo específico desse conceito.
Existem 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 da implementação dos patches em seus produtos?
O Google nunca adicionará uma alteração a uma versão respin até que o problema seja compreendido e todos os detalhes tenham sido coletados. Isso é visto no changelog (mensagem de commit). O Google não revela qual dispositivo específico isso afeta, mas os OEMs sempre podem encontrar a descrição e a solução do problema no changelog.