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

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

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

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

  • Сроки. Запрашивать повторные сборки можно только для веток выпуска после того, как была опубликована первоначальная общедоступная версия ежеквартальной сборки. Запрашивайте повторные сборки для хуков поставщиков или других функций только для определенной ветки выпуска в течение максимум шести месяцев после первоначального публичного выпуска.
  • Безопасность и LTS. Через шесть месяцев ветви могут быть пересобраны только для исправлений уязвимостей, указанных в бюллетене по безопасности Android, или критических исправлений ошибок.
  • Устаревание. Если требования LTS, определенные в бюллетене по безопасности Android (ASB), приводят к тому, что ветвь становится несовместимой, она устаревает. Запросы на повторную сборку для устаревших ветвей не принимаются.
    • Дата прекращения поддержки для определенной ветки выпуска GKI указывается в примечаниях к ежеквартальному выпуску GKI в разделе "Выпуски". Например, выпуск за сентябрь 2025 года поддерживается для респинов до марта 2027 года. Эта дата отражает срок поддержки ядра LTS 2.0, который составляет 18 месяцев для выпусков, начиная с сентября 2025 года (для выпусков до сентября 2025 года срок поддержки составлял 12 месяцев).
  • Область применения. Запрашивайте повторную сборку только для срочного исправления ошибок, обновления списка символов или применения патча для исправления существующей функции.
  • Выпуски GKI с поддержкой страниц размером 16 КБ. Для поддерживаемых ветвей GKI с поддержкой страниц размером 16 КБ (android15-6.6, android16-6.12 и android17-6.18) действуют те же форма запроса на повторную сборку по запросу, стандарты отправки исправлений и процесс квалификации, что и для сборок с поддержкой страниц размером 4 КБ. Обновлять ядра с размером страницы 4 КБ и 16 КБ одновременно не обязательно, но мы рекомендуем это делать.

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

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

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

  • Сначала ветка разработки. Все исправления, которые будут включены в квартальный выпуск, должны быть объединены с основной веткой разработки 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.