Pedir uma nova versão

Um respin é o processo de mesclagem, reconstrução, novo teste e recertificação de um binário após um lançamento público do kernel GKI.

Antes de solicitar um respin, observe as diretrizes a seguir.

Qualificação e ciclo de vida

  • Tempo:só é possível solicitar respins em ramificações de lançamento após o lançamento público inicial de um build trimestral. Solicite respins de 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 passar por respin apenas 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), fazem com que a ramificação não esteja em conformidade, ela é descontinuada. Não é possível fazer solicitações de respin 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 trimestral do GKI em "Lançamentos". Por exemplo, o lançamento de setembro de 2025 tem suporte para respins até março de 2027. Essa data reflete o ciclo de vida da versão do kernel LTS 2.0 de 18 meses 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 respins apenas para correções de bugs urgentes, atualizações de lista de símbolos ou para aplicar um patch para corrigir um recurso atual.

Padrões de envio de patch

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

Fonte de verdade e cherry-picks

  • Ramificação de desenvolvimento primeiro:todos os patches que entram na ramificação de lançamento trimestral já precisam ser mesclados na ramificação de desenvolvimento principal do GKI. Por exemplo, se um patch for necessário para um respin de android15-6.6-2025-08, ele já precisará ser mesclado em android15-6.6.
  • Cherry-pick limpo:é necessário fazer cherry-pick de patches diretamente da ramificação de desenvolvimento. Não faça cherry-pick de outras ramificações de lançamento (por exemplo, não escolha 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:preserve os metadados de commit originais (por exemplo, autor, carimbo de data/hora original). Use git cherry-pick -x para preservar os metadados.

Cadeia de commits

  • Cadeia sequencial:se a solicitação de respin envolver vários patches, faça o upload deles como uma cadeia única e 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 pai na cadeia, será necessário fazer rebase de todos os patches filhos na revisão mais recente do patch pai 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.

Tags obrigatórias

O progresso na solicitação de respin é 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 na ramificação de desenvolvimento como parte de uma atualização do LTS, ele precisa fazer 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 original da ramificação de desenvolvimento não podem ser removidas.
  • Bug (respin): é necessário adicionar uma nova tag Bug: XYZ, em que XYZ corresponde ao ID do bug associado à solicitação de respin atual.
  • Atualize a tag de commit UPSTREAM se necessário: ao fazer cherry-pick de um CL da ramificação de desenvolvimento para a ramificação de lançamento, e o CL estiver marcado como UPSTREAM, considere os seguintes cenários:
    • Se o CL for aplicado corretamente à ramificação de lançamento, não será necessário fazer mais nada.
    • Se o CL não for aplicado 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 respin para ajudar a equipe do GKI a priorizar. Essa prioridade ajuda a equipe do GKI a ajudar melhor parceiros de maneira oportuna.

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

A tabela a seguir fornece um mapeamento da prioridade do bug e do tempo de resolução (ESRT):

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

Políticas de SLA

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

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

Para enviar uma solicitação de respin:

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

    • Esse formulário cria um bug de solicitação de respin do GKI.

  2. Prepare seus patches :

    • Verifique se o patch foi mesclado na 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 cita o ID da solicitação de respin.

    Exemplo: Para fazer cherry-pick de um 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. O seguinte ocorre depois que você envia a solicitação:

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

      • A equipe do GKI do Google 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, a equipe do GKI do Google revisa o código da mudança. O timer ESRT fica ativo durante essa revisão. No entanto, se o patch for rejeitado ou exigir retrabalho, o timer ESRT será redefinido.
      • A equipe do GKI mescla, cria, testa a regressão e certifica a mudança.

    • Lançamento :