Запросить повторное вращение

Пересборка (respin) — это процесс повторного объединения, пересборки, повторного тестирования и повторной сертификации бинарного файла после публичного выпуска ядра GKI .

Перед тем как запросить повторное вращение барабанов, ознакомьтесь со следующими правилами.

Критерии отбора и жизненный цикл

  • Сроки: Запросы на повторное создание репозиториев можно отправлять только для релизных веток после первоначального публичного релиза квартальной сборки. Запросы на повторное создание репозиториев для vendor-hooks или других функций можно отправлять только для данной релизной ветки в течение максимум шести месяцев после первоначального публичного релиза.
  • Безопасность и LTS: По истечении шести месяцев ветки могут быть перезапущены только для установки исправлений безопасности, указанных в бюллетене безопасности Android (ASB), или критических исправлений ошибок.
  • Устаревание: Если требования LTS, определенные в бюллетене безопасности Android (ASB), приводят к тому, что ветка перестает соответствовать этим требованиям, она объявляется устаревшей. Запросы на перезапуск устаревших веток не принимаются.
    • Дата прекращения поддержки для конкретной ветки релизов GKI указана в ежеквартальных примечаниях к сборке релизов GKI в разделе «Релизы». Например, релиз сентября 2025 года поддерживается для повторных выпусков до марта 2027 года. Эта дата отражает срок службы версии ядра LTS 2.0, составляющий 18 месяцев для релизов, начинающихся в сентябре 2025 года (релизы до сентября 2025 года имели срок службы 12 месяцев).
  • Область применения: Запросы на повторное вращение запрашиваются только для срочного исправления ошибок, обновления списка символов или для применения патча, исправляющего существующую функцию.

стандарты отправки патчей

Для соблюдения ожидаемого стандартного времени разрешения (ESRT) при обработке запросов на повторную обработку все патчи, отправляемые в ветку релиза, должны соответствовать следующим техническим правилам.

Источник правды и выборочный подход

  • В первую очередь, ветка разработки: все патчи, которые будут включены в ветку ежеквартального релиза, должны быть уже объединены с основной веткой разработки GKI. Например, если требуется патч для переиздания android15-6.6-2025-08 , он должен быть уже объединен с android15-6.6 .
  • Чистый выбор изменений: Вы должны выбирать изменения непосредственно из ветки разработки. Не выбирайте изменения из других веток релизов (например, не выбирайте изменения из 2025-08 в 2025-09 ), так как это может привести к несоответствию информации об авторе или коммите версии в ветке разработки. Изменения с несоответствующей информацией приниматься не будут.
  • Сохранить метаданные: Сохранить исходные метаданные коммита (например, автора, исходную метку времени). Используйте git cherry-pick -x для сохранения метаданных.

Цепочка фиксации

  • Последовательная цепочка: если запрос на повторную обработку включает несколько патчей, загрузите их как единую последовательную цепочку коммитов.
  • Размещение ABI и KMI: Если в результате многократного обновления патчей вносятся изменения в интерфейс модуля ядра (KMI) и двоичный интерфейс приложения (ABI) (например, изменения списка символов или обновления XML/STG-файлов), разместите эти коммиты в самом конце цепочки коммитов.
  • Перебазирование: Если вы редактируете родительский коммит в цепочке, необходимо перебазировать все дочерние патчи поверх последней ревизии родительского патча, чтобы избежать ошибок сборки.
  • Разрешение конфликтов: Убедитесь, что ни в одном из патчей отсутствуют маркеры конфликтов.
  • Проверка сборки: вся цепочка коммитов должна быть успешно собрана.

Обязательные теги

Обработка запроса на повторную отправку блокируется без следующих тегов в сообщении коммита:

  • Change-Id : Должен совпадать с Change-Id изменения в ветке разработки.
  • Существующая Bug : Теги Bug: XYZ из исходного коммита ветки разработки не должны быть удалены.
  • Bug (повторный запуск): Необходимо добавить новый тег Bug: XYZ , где XYZ соответствует идентификатору ошибки, связанному с текущим запросом на повторный запуск.
  • При необходимости обновите тег коммита UPSTREAM : При выборе изменений из ветки разработки в ветку релиза, если эти изменения помечены тегом UPSTREAM , рассмотрите следующие сценарии:
    • Если изменение ветки (CL) корректно применяется к ветке релиза, никаких дополнительных действий не требуется.
    • Если CL применяется некорректно, устраните конфликты, обновите тег до BACKPORT и задокументируйте действия, предпринятые в рамках разрешения конфликтов, см. Требования к бэкпортам из основной ветки Linux .

Приоритет и ESRT

Присвойте запросу на переадресацию приоритет (срочность), чтобы помочь команде GKI расставить приоритеты. Этот приоритет поможет команде GKI оказывать партнерам более эффективную и своевременную помощь.

  • Для критически важных или срочных запросов отметьте приоритет как P0 .
  • Для запросов P0 и P1 необходимо также обосновать срочность.

В следующей таблице представлено соответствие приоритета ошибок и времени их устранения (ESRT):

Приоритет ЭСРТ
П0 2 рабочих дня
П1 5 рабочих дней
П2 10 рабочих дней
П3 15 рабочих дней

Политика SLA

  • Для каждой ветки релиза отправьте отдельный запрос на переиздание.
  • Если вы внесли изменения в запрос на переиздание, помеченный как исправленный, отправьте новый запрос на переиздание. Не открывайте запрос повторно для добавления дополнительных списков изменений (CL).
  • Если запрос на повторную подачу заявки требует вашего ответа, и вы не отвечаете в течение трех рабочих дней, приоритет понижается на один уровень, например, с P0 до P1 .
  • Если вы не ответите в течение двух недель, ошибка будет помечена как «Не будет исправлено (Устарело)» .

Отправить запрос на респиннинг

На следующей диаграмме показан процесс повторного запуска. Процесс начинается, когда OEM-партнер (вы) отправляет запрос на повторный запуск.

Процесс аварийного повторного вращения Рисунок 1. Процесс аварийного повторного вращения.

Чтобы отправить запрос на переспин:

  1. Заполните форму запроса на респин в GKI и немедленно свяжитесь со своим контактным лицом в Google.

    • Эта форма создает ошибку в запросе на переспин-код GKI.

  2. Подготовьте свои патчи:

    • Убедитесь, что патч объединен с веткой разработки GKI.
    • Примените патч к соответствующей ветке релиза GKI.
    • Внесите изменения в выбранный патч, добавив метку Bug: XYZ с указанием идентификатора запроса на перепроверку.

    Пример: Чтобы выбрать и перенести изменения из версии android16-6.12 в версию 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. Отправьте сообщение об ошибке. После отправки запроса происходит следующее:

    • Процесс проверки после отправки заявки:

      • Команда Google GKI рассматривает запрос и одобряет его или, если требуется дополнительная информация, возвращает его вам.
      • После согласования исправления команда Google GKI проводит проверку кода. Во время этой проверки активен таймер ESRT. Однако, если патч отклонен или требует доработки, таймер ESRT сбрасывается.
      • Команда GKI выполняет слияние, сборку, регрессионное тестирование и сертификацию изменений.

    • Выпускать:

      • Исполняемый файл опубликован на сайте ci.android.com .
      • Сроки выполнения запроса ESRT истекают, и команда Google GKI помечает запрос как решенный, ссылаясь на повторную сборку.
      • Сборка respin также размещена на странице сборок Generic Kernel Image (GKI) .