Cómo solicitar un respin

Un respin es el proceso de volver a fusionar, compilar, probar y certificar un objeto binario después de un lanzamiento público del kernel de GKI.

Antes de solicitar un respin, ten en cuenta los siguientes lineamientos.

Elegibilidad y ciclo de vida

  • Momento: Solo puedes solicitar respins en las ramas de lanzamiento después de que se haya lanzado una versión pública inicial de una compilación trimestral. Solicita respins para vendor-hooks o cualquier otra función solo para una rama de lanzamiento determinada durante un máximo de seis meses después del lanzamiento público inicial.
  • Seguridad y LTS: Después de seis meses, las ramas son aptas para respin solo para los parches de seguridad que se citan en un Boletín de seguridad de Android (ASB) o las correcciones de errores críticos.
  • Obsoleto: Cuando los requisitos de LTS, definidos por el Boletín de seguridad de Android (ASB), hacen que la rama no cumpla con las normas, esta se considera obsoleta. No se aceptan solicitudes de respin para ramas obsoletas.
    • La fecha de baja de una rama de lanzamiento de GKI determinada se incluye en las notas de compilación de lanzamiento de GKI trimestrales en Versiones. Por ejemplo, la versión de septiembre de 2025 es compatible con los respins hasta marzo de 2027. Esta fecha refleja el ciclo de vida de 18 meses de la versión del kernel de LTS 2.0 para las versiones que comienzan en septiembre de 2025 (las versiones anteriores a septiembre de 2025 tenían un ciclo de vida de 12 meses).
  • Alcance: Solicita respins solo para correcciones de errores urgentes, actualizaciones de listas de símbolos o para aplicar un parche para corregir una función existente.
  • Versiones de GKI de 16 KB: Los respins a pedido para las ramas de GKI de 16 KB compatibles (android15-6.6, android16-6.12 y android17-6.18) siguen el mismo formulario de solicitud de respin, los mismos estándares de envío de parches y el mismo proceso de calificación que las compilaciones de 4 KB. No es necesario que actualices los kernels de 4 KB y 16 KB juntos, aunque te recomendamos que lo hagas.

Estándares de envío de parches

Para cumplir con el tiempo de resolución estándar esperado (ESRT) para el procesamiento de solicitudes de respin, todos los parches enviados a una rama de lanzamiento deben cumplir con las siguientes reglas técnicas.

Fuente de información y cherry-picks

  • Primero la rama de desarrollo: Todos los parches que ingresan en la rama de lanzamiento trimestral ya deben fusionarse en la rama de desarrollo principal de GKI. Por ejemplo, si se requiere un parche para un respin de android15-6.6-2025-08, ya debe fusionarse en android15-6.6.
  • Cherry-pick limpio: Debes seleccionar parches directamente de la rama de desarrollo. No selecciones parches de otras ramas de lanzamiento (por ejemplo, no selecciones de 2025-08 a 2025-09), ya que esto puede generar información de autor o confirmación que no sea coherente con la versión de la rama de desarrollo. No se aceptarán parches con información incoherente.
  • Conservar metadatos: Conserva los metadatos de confirmación originales (por ejemplo, el autor y la marca de tiempo original). Usa git cherry-pick -x para conservar los metadatos.

Cadena de confirmaciones

  • Cadena secuencial: Si la solicitud de respin incluye varios parches, cárgalos como una cadena de confirmaciones única y secuencial.
  • Ubicación de ABI y KMI: Si un respin de varios parches incluye actualizaciones de la interfaz de módulo de kernel (KMI) y la interfaz binaria de aplicación (ABI) (por ejemplo, cambios en la lista de símbolos o actualizaciones de archivos XML/STG), coloca estas confirmaciones al final de la cadena de confirmaciones.
  • Rebasing: Si editas una confirmación superior en la cadena, debes rebasar todos los parches secundarios sobre la revisión más reciente de su parche superior para evitar fallas de compilación.
  • Resolución de conflictos: Verifica que no haya marcadores de conflicto en ningún parche.
  • Verificación de compilación: Toda la cadena de confirmaciones debe compilarse correctamente.

Etiquetas obligatorias

