Процесс выпуска универсального образа ядра (GKI)

На этой странице описывается, как выпускается GKI, включая еженедельные, ежемесячные и внеплановые экстренные выпуски. Цель этого документа — дать OEM-производителям рекомендации о том, где получить GKI, а также о процессе внеплановых аварийных исправлений. OEM-производители также могут использовать разработку GKI, чтобы узнать больше о том, как они могут работать с командой Android Kernel над оптимизацией ядра GKI для своих продуктов.

Частота выпуска GKI

GKI выпускается ежемесячно после заморозки KMI.

Выпуск Android 13, 14 и 15 GKI

Следующая таблица применима только к android13-5.10 , android13-5.15 и android14-5.15 .

Следующая таблица применима только к android14-6.1 и android15-6.6 .

Выпуск Android 12 GKI

После мая 2024 года выпуски android12-5.10 GKI будут выпускаться ежеквартально и публиковаться в середине месяца. Следующая таблица применима только к android12-5.10 .

Срок действия сборки GKI для OEM-производителей

OEM-производители могут использовать недавно выпущенный Android GKI. OEM-производители могут запускать сборки, сертифицированные GKI, при условии, что они соответствуют требованиям LTS в Бюллетене безопасности Android (ASB).

Еженедельные выпуски разработки

Двоичные файлы GKI доступны для самообслуживания в Android CI по мере объединения изменений. Еженедельные сборки не будут сертифицированы, но могут использоваться в качестве основы для разработки и тестирования. Еженедельные сборки нельзя использовать для сборок рабочих устройств для конечных пользователей.

Ежемесячные сертифицированные выпуски

Ежемесячные выпуски GKI содержат протестированный boot.img , который включает в себя вставленный сертификат Google, подтверждающий, что двоичные файлы были созданы на основе известного базового исходного кода.

Каждый месяц кандидат на ежемесячный выпуск GKI (не сертифицированный) выбирается после конечной даты регистрации, которая обычно является второй еженедельной сборкой этого месяца. После выбора кандидата на ежемесячный выпуск новые изменения не будут приняты в выпуск этого месяца. В период закрытого окна можно устранять только исправления ошибок, которые приводят к сбою теста. Кандидат на выпуск проходит проверку качества, как описано в разделе квалификации GKI , чтобы гарантировать прохождение тестов на соответствие сборке GSI+GKI с эталонным устройством, а также с каракатицей.

Рисунок 1. График выпуска GKI

Экстренный процесс респина

Респин — это процесс повторного объединения, пересборки, повторного тестирования и повторной сертификации двоичного файла после публичного выпуска ядра GKI . Вы можете запросить повторную отправку сертифицированного двоичного файла в любом из следующих случаев:

• Чтобы обновить список символов.
• Чтобы применить исправление к ошибке, включая ошибки, обнаруженные во время утверждения лабораторией оператора связи.
• Чтобы добавить крючок поставщика .
• Чтобы применить исправление к существующей функции.
• Применить патч безопасности (через 6 месяцев).

Исправления безопасности автоматически добавляются в ветку выпуска на срок до 6 месяцев после выпуска ветки. По истечении 6-месячного периода вы должны запросить повторную подписку, чтобы применить исправления безопасности к филиалу.

Рекомендации по запросу повторного вращения

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

• Респины разрешены только в ветках выпуска после запуска первоначального публичного выпуска ежемесячной сборки .

• Запросы на повторную отправку принимаются только для определенной ветки выпуска в течение максимум шести месяцев после первоначального публичного выпуска. По истечении шести месяцев филиалы имеют право на продление только для исправлений безопасности, указанных в бюллетене по безопасности Android .

• Если требования LTS , определенные Бюллетенем по безопасности Android (ASB), приводят к несоответствию ветки, она считается устаревшей. Запросы на повторную отправку устаревших веток не принимаются. Дата прекращения поддержки конкретной ветки выпуска GKI включена в ежемесячные примечания к сборке выпуска GKI в разделе «Релизы» . Для будущего планирования требования LTS обновляются ежегодно в мае и ноябре. Например, ветка android12-5.10-2023-07 (5.10.177) не поддерживается для повторных вращений после 1 мая 2024 г., поскольку ветка android12-5.10-2023-07 (5.10.177) не соответствует требованиям Требования LTS АСБ-2024-05.

• Респины применимы только для срочного исправления ошибок, обновления списка символов или для применения патча для исправления существующей функции.

• Все патчи, входящие в ветку ежемесячного выпуска, уже должны быть объединены в основную ветку разработки GKI. Например, если для респина android12-5.10-2022-09 требуется патч, он уже должен быть объединен с android12-5.10 .

• Вы должны выбрать патчи из основной ветки разработки GKI и загрузить их в ветку ежемесячного выпуска.

• В запросе на респин необходимо присвоить запросу приоритет (срочность). Этот приоритет помогает команде GKI лучше и своевременно оказывать помощь партнерам. Для критических или срочных запросов отметьте приоритет как P0 . Для запросов P0 и P1 также необходимо обосновать срочность. В следующей таблице представлено сопоставление приоритета ошибки и времени ее устранения (ESRT):

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

• Вы должны отправить отдельный запрос на повторную отправку для каждой ветки выпуска. Например, если повторное вращение требуется как для android12-5.10-2022-08 , так и android12-5.10-2022-09 , необходимо создать два запроса на повторное вращение.

• После того как сборка предоставлена ​​и запрос на повторную отправку помечен как исправленный, вам не следует повторно открывать запрос на повторную отправку, чтобы добавить дополнительные CL. Вы должны отправить новый запрос на повторную отправку, если есть дополнительные исправления, которые необходимо объединить.

