Pedir uma nova versão

Um respin é o processo de remergir, reconstruir, testar novamente e recertificar um binário após um lançamento público do kernel GKI.

Antes de pedir uma nova versão, confira as diretrizes a seguir.

Qualificação e ciclo de vida

  • Cronograma:só é possível solicitar novas versões em branches de lançamento depois que uma versão pública inicial de um build trimestral for lançada. Solicite novas versões de solicitações para hooks de fornecedor ou outros recursos apenas para uma determinada ramificação de lançamento por no máximo seis meses após o lançamento público inicial.
  • Segurança e LTS:após seis meses, as ramificações só poderão ser reexecutadas para patches de segurança citados em um Boletim de Segurança do Android (ASB) ou correções de bugs críticos.
  • Descontinuação:quando os requisitos de LTS, definidos pelo Boletim de segurança do Android (ASB, na sigla em inglês), fazem com que a ramificação fique em não conformidade, ela é descontinuada. Não é possível fazer novas solicitações para ramificações descontinuadas.
    • A data de descontinuação de uma determinada ramificação de lançamento do GKI está incluída nas notas de build de lançamento trimestrais do GKI em "Lançamentos". Por exemplo, a versão de setembro de 2025 tem suporte para novas rotações até março de 2027. Essa data reflete o ciclo de vida de 18 meses da versão do kernel LTS 2.0 para lançamentos a partir de setembro de 2025. Os lançamentos anteriores a setembro de 2025 tinham um ciclo de vida de 12 meses.
  • Escopo:solicite novas versões apenas para correções de bugs urgentes, atualizações da lista de símbolos ou para aplicar um patch e corrigir um recurso existente.

Padrões de envio de patch

Para atender ao tempo de resolução padrão esperado (ESRT, na sigla em inglês) do processamento de solicitações de reenvio, todos os patches enviados a uma ramificação de lançamento precisam obedecer às seguintes regras técnicas.

Fonte de verdade e cherry-picks

  • Primeiro a ramificação de desenvolvimento:todos os patches que entram na ramificação de lançamento trimestral já precisam estar mesclados na ramificação principal de desenvolvimento do GKI. Por exemplo, se um patch for necessário para uma nova versão de android15-6.6-2025-08, ele já precisará estar mesclado em android15-6.6.
  • Cherry-pick limpo:você precisa fazer cherry-pick de patches diretamente da ramificação de desenvolvimento. Não selecione de outras ramificações de lançamento (por exemplo, não selecione de 2025-08 para 2025-09), porque isso pode resultar em informações de autor ou commit inconsistentes com a versão na ramificação de desenvolvimento. Patches com informações inconsistentes não serão aceitos.
  • Preservar metadados:preserva os metadados originais do commit (por exemplo, autor, carimbo de data/hora original). Use git cherry-pick -x para preservar os metadados.

Cadeia de commits

  • Cadeia sequencial:se o pedido de nova versão envolver vários patches, faça o upload deles como uma única cadeia sequencial de commits.
  • Posicionamento de ABI e KMI:se um respin de vários patches incluir atualizações de interface de módulo do kernel (KMI) e interface binária de aplicativo (ABI), por exemplo, mudanças na lista de símbolos ou atualizações de arquivos XML/STG, coloque esses commits no final da cadeia de commits.
  • Rebase:se você editar um commit principal na cadeia, será necessário fazer rebase de todos os patches filhos na revisão mais recente do patch principal para evitar falhas de build.
  • Resolução de conflitos:verifique se não há marcadores de conflito em nenhum patch.
  • Verificação de build:toda a cadeia de commits precisa ser criada com sucesso.

Tags obrigatórias