El progreso de la solicitud de respin se bloquea sin las siguientes etiquetas en el mensaje de confirmación:

  • Change-Id: Debe ser idéntico al Change-Id del cambio de la rama de desarrollo.
    • Excepción: Si el parche se fusionó en la rama de desarrollo como parte de una actualización de LTS, debe ser un cherry-pick de la versión de LTS y tener el formato de un parche UPSTREAM. Consulta Cómo enviar parches a kernels comunes de Android.
  • Bug (existente): No se deben quitar las etiquetas Bug: XYZ existentes de la confirmación original de la rama de desarrollo.
  • Bug (respin): Debes agregar una nueva etiqueta Bug: XYZ, en la que XYZ corresponde al ID de error asociado con la solicitud de respin actual.
  • Actualiza la etiqueta de confirmación UPSTREAM si es necesario: Cuando selecciones una CL de la rama de desarrollo a la rama de lanzamiento y la CL esté etiquetada como UPSTREAM, considera las siguientes situaciones:
    • Si la CL se aplica correctamente a la rama de lanzamiento, no es necesario que realices ninguna acción adicional.
    • Si la CL no se aplica correctamente, corrige los conflictos, actualiza la etiqueta a BACKPORT y documenta lo que se hizo como parte de la resolución de conflictos. Consulta Requisitos para los backports de Linux principal.

Prioridad y ESRT

Asigna una prioridad (urgencia) a la solicitud de respin para ayudar al equipo de GKI a priorizar. Esta prioridad ayuda al equipo de GKI a ayudar mejor a los socios de manera oportuna.

  • Para las solicitudes críticas o urgentes, marca la prioridad como P0.
  • Para las solicitudes P0 y P1, también debes justificar la urgencia.

En la siguiente tabla, se proporciona una asignación de la prioridad de errores y el tiempo de resolución (ESRT):

PrioridadESRT
P0Dos días hábiles
P15 días hábiles
P210 días hábiles
P315 días laborables

Políticas de ANS

  • Envía una solicitud de respin independiente para cada rama de lanzamiento.
  • Si tienes cambios en una solicitud de respin marcada como corregida, envía una nueva solicitud de respin. No vuelvas a abrir la solicitud para agregar listas de cambios (CL) adicionales.
  • Si una solicitud de respin requiere tu respuesta y no respondes en un plazo de tres días hábiles, la prioridad se reduce en un nivel, por ejemplo, P0 se reduce a P1.
  • Si no respondes durante dos semanas, el error se marca como No se corregirá (Obsoleto).

Envía una solicitud de respin

En el siguiente diagrama, se muestra el proceso de respin. El proceso comienza cuando el socio OEM (tú) envía la solicitud de respin.

Proceso de reenvío de emergencia Figura 1.Proceso de respin de emergencia

Para enviar una solicitud de respin, haz lo siguiente:

  1. Completa el formulario de solicitud de respin de GKI y comunícate con tu punto de contacto de Google de inmediato.

    • Este formulario crea un error de solicitud de respin de GKI.

  2. Prepara tus parches:

    • Verifica que el parche se haya fusionado en la rama de desarrollo de GKI.
    • Aplica el parche a la rama de lanzamiento de GKI adecuada.
    • Modifica el parche seleccionado para incluir una etiqueta Bug: XYZ que cite el ID de solicitud de respin.

    Ejemplo: Para seleccionar una CL de android16-6.12 a android16-6.12-2025-12, haz lo siguiente:

    # 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. Envía el error. Esto sucederá después de que envíes la solicitud:

    • Proceso de revisión después de que se realiza un envío:

      • El equipo de GKI de Google revisa la solicitud y la aprueba o te la asigna nuevamente si se necesita más información.
      • Después de que se acuerda una corrección, el equipo de GKI de Google revisa el código del cambio. El cronómetro de ESRT está activo durante esta revisión. Sin embargo, si se rechaza el parche o requiere una reelaboración, el cronómetro de ESRT se restablece.
      • El equipo de GKI fusiona, compila, prueba la regresión y certifica el cambio.

    • Lanzamiento:

      • El objeto binario se lanza a ci.android.com.
      • Finaliza el plazo de ESRT, y el equipo de GKI de Google marca la solicitud como corregida y hace referencia a la compilación de respin.
      • La compilación de respin también se publica en la página de compilaciones de lanzamiento de la imagen de kernel genérica (GKI).