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

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

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

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

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

• Когда требования LTS , определяемые бюллетенем Android Security (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 и загружать патч в ежемесячный филиал.

• В запросе Respin вы должны назначить приоритет (срочность) запросу. Этот приоритет помогает команде 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 -производители всегда могут найти описание и решение проблемы в ChangeLog.