В этом документе описывается порядок выпуска GKI, включая еженедельные, ежемесячные и внеплановые экстренные выпуски. Цель этого документа — дать OEM-производителям рекомендации о том, где получить GKI, а также о процессе внеплановых аварийных исправлений. OEM-производители также могут использовать руководство по разработке GKI , чтобы узнать больше о том, как они могут работать с командой Android Kernel над оптимизацией ядра GKI для своих продуктов.
Частота выпуска GKI
GKI выпускается ежемесячно после заморозки KMI.
Выпуск Android 13 и 14 GKI
Следующая таблица применима только к android13-5.10 , android13-5.15 и android14-6.1 .
| Ежемесячные сертифицированные сборки GKI | Дата окончания заезда | Дата готовности предварительной загрузки GKI | Подтвержденный? |
|---|---|---|---|
| Октябрь | 14 октября 2022 г. | 31 октября 2022 г. | Да |
| ноябрь | 14 ноября 2022 г. | 30 ноября 2022 г. | Да |
| Декабрь | 9 декабря 2022 г. | 21 декабря 2022 г. | Да |
| январь | 17 января 2023 г. | 31 января 2023 г. | Да |
| февраль | 15 февраля 2023 г. | 28 февраля 2023 г. | Да |
| Маршировать | 15 марта 2023 г. | 31 марта 2023 г. | Да |
| апрель | 13 апреля 2023 г. | 28 апреля 2023 г. | Да |
| Может | 17 мая 2023 г. | 31 мая 2023 г. | Да |
| Июнь | 15 июня 2023 г. | 30 июня 2023 г. | Да |
| Июль | 18 июля 2023 г. | 31 июля 2023 г. | Да |
| Август | 16 августа 2023 г. | 31 августа 2023 г. | Да |
| Сентябрь | 14 сентября 2023 г. | 29 сентября 2023 г. | Да |
| Октябрь | 18 октября 2023 г. | 31 октября 2023 г. | Да |
| ноябрь | 10 ноября 2023 г. | 30 ноября 2023 г. | Да |
| Декабрь | 7 декабря 2023 г. | 22 декабря 2023 г. | Да |
| январь | 16 января 2024 г. | 31 января 2024 г. | Да |
| февраль | 13 февраля 2024 г. | 29 февраля 2024 г. | Да |
| Маршировать | 13 марта 2024 г. | 29 марта 2024 г. | Да |
| апрель | 16 апреля 2024 г. | 30 апреля 2024 г. | Да |
| Может | 14 мая 2024 г. | 31 мая 2024 г. | Да |
| Июнь | 12 июня 2024 г. | 28 июня 2024 г. | Да |
| Июль | 16 июля 2024 г. | 31 июля 2024 г. | Да |
| Август | 15 августа 2024 г. | 30 августа 2024 г. | Да |
| Сентябрь | 17 сентября 2024 г. | 30 сентября 2024 г. | Да |
| Октябрь | 15 октября 2024 г. | 31 октября 2024 г. | Да |
| ноябрь | 11 ноября 2024 г. | 27 ноября 2024 г. | Да |
| Декабрь | 6 декабря 2024 г. | 23 декабря 2024 г. | Да |
Начиная с января 2024 года мы возобновим ежемесячные выпуски android14-5.15 в соответствии с ежемесячной периодичностью, указанной в таблице ниже.
| Ежемесячные сертифицированные сборки GKI | Дата окончания заезда | Дата готовности предварительной загрузки GKI | Подтвержденный? |
|---|---|---|---|
| январь | 16 января 2024 г. | 31 января 2024 г. | Да |
| февраль | 13 февраля 2024 г. | 29 февраля 2024 г. | Да |
| Маршировать | 4 марта 2024 г. | 15 марта 2024 г. | Да |
| апрель | 1 апреля 2024 г. | 17 апреля 2024 г. | Да |
| Может | 1 мая 2024 г. | 17 мая 2024 г. | Да |
| Июнь | 3 июня 2024 г. | 17 июня 2024 г. | Да |
| Июль | 1 июля 2024 г. | 15 июля 2024 г. | Да |
| Август | 1 августа 2024 г. | 16 августа 2024 г. | Да |
| Сентябрь | 2 сентября 2024 г. | 16 сентября 2024 г. | Да |
| Октябрь | 1 октября 2024 г. | 14 октября 2024 г. | Да |
| ноябрь | 1 ноября 2024 г. | 15 ноября 2024 г. | Да |
| Декабрь | 2 декабря 2024 г. | 16 декабря 2024 г. | Да |
Выпуск Android 12 GKI
После мая 2023 года выпуски android12-5.10 GKI будут выпускаться каждые два месяца и публиковаться в середине месяца. Следующая таблица применима только к android12-5.10 .
| Ежемесячные сертифицированные сборки GKI | Дата окончания заезда | Дата готовности предварительной загрузки GKI | Подтвержденный? |
|---|---|---|---|
| Июль | 3 июля 2023 г. | 14 июля 2023 г. | Да |
| Сентябрь | 1 сентября 2023 г. | 15 сентября 2023 г. | Да |
| ноябрь | 3 ноября 2023 г. | 17 ноября 2023 г. | Да |
| январь | 5 января 2024 г. | 19 января 2024 г. | Да |
| Маршировать | 4 марта 2024 г. | 15 марта 2024 г. | Да |
| Может | 1 мая 2024 г. | 17 мая 2024 г. | Да |
Срок действия сборки GKI для OEM-производителей
OEM-производители могут использовать недавно выпущенный Android GKI. OEM-производители могут запускать сборки, сертифицированные GKI, при условии, что они соответствуют требованиям LTS в Бюллетене безопасности Android (ASB).
Еженедельные выпуски разработки
Релизы тестируются на каракатицах , чтобы гарантировать, что они соответствуют минимальному стандарту качества .Двоичные файлы GKI доступны для самообслуживания на сайте ci.android.com по мере объединения изменений. Еженедельные сборки не будут сертифицированы, но могут использоваться в качестве основы для разработки и тестирования. Еженедельные сборки нельзя использовать для сборок рабочих устройств для конечных пользователей.
Ежемесячные сертифицированные выпуски
Ежемесячные выпуски GKI содержат протестированный файл boot.img , который включает вставленный сертификат Google, подтверждающий, что двоичные файлы были созданы на основе известного базового исходного кода.
Каждый месяц кандидат на ежемесячный выпуск GKI (не сертифицированный) выбирается после конечной даты регистрации, которая обычно является второй еженедельной сборкой этого месяца. После выбора кандидата на ежемесячный выпуск новые изменения не будут приняты в выпуск этого месяца. В период закрытого окна можно устранять только исправления ошибок, которые приводят к сбою теста. Кандидат на выпуск проходит проверку качества, как описано в разделе квалификации GKI , чтобы гарантировать прохождение тестов на соответствие сборке GSI+GKI с эталонным устройством, а также с каракатицей.
Рисунок 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 АСБ-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. Вы должны отправить новый запрос на повторную отправку, если есть дополнительные исправления, которые необходимо объединить.
Для каждого рассматриваемого CL добавьте следующие теги. Без этой информации прогресс выполнения запроса на повторный запуск блокируется.
-
Bug: идентификатор ошибки должен быть добавлен в сообщение о фиксации для каждого CL. -
Change-Id: должен быть идентичен Change-Id изменения базовой ветки.
-
Если запрос на повторную отправку требует вашего ответа, а вы не отвечаете в течение трех рабочих дней, приоритет понижается на один уровень (например, P0 понижается до P1 ). Если вы не ответите в течение двух недель, ошибка будет помечена как «Не будет исправлена (устарела)» .
Отправить запрос на повторную отправку
На следующей диаграмме показан процесс респина. Процесс начинается, когда 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 | Обеспечение качества | Примечания |
|---|---|---|
| Еженедельно | Тестирование каракатиц
|
|
| Ежемесячно (сертифицировано) | Тестирование каракатиц
| |
| Респины (сертифицированные) | Тестирование каракатиц
|
|
Где взять артефакты сборки
Артефакты для всех выпусков можно получить на сайте ci.android.com .
Дополнительную информацию о CI, включая результаты тестирования, можно найти на панели мониторинга непрерывной интеграции Android .
Часто задаваемые вопросы
Можно ли создать новый двоичный файл 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/manifestmv manifest_7364300.xml .repo/manifestsrepo init -m manifest_7364300.xml --depth=1repo sync # build the GKI images # You may want to use LTO=thin to build faster for developmentBUILD_CONFIG=common/build.config.gki.aarch64 build/build.sh # (optional) build virtual platform modulesBUILD_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-производители всегда могут найти описание проблемы и решение в журнале изменений.