Cómo solicitar un respin

Un respin es el proceso de volver a combinar, recompilar, volver a probar y volver a 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 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 los enlaces del proveedor 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 para los parches de seguridad que se citan en un Boletín de seguridad de Android (ASB) o las correcciones de errores críticos.
  • 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 creación 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 lanzamiento deben cumplir con las siguientes reglas técnicas.

Fuente de información y selecciones

  • 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.
  • Selección puntual limpia: Debes seleccionar puntualmente los parches directamente desde la rama de desarrollo. No selecciones puntualmente de otras ramas de versiones (por ejemplo, no selecciones puntualmente 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.
  • Conservar metadatos: 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 reenvío 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 una selección puntual de la versión de LTS y tener el formato de un parche de UPSTREAM. Consulta Cómo enviar parches a los kernels comunes de Android.
  • Bug (existente): No se deben quitar las etiquetas Bug: XYZ existentes de la confirmación de la rama de desarrollo original.
  • Bug (nueva versión): Debes agregar una nueva etiqueta Bug: XYZ, en la que XYZ corresponde al ID de error asociado con la solicitud de nueva versión actual.
  • Actualiza la etiqueta de confirmación UPSTREAM si es necesario: Cuando se realice un cherry-pick de un CL de la rama de desarrollo a la rama de lanzamiento, y el CL esté etiquetado 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 más listas de cambios (CL).
  • 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 nueva versión.

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

Para enviar una solicitud de respin, sigue estos pasos:

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

    • 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 puntualmente 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, ocurrirá 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 corrección, el equipo de 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: