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

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

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

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

Валидность сборки GKI для OEM-производителей

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

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

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

Ежеквартальные сертифицированные релизы

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

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

Рисунок 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 ASB-2024-05.

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

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

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

• В запросе на повторный запуск необходимо назначить приоритет (срочность) запросу. Этот приоритет помогает команде GKI лучше и своевременно помогать партнерам. Для критических или срочных запросов отметьте приоритет как P0 . Для запросов P0 и P1 необходимо также обосновать срочность. В следующей таблице приведено сопоставление приоритета ошибки и времени ее устранения (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 Respin. Ошибки запроса Respin видны вам (запрашивающему), команде GKI и конкретным лицам, которых вы добавляете в список CC ошибки.
   • Если у вас уже есть исправление, запрос должен ссылаться на отправку исправления в AOSP, чтобы Google мог его рассмотреть. Если отправка исправления невозможна, исправление должно быть прикреплено к запросу в виде текстового файла.
   • Если у вас нет решения, запрос должен содержать как можно больше информации, включая номер версии ядра и журналы, чтобы Google мог помочь устранить проблему.
2. Команда Google GKI рассматривает запрос и одобряет его или возвращает вам, если требуется дополнительная информация.
3. После согласования исправления команда Google GKI проверяет код (CR+2) изменения. Проверка начинает временные рамки ESRT. Команда GKI объединяет, строит, тестирует на регрессию и сертифицирует изменение.
4. Двоичный файл выпускается на ci.android.com . Срок ESRT заканчивается, и команда Google GKI отмечает запрос как исправленный и ссылается на сборку respin. Сборка respin также публикуется на странице сборок релиза Generic Kernel Image (GKI) .

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

Где получить артефакты для сборки

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

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

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

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

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

Да, это известно как респин. Процесс респина поддерживается, пока выпущенная сборка GKI (для которой запрашивается респин) соответствует требованиям LTS в Android Security Bulletin (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-патчи влияют на нас, потому что они не были специально протестированы с нашими продуктами. Возможно ли включить только наш патч?

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

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

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

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