Разработка манифеста устройства

При разработке и выпуске новых устройств поставщики могут определять и указывать целевую версию FCM в манифесте устройства (DM). При обновлении образа поставщика для старых устройств поставщики могут выбрать внедрение новых версий HAL и увеличить целевую версию FCM.

Разрабатывать новые устройства

При определении целевой версии FCM для новых устройств:

  1. Оставьте значения DEVICE_MANIFEST_FILE и PRODUCT_ENFORCE_VINTF_MANIFEST неопределенными.
  2. Реализуйте HAL для целевой версии FCM.
  3. Создайте корректный файл манифеста устройства.
  4. Запишите целевую версию FCM в файл манифеста устройства.
  5. Установите DEVICE_MANIFEST_FILE .
  6. Установите параметр PRODUCT_ENFORCE_VINTF_MANIFEST в true .

Выпуск новых устройств

При выпуске нового устройства необходимо определить и указать его начальную целевую версию FCM в манифесте устройства в качестве атрибута " target-level " в элементе верхнего уровня <manifest> .

Например, устройства, запускаемые с Android 9, должны иметь целевую версию FCM, равную 3 (более высокая доступная на данный момент версия). Чтобы указать это в манифесте устройства:

<manifest version="1.0" type="device" target-level="3">
    <!-- ... -->
</manifest>

Обновить образ поставщика

При обновлении образа системы производителя для старого устройства поставщики могут выбрать внедрение новых версий HAL и увеличить целевую версию FCM.

Обновить HAL

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

  • Устройства Google Pixel 2 и Pixel 2 XL выпущены с целевой версией FCM 2, которая реализовала необходимый HAL audio 2.0 android.hardware.audio@2.0::IDeviceFactory/default .
  • Для аудиоинтерфейса 4.0 HAL, выпущенного вместе с Android 9, устройства Google Pixel 2 и Pixel 2 XL могут использовать полное обновление по воздуху (OTA) до версии 4.0 HAL, которая реализует интерфейс android.hardware.audio@4.0::IDeviceFactory/default .
  • Несмотря на то, что в файле compatibility_matrix.2.xml указан только аудио 2.0, требование к образу поставщика с целевой версией FCM 2 было ослаблено, поскольку фреймворк Android 9 (версия FCM 3) рассматривает аудио 4.0 как замену HAL аудио 2.0 с точки зрения функциональности.

В итоге, учитывая, что compatibility_matrix.2.xml требует аудио 2.0, а compatibility_matrix.3.xml — аудио 4.0, требования следующие:

Версия FCM (системы) Целевая версия FCM (производитель) Требования
2 (8.1) 2 (8.1) Аудио 2.0
3 (9) 2 (8.1) Аудио 2.0 или 4.0
3 (9) 3 (9) Аудио 4.0

Обновить целевую версию FCM

В процессе обновления образа системы поставщика, поставщики также могут увеличить целевую версию FCM, чтобы указать целевую версию FCM, с которой может работать обновленный образ системы поставщика. Для повышения целевой версии FCM устройства поставщикам необходимо:

  1. Внедрить все необходимые новые версии HAL для целевой версии FCM.
  2. Измените версию HAL в файле манифеста устройства.
  3. Измените целевую версию FCM в файле манифеста устройства.
  4. Удалите устаревшие версии HAL.

Например, устройства Google Pixel и Pixel XL были выпущены с Android 7.0, поэтому их целевая версия FCM должна быть как минимум устаревшей. Однако в манифесте устройства указана целевая версия FCM 2, поскольку образ поставщика был обновлен в соответствии с compatibility_matrix.2.xml :

<manifest version="1.0" type="device" target-level="2">

Если поставщики не внедрят все необходимые новые версии HAL или не удалят устаревшие версии HAL, целевую версию FCM обновить будет невозможно.

Например, устройства Google Pixel 2 и Pixel 2 XL имеют целевую версию FCM 2. Хотя они и реализуют некоторые HAL, необходимые согласно compatibility_matrix.3.xml (например, audio 4.0, health 2.0 и т. д.), они не удаляют android.hardware.radio.deprecated@1.0 , который устарел в версии FCM 3 (Android 9). Следовательно, эти устройства не могут обновить целевую версию FCM до 3.

Обязательное требование к ядру во время OTA-обновлений.

Обновление устройств с Android 9 или более ранних версий.

На устройствах с Android 9 или более ранней версией убедитесь, что следующие CL-пакеты выбраны с помощью cherry-pick:

Эти изменения вводят флаг сборки PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS и оставляют этот флаг незаданным для устройств, выпущенных с Android 9 или более ранними версиями.

  • При обновлении до Android 10 клиенты OTA на устройствах под управлением Android 9 или более ранних версий некорректно проверяют требования ядра в пакете OTA. Необходимы следующие изменения, чтобы исключить требования ядра из сгенерированного пакета OTA.
  • При обновлении до Android 11 установка флага сборки PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS для проверки совместимости с VINTF при создании пакета обновления является необязательной.

Для получения дополнительной информации об этом флаге сборки см. раздел «Обновление устройств с Android 10» .

Обновление устройств с Android 10

В Android 10 появился новый флаг сборки PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS . Для устройств, выпущенных с Android 10, этот флаг автоматически устанавливается в true . Когда флаг установлен в true , скрипт извлекает версию ядра и конфигурации ядра из установленного образа ядра.

  • При обновлении до Android 10 пакет OTA-обновления содержит версию ядра и конфигурацию. Клиенты OTA на устройствах под управлением Android 10 считывают эту информацию для проверки совместимости.
  • При обновлении до Android 11 процесс генерации OTA-пакетов считывает версию ядра и конфигурацию для проверки совместимости.

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

  • Отредактируйте скрипт, чтобы он поддерживал ваш формат ядра, и внесите свой вклад в AOSP.
  • Установите BOARD_KERNEL_VERSION в значение версии ядра, а BOARD_KERNEL_CONFIG_FILE — в путь к скомпилированному файлу конфигурации ядра .config . Обе переменные необходимо обновить при обновлении образа ядра.
  • В качестве альтернативы установите PRODUCT_OTA_ENFORCE_VINTF_KERNEL_REQUIREMENTS в значение false , чтобы пропустить проверку требований ядра. Это не рекомендуется, поскольку любая несовместимость скрыта и обнаруживается только при запуске тестов VTS после обновления.

Вы можете просмотреть исходный код скрипта для извлечения информации из ядра extract_kernel.py .