Esta página descreve como a GKI é lançada, incluindo dados semanais, mensais e externos de lançamentos de emergência de banda. O objetivo deste documento é oferecer aos OEMs diretrizes sobre onde coletar a GKI, bem como o processo para fora da banda correções de emergência. OEMs também podem usar GKI desenvolvimento para saber mais sobre como eles podem trabalhar com a equipe do kernel do Android para otimizar o kernel de GKI para seus produtos.
Cadência de lançamento de GKI
O GKI é lançado mensalmente após o congelamento do KMI.
Versão 13, 14 e 15 da GKI do Android
A tabela a seguir se aplica apenas aos
android13-5.10,
android13-5.15,
e
android14-5.15.
Consulte as datas de lançamento de setembro de 2024 neste comunicado.
| Builds certificados mensais do GKI | Data limite para check-in | Data de pré-carregamento de GKI | Confirmado? |
|---|---|---|---|
| Novembro | 11 de novembro de 2024 | 27 de novembro de 2024 | Sim |
| Janeiro | 17 de janeiro de 2025 | 31 de janeiro de 2025 | Sim |
| Fevereiro | 14 de fevereiro de 2025 | 28 de fevereiro de 2025 | Sim |
A tabela a seguir se aplica apenas aos
android14-6.1
e
android15-6.6
Consulte as datas de lançamento de setembro de 2024 neste comunicado.
| Builds mensais certificados de GKI | Data limite para check-in | Data de pré-carregamento de GKI | Confirmado? |
|---|---|---|---|
| Outubro | 1o 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 |
Lançamento da GKI do Android 12
Após maio de 2024, os lançamentos da GKI android12-5.10 serão trimestrais e
é publicado no meio do mês.
A tabela a seguir se aplica apenas aos
android12-5.10
| Builds mensais certificados de GKI | Data limite para check-in | Data de pré-carregamento de GKI | Confirmado? |
|---|---|---|---|
| Julho | 3 de julho de 2023 | 14 de julho de 2023 | Sim |
| Setembro | 1o 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 |
| Março | 4 de março de 2024 | 15 de março de 2024 | Sim |
| Maio | 1o de maio de 2024 | 17 de maio de 2024 | Sim |
| Agosto | 1º de agosto de 2024 | 16 de agosto de 2024 | Sim |
| 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 de GKI para OEMs
OEMs podem usar uma GKI do Android lançada recentemente. OEMs podem lançar com builds com certificação GKI, desde que estejam em conformidade com os requisitos de LTS no Boletim de segurança do Android (ASB).
Versões de desenvolvimento semanais
As versões são testadas com o Cuttlefish. para garantir que eles tenham passado em uma barra de qualidade mínima.Os binários de GKI estão disponíveis para autoatendimento no Android CI conforme as alterações são mescladas. Os builds semanais não serão certificados, embora possam ser usados como e estabelecer um valor de referência para desenvolvimento e testes. Os builds semanais não podem ser usados para e builds de dispositivos de produção para os usuários finais.
Lançamentos certificados mensais
Os lançamentos mensais de GKI contêm um boot.img testado que inclui uma versão
certificado inserido para atestar que os binários foram criados a partir de uma fonte conhecida
linha de base do código.
Todo mês, um candidato a lançamento mensal de GKI (não certificado) é selecionado após a data limite de check-in, que geralmente é a segunda criação semanal de naquele mês. Depois que o candidato a lançamento mensal for selecionado, o novo as mudanças não serão aceitas na versão desse mês. Durante o período fechado somente correções de bugs que causam falha no teste podem ser abordadas. O o candidato a lançamento passa por um controle de qualidade, conforme descrito no na seção de qualificação da solução) para garantir a aprovação dos testes de compliance O build de GSI+GKI usa um dispositivo de referência e o Cutlefish.
Figura 1. Cronograma de lançamento do GKI
Processo de resposta de emergência
Uma respin refere-se ao processo de refusão, recriação, novo teste e a recertificação de binários após uma versão pública do kernel de GKI. É possível solicitar uma nova versão de um binário certificado para qualquer uma das seguintes circunstâncias:
- 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.
- Adicionar um gancho para fornecedores.
- 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 versão de lançamento por até seis meses após o lançamento da versão. Após o limite de seis meses, você vai precisar solicitar uma nova verificação para aplicar patches de segurança a uma ramificação.
Diretrizes de solicitação de respin
Antes de solicitar uma nova verificação, observe as seguintes diretrizes:
As respins são permitidas somente em ramificações de lançamento após uma versão pública inicial. de uma versão mensal foi foi lançado.
As solicitações de respin são aceitas somente para uma determinada ramificação de lançamento durante um no máximo seis meses após o lançamento público inicial. Depois de seis meses, ramificações são qualificadas para respin apenas para patches de segurança citados em o Boletim de segurança do Android.
Quando os requisitos de LTS , definido pelo Boletim de segurança do Android (ASB, na sigla em inglês). fazer 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 GKI está incluída nas notas de build de lançamento mensais da GKI em Lançamentos. Para o planejamento futuro, os requisitos de LTS serão atualizados em maio e novembro anualmente. Por exemplo, o
android12-5.10-2023-07a ramificação (5.10.177) não oferece suporte a respins após 1o de maio de 2024 porqueandroid12-5.10-2023-07ramificação (5.10.177) não está em conformidade com os requisitos de LTS do ASB-2024-05.As respins são aplicáveis somente a correções urgentes de bugs, atualizações da lista de símbolos ou para aplicar um patch para corrigir um recurso.
Todos os patches que vão para a ramificação de lançamento mensal já devem estar mesclados na ramificação principal de desenvolvimento de GKI. Por exemplo, se for necessário um patch respin de
android12-5.10-2022-09, ele já deve estar mesclado aoandroid12-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 resposta, você precisa atribuir uma prioridade (urgência) a ela. Essa prioridade ajuda a equipe de GKI a atender melhor os parceiros em tempo hábil. Para solicitações críticas ou urgentes, marque a prioridade como P0. Para P0 e P1 as solicitações, você também deve justificar a urgência. A tabela a seguir mostra mapeamento da prioridade do bug e do tempo para 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
É necessário enviar uma solicitação de respin separada para cada ramificação de lançamento. Por exemplo, se é necessário um respin para
android12-5.10-2022-08eandroid12-5.10-2022-09, é necessário criar duas solicitações de respin.Depois que um build é fornecido e uma solicitação de respin é marcada como corrigida, não deve reabrir a solicitação de respin para adicionar mais CLs. Você deve enviar um novo solicitação respin se houver patches adicionais que precisam ser mesclados.
Para cada CL em consideração, adicione as seguintes tags.
Bug: o ID do bug precisa ser adicionado à mensagem de confirmação para cada CL.Change-Id: precisa ser idêntico ao Change-Id da alteração da ramificação base.
Se uma solicitação de respin exigir sua resposta e você não responder em até três dias úteis, a prioridade é rebaixada em um nível (por exemplo, P0 é rebaixado para P1. Se você não responder em até duas semanas, o bug será marcado como Sem correção (obsoleto).
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 resposta.
Figura 2. O processo de respin
Para entrar no processo de respin, siga estas etapas:
- Preencha o formulário de solicitação de 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 de GKI. Bugs de solicitação de respin aparecem para você
(o solicitante), a equipe de GKI e as pessoas específicas
que você adicionar ao
na lista de CC do bug.
- Se você já tiver uma correção, a solicitação deverá apontar para o patch envio no AOSP para que o Google possa analisá-lo. Se o envio do patch não for viável, o patch deve ser anexado à solicitação como um arquivo de texto.
- 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 e aprova a solicitação ou a atribui de volta ao caso precise de mais informações.
- Depois que uma correção é acordada, a equipe de GKI do Google revisa o código da equipe de GKI do Google (CR+2) mudar. A revisão começa o prazo da ESRT. A equipe de GKI mescla, cria e testa para regressão e certifica a mudança.
- O binário é liberado para ci.android.com (link em inglês). O O prazo da ESRT termina e a equipe de GKI do Google marca a solicitação como corrigida e referenciar o build respin. A versão respin também será postada na página Página de builds de lançamento de imagem genérica do kernel (GKI, na sigla em inglês).
Qualificações de GKI
| Tipos de builds de GKI | Aplicação da qualidade | Observações |
|---|---|---|
| Semanal | Teste do Cuttlefish
|
|
| Mensalmente (certificado) | Teste do Cuttlefish
|
|
| Respins (certificado) | Teste do Cuttlefish
|
|
Onde conseguir artefatos de build
Os artefatos de todas as versões podem ser obtidos em ci.android.com (link em inglês).
Encontre mais informações sobre CI, incluindo resultados no relatório Integração contínua do Android mais avançado.
Perguntas frequentes
Estas são algumas perguntas frequentes sobre o processo de lançamento da GKI.
É possível criar um novo binário de GKI com base em uma GKI já lançada?
Sim, isso é conhecido como respin. O processo respin tem suporte desde que o O build GKI lançado (em que a resposta é solicitada) está em conformidade com o LTS. requisitos no Boletim de segurança do Android (ASB).
É possível reproduzir binários de GKI?
Sim, aqui está 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 sua cópia do artefato de 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?
Não. As Respins só contêm patches que complementam as certificações mensais aos kernels que foram escolhidos. Esses respins contêm todos os bugs de bloqueio de lançamento de correções relatadas até determinado momento pelos OEMs usando a base correspondente lançamento mensal. Confira o exemplo a seguir de como esse tipo de cenário acontece.
- O OEM1 e o OEM2 decidiram usar a versão do binário 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 marcador também foram incluídos nas próximas etapas lançamentos mensais.
A respin de outubro tem todos os patches enviados pelo OEM, mas outros patches do OEM nos afetam porque eles 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" 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 de GKI descobrir que o problema é específico de um OEM, dispositivo ou a equipe de GKI pode garantir que o código adicionado pela mudança só seja executado no dispositivo, modelo ou SKU que está sendo afetado.
A maior vantagem das respins unificadas é que cada dispositivo usando a mesma base de lançamento se beneficiam uns dos outros, especialmente se os bugs que descobrirem são genéricas e aplicáveis a todos os usuários. 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 e cenários de problemas do OEM para que eles possam avaliar o impacto e o risco da implementação dos patches nos produtos deles?
O Google não adiciona uma alteração a um build respin até que o problema seja compreendido. e todos os detalhes foram coletados. Isso é visto no log de mudanças (mensagem de confirmação). O Google não revela qual dispositivo específico afeta, mas Os OEMs sempre podem encontrar a descrição do problema e a solução no log de mudanças.