Как запросить повторную проверку

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

Прежде чем запросить повторную проверку, ознакомьтесь с приведенными ниже рекомендациями.

Требования и жизненный цикл

  • Время. Запрашивать повторные сборки можно только для веток релизов после того, как будет запущен первый публичный релиз квартальной сборки. Запросы на повторную проверку для хуков поставщика или других функций принимаются только для определенной ветки выпуска в течение шести месяцев после первоначального публичного выпуска.
  • Безопасность и LTS. Через шесть месяцев ветви можно будет пересобрать только для установки исправлений уязвимостей, указанных в бюллетене по безопасности Android (ASB), или критических исправлений ошибок.
  • Прекращение поддержки. Если требования к LTS, определенные в бюллетене по безопасности Android (ASB), приводят к тому, что ветвь перестает соответствовать требованиям, ее поддержка прекращается. Запросы на повторную проверку устаревших веток не принимаются.
    • Дата прекращения поддержки для определенной ветки выпуска GKI указывается в примечаниях к ежеквартальному выпуску GKI в разделе "Выпуски". Например, версия от сентября 2025 года поддерживается для повторных выпусков до марта 2027 года. Эта дата отражает срок поддержки ядра LTS 2.0, который составляет 18 месяцев для выпусков, начиная с сентября 2025 года (для выпусков до сентября 2025 года срок поддержки составлял 12 месяцев).
  • Область применения. Запрашивайте повторную сборку только для срочного исправления ошибок, обновления списка символов или применения патча для исправления существующей функции.

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

Чтобы соблюдать ожидаемое стандартное время обработки запроса на повторную проверку, все исправления, отправленные в ветку выпуска, должны соответствовать следующим техническим правилам.

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

  • Сначала ветка разработки. Все исправления, которые будут включены в квартальный выпуск, должны быть объединены с основной веткой разработки 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, рассмотрите следующие сценарии:
    • Если список изменений применяется к ветке выпуска без проблем, никаких дополнительных действий не требуется.
    • Если список изменений не применяется, устраните конфликты, обновите тег до BACKPORT и задокументируйте действия, выполненные для устранения конфликтов. Подробную информацию можно найти в разделе Требования к бэкпортам из основной ветки Linux.

Приоритет и ESRT

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

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

В таблице ниже приведена зависимость между приоритетом ошибки и временем ее устранения (ESRT).

ПриоритетESRT
P02 рабочих дня
P15 рабочих дней
P210 рабочих дней
P315 рабочих дней

Правила SLA

  • Для каждой ветви релиза нужно отправить отдельный запрос на повторную обработку.
  • Если у вас есть изменения в запросе на повторную публикацию, который помечен как исправленный, отправьте новый запрос. Не открывайте запрос повторно, чтобы добавить дополнительные списки изменений.
  • Если запрос на повторную сборку требует вашего ответа и вы не отвечаете в течение трех рабочих дней, приоритет понижается на один уровень, например с 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.
      • Обновленная сборка также опубликована на странице конечных сборок GKI.