O progresso da solicitação de nova geração é bloqueado sem as seguintes tags na mensagem de commit:

  • Change-Id: precisa ser idêntico ao Change-Id da mudança na ramificação de desenvolvimento.
    • Exceção: se o patch foi mesclado à ramificação de desenvolvimento como parte de uma atualização do LTS, ele precisa ser um cherry-pick da versão do LTS e formatado como um patch UPSTREAM. Consulte Como enviar patches para kernels comuns do Android.
  • Bug (existente): as tags Bug: XYZ atuais do commit da ramificação de desenvolvimento original não podem ser removidas.
  • Bug (nova versão): adicione uma nova tag Bug: XYZ, em que XYZ corresponde ao ID do bug associado à solicitação de nova versão atual.
  • Atualize a tag de commit UPSTREAM, se necessário: ao fazer cherry-pick de uma CL do branch de desenvolvimento para o branch de lançamento, e a CL estiver marcada como UPSTREAM, considere os seguintes cenários:
    • Se a CL for aplicada corretamente à ramificação de lançamento, não será necessário fazer mais nada.
    • Se a CL não for aplicada corretamente, corrija os conflitos, atualize a tag para BACKPORT e documente o que foi feito como parte da resolução de conflitos. Consulte Requisitos para backports do Linux principal.

Prioridade e ESRT

Atribua uma prioridade (urgência) à solicitação de nova geração para ajudar a equipe do GKI a priorizar. Essa prioridade ajuda a equipe da GKI a atender melhor os parceiros de maneira oportuna.

  • Para solicitações urgentes ou críticas, marque a prioridade como P0.
  • Para solicitações P0 e P1, você também precisa justificar a urgência.

A tabela a seguir mostra um mapeamento da prioridade do bug e do tempo até a resolução (ESRT, na sigla em inglês):

PrioridadeESRT
P02 dias úteis
P15 dias úteis
P210 dias úteis
P315 dias úteis

Políticas de SLA

  • Envie uma solicitação de nova versão separada para cada ramificação de lançamento.
  • Se você tiver mudanças em uma solicitação de nova versão marcada como corrigida, envie uma nova solicitação. Não reabra a solicitação para adicionar mais listas de mudanças (CLs).
  • Se um pedido de nova geração exigir sua resposta e você não responder em até três dias úteis, a prioridade será reduzida em um nível. Por exemplo, P0 será reduzida para P1.
  • Se você não responder em duas semanas, o bug será marcado como Não será corrigido (obsoleto).

Enviar um pedido de nova versão

O diagrama a seguir mostra o processo de nova tentativa. O processo começa quando o parceiro OEM (você) envia a solicitação de nova versão.

Processo de nova geração de emergência Figura 1.Processo de respin de emergência.

Para enviar um pedido de nova versão:

  1. Preencha o formulário de solicitação de nova versão do GKI e entre em contato com seu ponto de contato do Google imediatamente.

    • Este formulário cria um bug de solicitação de regeração da GKI.

  2. Prepare seus patches:

    • Verifique se o patch foi mesclado à ramificação de desenvolvimento do GKI.
    • Aplique o patch à ramificação de lançamento do GKI apropriada.
    • Altere o patch escolhido para incluir uma tag Bug: XYZ que cite o ID da solicitação de nova geração.

    Exemplo:Para fazer cherry-pick de uma CL de android16-6.12 para android16-6.12-2025-12:

    # 1. Checkout the target release branch
git checkout android16-6.12-2025-12

# 2. Fetch the upstream development branch (Source of Truth)
git fetch aosp android16-6.12

# 3. Cherry-pick the commit (Preserving metadata)
git cherry-pick -x <commit_hash>

# 4. Update the commit message to include the Respin Bug ID
# (Do not remove existing Bug IDs or change the Change-Id)

  3. Envie o bug. Depois que você envia a solicitação, acontece o seguinte:

    • Processo de revisão após um envio:

      • A equipe do GKI do Google analisa a solicitação e a aprova ou a atribui de volta a você se precisar de mais informações.
      • Depois que uma correção é acordada, a equipe do Google GKI faz uma revisão do código da mudança. O timer da ESRT fica ativo durante essa análise. No entanto, se o patch for rejeitado ou precisar de reformulação, o timer do ESRT será redefinido.
      • A equipe do GKI faz a fusão, cria, testa a regressão e certifica a mudança.

    • Versão: