Pedir uma nova versão

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

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

Qualificação e ciclo de vida

• Tempo:só é possível solicitar respins em ramificações de lançamento depois que um lançamento público inicial de um build trimestral for lançado. Solicite respins 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 passar por respin apenas para patches de segurança citados em um Boletim de Segurança do Android (ASB, na sigla em inglês) 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.
• Lançamentos de GKI de 16 KB: os respins sob demanda para ramificações de GKI de 16 KB com suporte (android15-6.6, android16-6.12, e android17-6.18) seguem o mesmo formulário de solicitação de respin, padrões de envio de patch e processo de qualificação que os builds de 4 KB. Não é necessário atualizar os kernels de 4 KB e 16 KB juntos, embora seja recomendável.

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 seguir as regras técnicas a seguir.

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 principal de desenvolvimento 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, na sigla em inglês) e interface binária de aplicativo (ABI, na sigla em inglês) (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 com sucesso.

Tags obrigatórias

O progresso na solicitação de respin é bloqueado sem as tags a seguir 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 precisará 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 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 uma CL da ramificação de desenvolvimento para a ramificação de lançamento, e a CL estiver marcada como UPSTREAM, considere os cenários a seguir:
  • 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 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):

Prioridade	ESRT
P0	2 dias úteis
P1	5 dias úteis
P2	10 dias úteis
P3	15 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 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 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.

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.
   • Modifique o patch de cherry-pick para incluir uma tag Bug: XYZ que cite o ID da solicitação de respin.

   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. 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 :

     • O binário é lançado em ci.android.com.
     • O período do ESRT termina, e a equipe do GKI do Google marca a solicitação como corrigida e faz referência ao build de respin.
     • O build de respin também é postado na página Builds de lançamento de imagens genéricas do kernel (GKI, na sigla em inglês).