• Для каждого рассматриваемого CL добавьте следующие теги.

  • Bug : идентификатор ошибки должен быть добавлен в сообщение фиксации для каждого CL.
  • Change-Id : должен быть идентичен Change-Id изменения базовой ветки.

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

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

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

Рисунок 2. Процесс респина

Чтобы войти в процесс респина:

1. Заполните форму запроса GKI Respin . и немедленно обратитесь к своему техническому менеджеру Google. Эта форма создает ошибку запроса повторного запуска GKI. Ошибки запроса на повторную отправку видны вам (запрашивающему), команде GKI и конкретным людям, которых вы добавляете в список CC об ошибке.
   • Если у вас уже есть исправление, запрос должен указывать на отправку исправления в AOSP, чтобы Google мог его просмотреть. Если отправить исправление невозможно, его необходимо приложить к запросу в виде текстового файла.
   • Если у вас нет исправления, запрос должен содержать как можно больше информации, включая номер версии ядра и журналы, чтобы Google мог помочь устранить проблему.
2. Команда Google GKI рассматривает запрос и одобряет его или возвращает его вам, если требуется дополнительная информация.
3. После согласования исправления команда Google GKI проверяет его код (CR+2). Проверка начинается с периода ESRT. Команда GKI объединяет, собирает, тестирует на предмет регрессии и сертифицирует изменения.
4. Бинарный файл доступен на ci.android.com . Срок ESRT заканчивается, и команда Google GKI помечает запрос как исправленный и ссылается на сборку повторного запуска. Сборка Respin также будет размещена на странице сборок выпусков Generic Kernel Image (GKI) .

Квалификация ГКИ

Где взять артефакты сборки

Артефакты для всех выпусков можно получить на сайте ci.android.com .

Дополнительную информацию о CI, включая результаты тестирования, можно найти на панели мониторинга непрерывной интеграции Android .

Часто задаваемые вопросы

Вот некоторые часто задаваемые вопросы, связанные с процессом выпуска GKI.

Можно ли создать новый двоичный файл GKI на основе уже выпущенного GKI?

Да, это называется респином. Процесс повторного запуска поддерживается до тех пор, пока выпущенная сборка GKI (для которой запрашивается повторный запуск) соответствует требованиям LTS в Бюллетене безопасности Android (ASB).

Можно ли воспроизвести двоичные файлы GKI?

Да, вот пример:

GKI 2.0
5.10 kernel prebuilts from build 7364300
https://ci.android.com/builds/submitted/7364300/kernel_aarch64/latest

Чтобы воспроизвести пример, загрузите файл manifest_$id.xml и выполните следующую команду:

repo init -u https://android.googlesource.com/kernel/manifest
mv manifest_7364300.xml .repo/manifests
repo init -m manifest_7364300.xml --depth=1
repo sync
# build the GKI images
# You may want to use LTO=thin to build faster for development
BUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh
# (optional) build virtual platform modules
BUILD_CONFIG=common-modules/virtual-device/build.config.virtual_device.aarch64 build/build.sh

Вы можете получить копию артефакта GKI из out/.../dist .

Был ли двоичный файл GKI (включая аварийный патч) построен на последней кодовой базе?

Нет. Респины содержат только те исправления, которые находятся поверх выбранных ежемесячно сертифицированных ядер. Эти респины содержат все исправления ошибок, блокирующих запуск, о которых до определенного момента сообщали OEM-производители, использующие соответствующий базовый ежемесячный выпуск. См. следующий пример того, как происходит этот тип сценария.

• OEM1 и OEM2 решили использовать двоичный выпуск GKI с ноября 2021 года.
• OEM1 и OEM2 находят проблемы, требующие исправлений для поддержки. Эти патчи могут быть разными или могут быть одинаковыми.
• Респины поверх бинарного файла за ноябрь 2021 года содержат исправления блокировки запуска, о которых сообщили как OEM1, так и OEM2 во время окна респинов, но не более того.
• Проблемы, упомянутые во втором пункте, также включаются в последующие ежемесячные выпуски GKI.

В октябрьском выпуске представлены все исправления, представленные OEM-производителями, но другие исправления OEM-производителей затрагивают нас, поскольку они не были специально протестированы с нашими продуктами. Можно ли включить только наш патч?

Это невозможно. Путь ответа «для каждого OEM» не масштабируется. Вместо этого команда GKI тщательно изучает каждое изменение, вносимое в повторные сборки, и тестирует изменения на всем доступном оборудовании перед созданием новой сборки. Если команда GKI обнаружит, что проблема связана с OEM, устройством или моделью, команда GKI может гарантировать, что код, добавленный в результате изменения, выполняется только на затрагиваемом устройстве, модели или SKU.

Основное преимущество унифицированных повторов заключается в том, что каждое устройство, использующее одну и ту же базу выпусков, получает выгоду друг от друга, особенно если обнаруженные ими ошибки являются общими и применимы ко всем пользователям. Ошибки ядра, обнаруженные при тестировании операторов связи, являются конкретным примером этой концепции.

Бывают ли ситуации, когда Google предоставляет конкретную информацию об исправлениях OEM и сценариях проблем, чтобы OEM-производители могли оценить влияние и риск внедрения исправлений в свои продукты?

Google никогда не внесет изменения в сборку респина, пока проблема не будет понята и все детали не собраны. Это видно в журнале изменений (сообщение о фиксации). Google не раскрывает, на какое именно устройство это влияет, но OEM-производители всегда могут найти описание проблемы и решение в журнале изменений.