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

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

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

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

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

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

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

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

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

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

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

Рисунок 1. Хронология выпуска GKI

Процесс экстренного респина

Респин (respin) — это процесс повторного объединения, сборки, тестирования и повторной сертификации исполняемого файла после публичного выпуска ядра 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):

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

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

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

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

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

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

Подать запрос на респин

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

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

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

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

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

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

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

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

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

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

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

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

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