Эта страница переведена с помощью Cloud Translation API.

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

Ежемесячные сертифицированные сборки GKI	Дата окончания заезда	Дата готовности предварительной загрузки GKI	Подтвержденный?
ноябрь	11 ноября 2024 г.	27 ноября 2024 г.	Да
январь	17 января 2025 г.	31 января 2025 г.	Да
Маршировать	14 марта 2025 г.	31 марта 2025 г.	Да

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

Ежемесячные сертифицированные сборки GKI	Дата окончания заезда	Дата готового нагрузки GKI	Подтвержденный?
Октябрь	1 октября 2024 г.	14 октября 2024 г.	Да
ноябрь	1 ноября 2024 г.	15 ноября 2024 г.	Да
декабрь	2 декабря 2024 г.	16 декабря 2024 г.	Да
январь	6 января 2025 г.	22 января 2025 г.	Да

Android 12 GKI релиз

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

Ежемесячные сертифицированные сборки GKI	Дата вырезания регистрации	Дата готового нагрузки GKI	Подтвержденный?
ноябрь	1 ноября 2024 г.	15 ноября 2024 г.	Да
февраль	3 февраля 2025 г.	17 февраля 2025 г.	Да

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

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

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

Релизы тестируются с помощью Cuttlefish , чтобы гарантировать, что они соответствуют минимальному стандарту качества .

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

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

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

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

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

Аварийный процесс

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

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

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

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

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

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

Экстренный процесс респина Рисунок 2. Процесс респина

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

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

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

Типы сборок GKI	Обеспечение качества	Примечания
Еженедельно	Тестирование каракатиц Ботинок Подмножество VTS Подмножество CTS	Не сертифицирован. Только для тестирования и Устройство поднимает. Невозможно использовать для запуска устройств.
Ежемесячно (сертифицировано)	Тестирование каракатицы Ботинок СУДС КТС Эталонное тестирование оборудования Ботинок СУДС КТС
Респин (сертифицировано)	Тестирование каракатицы Ботинок СУДС Подмножество CTS Тестирование на справочном устройстве Ботинок СУДС	Построен на вершине сертифицированной сборки GKI. Сборка сертифицирована после квалификации.

Типы сборок GKI

Обеспечение качества

Примечания

Еженедельно

Тестирование каракатиц

Ботинок
Подмножество VTS
Подмножество CTS

Не сертифицирован. Только для тестирования и
Устройство поднимает.
Невозможно использовать для запуска устройств.

Ежемесячно (сертифицировано)

Тестирование каракатицы

Ботинок
СУДС
КТС

Эталонное тестирование оборудования

Ботинок
СУДС
КТС

Респин (сертифицировано)

Тестирование каракатицы

Ботинок
СУДС
Подмножество CTS

Тестирование на справочном устройстве

Ботинок
СУДС

Построен на вершине сертифицированной сборки 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.