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

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

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

GKI выпускается ежемесячно после KMI Freeze, начиная с 14 июля 2021 г. На следующем рисунке показана периодичность выпуска.

Ежемесячные сертифицированные сборки GKI Дата окончания регистрации Дата готовности предварительной загрузки GKI Этикетка Подтвержденный?
Июль
(заморозка КМИ)
14 июля 2021 г. Конец июля Андроид 12
Сертифицированная сборка AOSP — июль
Да
Август 16 августа 2021 г. Конец августа Андроид 12
Сертифицированная сборка AOSP — август
Да
Сентябрь 17 сентября 2021 г. Конец сентября Андроид 12
Сертифицированная сборка AOSP — сентябрь
Да
Октябрь 15 октября 2021 г. 29 октября 2021 г. Андроид 12
Сертифицированная сборка AOSP — октябрь
Да
ноябрь 12 ноября 2021 г. 30 ноября 2021 г. Андроид 12
Сертифицированная сборка AOSP — ноябрь
Да
Декабрь 10 декабря 2021 г. 22 декабря 2021 г. Андроид 12
Сертифицированная сборка AOSP — декабрь
Да
январь 14 января 2022 г. 31 января 2022 г. Андроид 12
Сертифицированная сборка AOSP — январь
Да
февраль 14 февраля 2022 г. 28 февраля 2022 г. Андроид 12
Сертифицированная сборка AOSP — февраль
Да
Маршировать 16 марта 2022 г. 31 марта 2022 г. Андроид 12
Сертифицированная сборка AOSP — март
Да
апреля 15 апреля 2022 г. 29 апреля 2022 г. Андроид 12
Сертифицированная сборка AOSP — апрель
Да
Май 16 мая 2022 г. 31 мая 2022 г. Андроид 12
Сертифицированная сборка AOSP — май
Да
Июнь 15 июня 2022 г. 30 июня 2022 г. Андроид 12
Сертифицированная сборка AOSP — июнь
Да
Июль 15 июля 2022 г. 29 июля 2022 г. Андроид 12
Сертифицированная сборка AOSP — июль
Да
Август 15 августа 2022 г. 31 августа 2022 г. Андроид 12
Сертифицированная сборка AOSP — август
Да
Сентябрь 16 сентября 2022 г. 30 сентября 2022 г. Андроид 12
Сертифицированная сборка AOSP — сентябрь
Да
Октябрь 14 октября 2022 г. 31 октября 2022 г. Андроид 12
Сертифицированная сборка AOSP — октябрь
Да
ноябрь 14 ноября 2022 г. 30 ноября 2022 г. Андроид 12
Сертифицированная сборка AOSP — ноябрь
Да
Декабрь 9 декабря 2022 г. 21 декабря 2022 г. Андроид 12
Сертифицированная сборка AOSP — декабрь
Да

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

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

Сертифицированная политика повторного запуска сборки

  • Двоичные файлы, сертифицированные GKI, не поддерживаются для респинов после того, как они больше не соответствуют требованиям LTS в ASB. Например, ветка android12-5.10-2021-11 (5.10.66) не поддерживается для респинов после ноября 2022 года, поскольку ветка android12-5.10-2021-11 (5.10.66) не соответствует требованиям LTS АСБ-2022-11.
  • Дополнительную информацию см. в разделе Процесс экстренного респина .

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

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

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

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

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

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

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

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

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

OEM-производителям может потребоваться перезапустить ядро ​​для получения технических разрешений (TA), которые блокируют проблему. Повторные вращения поддерживаются ежемесячными сборками сертифицированных выпусков и имеют ожидаемое стандартное время разрешения (ESRT) в два рабочих дня в часовом поясе США.

ESRT определяется как время, необходимое для доставки сертифицированного бинарного файла GKI, содержащего исправление, при условии, что он одобрен командой GKI и проверен соответствующим OEM-производителем. ESRT является только оценкой и не должна интерпретироваться как гарантия.

OEM-производителям, которым требуется респин для исправления блокировки TA, необходимо сделать следующее:

  1. Сообщите об ошибке в системе отслеживания ошибок и немедленно обратитесь к своему контактному лицу в Google.
    • Если у вас уже есть исправление, ошибка должна указывать на отправку исправления в AOSP, чтобы Google мог его просмотреть. Если отправить исправление невозможно, прикрепите его в виде текстового файла к ошибке в системе отслеживания ошибок .
    • Если у вас еще нет исправления, ошибка должна содержать как можно больше информации, включая номер версии ядра и журналы, чтобы Google мог помочь устранить проблему.
  2. После согласования исправления команда Google GKI проверяет код (CR+2) изменения и тестирует регрессию. Тестирование запускает обратный отсчет ESRT и заканчивается, когда двоичный файл публикуется на ci.android.com .

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

Типы сборок GKI Контроль качества Заметки
Еженедельно Тестирование каракатиц
  • Ботинок
  • Подмножество VTS
  • Подмножество CTS
  • Не сертифицирован. Только для тестирования и
    устройство поднимется.
  • Нельзя использовать для запуска устройств.
Ежемесячно (сертифицировано) Тестирование каракатиц
  • Ботинок
  • СУДС
  • КТС
Эталонное аппаратное тестирование
  • Ботинок
  • СУДС
  • КТС
    Респины (сертифицированы) Тестирование каракатиц
    • Ботинок
    • СУДС
    • Подмножество CTS
    Тестирование эталонного устройства
    • Ботинок
    • СУДС
    • Построен на основе сертифицированной 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/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-производители всегда могут найти описание проблемы и решение в журнале изменений.