Cómo solicitar un respin

Un respin es el proceso de volver a combinar, recompilar, volver a probar y volver a certificar un archivo binario después del 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 ramas de versiones después de que se haya lanzado una versión pública inicial de una compilación trimestral. Solicita nuevas versiones de vendor-hooks o de otras funciones solo para una rama de versión 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 solo son aptas para respin
  • Obsolescencia: 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 la compilación de lanzamiento de GKI trimestrales en Lanzamientos. Por ejemplo, la versión de septiembre de 2025 se admite para los relanzamientos hasta marzo de 2027. Esta fecha refleja la vida útil de 18 meses de la versión del kernel de LTS 2.0 para los lanzamientos a partir de septiembre de 2025 (los lanzamientos anteriores a septiembre de 2025 tenían una vida útil de 12 meses).
  • Alcance: Solicita reenvíos solo para correcciones de errores urgentes, actualizaciones de la lista de símbolos o para aplicar un parche que corrija una función existente.

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 reenvío, todos los parches enviados a una rama de versión deben cumplir con las siguientes reglas técnicas.

Fuente de información y cherry-picks

  • Primero la rama de desarrollo: Todos los parches que se incluyan en la rama de la versión trimestral ya deben haberse combinado con la rama principal de desarrollo del GKI. Por ejemplo, si se requiere un parche para una nueva versión de android15-6.6-2025-08, ya debe haberse combinado en android15-6.6.
  • Cherry-pick limpio: Debes hacer un cherry-pick de los parches directamente desde la rama de desarrollo. No selecciones commits de otras ramas de versiones (por ejemplo, no selecciones de 2025-08 a 2025-09), ya que esto puede generar información del autor o del commit que no sea coherente con la versión de la rama de desarrollo. No se aceptarán parches con información incoherente.
  • Preserve metadata: Conserva los metadatos originales de la confirmación (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 nueva versión implica varios parches, súbelos como una cadena secuencial única de confirmaciones.
  • Ubicación de ABI y KMI: Si una nueva versión de varios parches incluye actualizaciones de la interfaz del módulo del kernel (KMI) y la interfaz binaria de la 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.
  • Cambio de base: Si editas una confirmación principal en la cadena, debes cambiar la base de todos los parches secundarios sobre la revisión más reciente de su parche principal para evitar errores 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 reenvío se bloquea si no se incluyen 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 combinó 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 de UPSTREAM. Consulta How do I submit patches to Android Common Kernels.
  • Bug (existente): No se deben quitar las etiquetas Bug: XYZ existentes de la confirmación de la rama de desarrollo original.
  • 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 se realiza un cherry-pick de un CL de la rama de desarrollo a la rama de lanzamiento, y el CL se etiqueta como UPSTREAM, considera las siguientes situaciones:
    • Si el CL se aplica correctamente a la rama de lanzamiento, no es necesario que realices ninguna acción adicional.
    • Si el 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 las versiones secundarias de Linux.

Prioridad y ESRT

Asigna una prioridad (urgencia) a la solicitud de reenvío para ayudar al equipo del GKI a priorizarla. Esta prioridad ayuda al equipo del GKI a brindar una mejor asistencia a los socios de manera oportuna.

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

En la siguiente tabla, se proporciona una asignación de la prioridad de los errores y el tiempo de resolución estimado (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 reenvío marcada como corregida, envía una nueva solicitud de reenvío. No vuelvas a abrir la solicitud para agregar listas de cambios (CL) adicionales.
  • Si una solicitud de reenvío 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 en dos semanas, el error se marcará como Won't Fix (Obsolete).

Envía una solicitud de respin

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

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

Sigue estos pasos para enviar una solicitud de respin:

  1. Completa el formulario de solicitud de nueva versión del GKI y comunícate de inmediato con tu punto de contacto de Google.

    • Este formulario crea un error de solicitud de reenvío de GKI.

  2. Prepara los parches:

    • Verifica que el parche se haya combinado en la rama de desarrollo del 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 la solicitud de reenvío.

    Ejemplo: Para seleccionar un CL de android16-6.12 a 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. Envía el error. Después de enviar la solicitud, sucede lo siguiente:

    • Proceso de revisión después del envío:

      • El equipo del GKI de Google revisa la solicitud y la aprueba o te la reasigna si se necesita más información.
      • Después de acordar una solución, el equipo del GKI de Google revisa el código del cambio. El temporizador de ESRT está activo durante esta revisión. Sin embargo, si se rechaza el parche o requiere una revisión, se restablece el temporizador del ESRT.
      • El equipo del GKI combina, compila, prueba la regresión y certifica el cambio.

    • Versión: