Processo de lançamento de imagem genérica do kernel (GKI)

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.

Cronograma de cadência de lançamento do GKI 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ção android12-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 em android12-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-08 e android12-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.

Processo de respin de emergência Figura 2. O processo de respin

Para entrar no processo de respin:

  1. 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.
  2. 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.
  3. 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.
  4. 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
  • Bota
  • Subconjunto de VTS
  • Subconjunto de CTS
  • Não certificado. Somente para testes e
    dispositivo seja exibido.
  • Não pode ser usado para iniciar dispositivos.
Mensalmente (certificado) Teste de choco
  • Bota
  • VTS
  • CTS
Teste de hardware de referência
  • Bota
  • VTS
  • CTS
    Respins (certificados) Teste de choco
    • Bota
    • VTS
    • Subconjunto de CTS
    Teste de dispositivo de referência
    • Bota
    • VTS
    • Construído com base em uma versão certificada pela GKI.
    • A construção é certificada após qualificação.

    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/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
    

    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.