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

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

График выпуска GKI

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

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

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

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

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

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

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

Процесс аварийного повторного вращения

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

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

Обновления безопасности автоматически объединяются с веткой релиза в течение 6 месяцев после выпуска этой ветки. По истечении 6 месяцев для применения обновлений безопасности к ветке необходимо запросить повторный выпуск (repin).

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

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

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

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

  • Bug : идентификатор ошибки необходимо добавить в сообщение коммита для каждого изменения кода.
  • 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) .

Квалификации GKI

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

Документацию по всем релизам можно получить на сайте ci.android.com .

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

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

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

Возможно ли создать новый бинарный файл GKI на основе уже выпущенного GKI?

Да, это называется пересборкой (respin). Процесс пересборки поддерживается до тех пор, пока выпущенная сборка 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 (включая аварийный патч) на основе последней версии кода?

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

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

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

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

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

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

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