Манифесты

Объект VINTF объединяет данные из файлов манифеста устройства и файлов манифеста платформы (XML). Оба манифеста имеют общий формат, хотя не все элементы применимы к обоим (подробные сведения о схеме см. в разделе Схема файла манифеста ).

Манифест устройства

Манифест устройства (предоставляемый устройством) состоит из манифеста поставщика и манифеста ODM.

  • В манифесте поставщика указаны HAL, версии политики SELinux и т. д., общие для SoC. Рекомендуется размещать его в дереве исходного кода Android по адресу device/ VENDOR / DEVICE /manifest.xml , но можно использовать несколько файлов фрагментов. Подробности см. в разделах «Фрагменты манифеста» и «Создание DM из фрагментов» .
  • В манифесте ODM в разделе ODM перечислены HAL, специфичные для продукта. Объект VINTF загружает манифест ODM в следующем порядке:
    1. Если SKU определен (где SKU — это значение свойства ro.boot.product.hardware.sku ), /odm/etc/vintf/manifest_ SKU .xml
    2. /odm/etc/vintf/manifest.xml
    3. Если SKU определен, /odm/etc/manifest_ SKU .xml
    4. /odm/etc/manifest.xml
  • В манифесте поставщика перечислены HAL, специфичные для продукта, в разделе поставщика. Объект VINTF загружает манифест поставщика в следующем порядке:
    1. Если SKU определен (где SKU — это значение свойства ro.boot.product.vendor.sku ), /vendor/etc/vintf/manifest_ SKU .xml
    2. /vendor/etc/vintf/manifest.xml
  • Объект VINTF загружает манифест устройства в следующем порядке:
    1. Если манифест поставщика существует, объедините следующее:
      1. Манифест поставщика
      2. Необязательные фрагменты манифеста поставщика
      3. Дополнительный манифест ODM
      4. Необязательные фрагменты манифеста ODM
    2. В противном случае, если манифест ODM существует, объедините манифест ODM с дополнительными фрагментами манифеста ODM.
    3. /vendor/manifest.xml (устаревший, без фрагментов)
    4. Наконец, объедините фрагменты манифеста от APEX любого поставщика.

    Обратите внимание, что:

    • На устаревших устройствах используются устаревший манифест поставщика и манифест ODM. Манифест ODM может полностью переопределять манифест устаревшего поставщика.
    • На устройствах, запущенных с Android 9, манифест ODM объединяется с манифестом поставщика.
    • При объединении списка манифестов манифесты, которые появляются позже в списке, могут переопределять теги в манифестах, которые появляются раньше в списке, при условии, что теги в более позднем манифесте имеют атрибут override="true" . Например, манифест ODM может переопределять некоторые теги <hal> из манифеста поставщика. См. документацию по override атрибута ниже.

Эта настройка позволяет нескольким продуктам с одной и той же платой использовать один и тот же образ поставщика (который предоставляет общие HAL), но при этом иметь разные образы ODM (которые определяют HAL для конкретного продукта).

Вот пример манифеста поставщика.

<?xml version="1.0" encoding="UTF-8"?>
<!-- Comments, Legal notices, etc. here -->
<manifest version="2.0" type="device" target-level="1">
    <hal>
        <name>android.hardware.camera</name>
        <transport>hwbinder</transport>
        <version>3.4</version>
        <interface>
            <name>ICameraProvider</name>
            <instance>legacy/0</instance>
            <instance>proprietary/0</instance>
        </interface>
    </hal>
    <hal>
        <name>android.hardware.nfc</name>
        <transport>hwbinder</transport>
        <version>1.0</version>
        <version>2.0</version>
        <interface>
            <name>INfc</name>
            <instance>nfc_nci</instance>
        </interface>
    </hal>
    <hal>
        <name>android.hardware.nfc</name>
        <transport>hwbinder</transport>
        <fqname>@2.0::INfc/default</fqname>
    </hal>
    <hal>
        <name>android.hardware.drm</name>
        <transport>hwbinder</transport>
        <version>1.0</version>
        <interface>
            <name>ICryptoFactory</name>
            <instance>default</instance>
        </interface>
        <interface>
            <name>IDrmFactory</name>
            <instance>default</instance>
        </interface>
        <fqname>@1.1::ICryptoFactory/clearkey</fqname>
        <fqname>@1.1::IDrmFactory/clearkey</fqname>
    </hal>
    <hal format="aidl">
        <name>android.hardware.light</name>
        <version>1</version>
        <fqname>ILights/default</fqname>
    </hal>
    <hal format="aidl">
        <name>android.hardware.power</name>
        <version>2</version>
        <interface>
            <name>IPower</name>
            <instance>default</instance>
        </interface>
    </hal>
    <hal format="native">
        <name>EGL</name>
        <version>1.1</version>
    </hal>
    <hal format="native">
        <name>GLES</name>
        <version>1.1</version>
        <version>2.0</version>
        <version>3.0</version>
    </hal>
    <sepolicy>
        <version>25.0</version>
    </sepolicy>
</manifest>

Вот пример манифеста ODM.

<?xml version="1.0" encoding="UTF-8"?>
<!-- Comments, Legal notices, etc. here -->
<manifest version="1.0" type="device">
    <!-- camera 3.4 in vendor manifest is ignored -->
    <hal override="true">
        <name>android.hardware.camera</name>
        <transport>hwbinder</transport>
        <version>3.5</version>
        <interface>
            <name>ICameraProvider</name>
            <instance>legacy/0</instance>
        </interface>
    </hal>
    <!-- NFC is declared to be disabled -->
    <hal override="true">
        <name>android.hardware.nfc</name>
        <transport>hwbinder</transport>
    </hal>
    <hal>
        <name>android.hardware.power</name>
        <transport>hwbinder</transport>
        <version>1.1</version>
        <interface>
            <name>IPower</name>
            <instance>default</instance>
        </interface>
    </hal>
</manifest>

Ниже приведен пример манифеста устройства в пакете OTA.

<?xml version="1.0" encoding="UTF-8"?>
<!-- Comments, Legal notices, etc. here -->
<manifest version="1.0" type="device" target-level="1">
    <!-- hals ommited -->
    <kernel version="4.4.176">
        <config>
            <key>CONFIG_ANDROID</key>
            <value>y</value>
        </config>
        <config>
            <key>CONFIG_ARM64</key>
            <value>y</value>
        </config>
    <!-- other configs ommited -->
    </kernel>
</manifest>

Дополнительные сведения см. в разделе Разработка манифеста устройства .

Манифест платформы

Файл манифеста платформы состоит из манифеста системы, манифеста продукта и манифеста system_ext.

  • Системный манифест (предоставленный Google) генерируется вручную и находится в дереве исходного кода Android по адресу /system/libhidl/manifest.xml .
  • В манифесте продукта (предоставленном устройством) перечислены HAL, обслуживаемые модулями, установленными в разделе продукта.
  • Манифест system_ext (предоставленный устройством) содержит следующее:
    • HAL, обслуживаемые модулями, установленными в разделе system_ext;
    • версии ВНДК;
    • Версия системного SDK.

Подобно манифесту устройства, можно использовать несколько файлов фрагментов. Подробности см. в разделе Фрагменты манифеста .

Вот пример манифеста платформы.

<?xml version="1.0" encoding="UTF-8"?>
<!-- Comments, Legal notices, etc. here -->
<manifest version="1.0" type="framework">
    <hal>
        <name>android.hidl.allocator</name>
        <transport>hwbinder</transport>
        <version>1.0</version>
        <interface>
            <name>IAllocator</name>
            <instance>ashmem</instance>
        </interface>
    </hal>
    <hal>
        <name>android.hidl.memory</name>
        <transport arch="32+64">passthrough</transport>
        <version>1.0</version>
        <interface>
            <name>IMapper</name>
            <instance>ashmem</instance>
        </interface>
    </hal>
    <hal>
        <name>android.hidl.manager</name>
        <transport>hwbinder</transport>
        <version>1.0</version>
        <interface>
            <name>IServiceManager</name>
            <instance>default</instance>
        </interface>
    </hal>
    <hal>
        <name>android.frameworks.sensorservice</name>
        <transport>hwbinder</transport>
        <version>1.0</version>
        <interface>
            <name>ISensorManager</name>
            <instance>default</instance>
        </interface>
    </hal>
    <hal max-level="5">
        <name>android.frameworks.schedulerservice</name>
        <transport>hwbinder</transport>
        <version>1.0</version>
        <interface>
            <name>ISchedulingPolicyService</name>
            <instance>default</instance>
        </interface>
    </hal>
    <vendor-ndk>
        <version>27</version>
    </vendor-ndk>
    <system-sdk>
        <version>27</version>
    </system-sdk>
</manifest>

Фрагменты манифеста

В Android 10 и более поздних версиях вы можете связать запись манифеста с модулем HAL в системе сборки. Это упрощает условное включение модуля HAL в систему сборки.

Пример

В файле Android.bp или Android.mk добавьте vintf_fragments в любой модуль. Например, вы можете изменить модуль, используя свою реализацию HAL ( my.package.foo@1.0-service-bar ).

... {
    ...
    vintf_fragments: ["manifest_foo.xml"],
    ...
}
LOCAL_MODULE := ...
LOCAL_VINTF_FRAGMENTS := manifest_foo.xml

В файле с именем manifest_foo.xml создайте манифест для этого модуля. Во время сборки этот манифест добавляется на устройство. Добавление записи здесь аналогично добавлению записи в основной манифест устройства. Это позволяет клиентам использовать интерфейс и позволяет VTS определять, какие реализации HAL установлены на устройстве. Все, что делает обычный манифест, делает и этот манифест.

В приведенном ниже примере реализуется android.hardware.foo@1.0::IFoo/default , который устанавливается в раздел vendor или odm . Если он установлен в раздел system , product или system_ext , используйте type framework вместо type device .

<manifest version="1.0" type="device">
    <hal format="hidl">
        <name>android.hardware.foo</name>
        <transport>hwbinder</transport>
        <fqname>@1.0::IFoo/default</fqname>
    </hal>
</manifest>

Если модуль HAL упакован в APEX поставщика , упакуйте связанные с ним фрагменты VINTF в тот же APEX с помощью prebuilt_etc , как описано в разделе «Фрагменты VINTF» .

Схема файла манифеста

В этом разделе описывается значение этих тегов XML. Некоторые «обязательные» теги могут отсутствовать в исходном файле в дереве исходного кода Android и записываться с помощью assemble_vintf во время сборки. Обязательные теги должны присутствовать в соответствующих файлах на устройстве.

?xml
Необязательный. Предоставляет информацию только анализатору XML.
manifest.version
Необходимый. Мета-версия этого манифеста. Описывает элементы, ожидаемые в манифесте. Не связано с версией XML.
manifest.type
Необходимый. Тип этого манифеста. Он имеет значение device для файла манифеста устройства и framework для файла манифеста платформы.
manifest.target-level
Требуется для манифеста устройства. Указывает версию матрицы совместимости платформы (FCM), с которой этот манифест устройства должен быть совместим. Это также называется транспортной версией устройства FCM.
manifest.hal
По желанию, могу повторить. Один HAL (HIDL или собственный, например GL), в зависимости от атрибута format .
manifest.hal.format
Необязательный. Значение может быть одним из:
  • hidl : HIDL HAL. Это значение по умолчанию.
  • aidl : AIDL HAL . Действительно только для мета-версии манифеста 2.0 и выше.
  • native : собственные HAL.
manifest.hal.max-level
Необязательный. Действует только в манифестах платформы. Если этот параметр установлен, HAL с максимальным уровнем ниже целевой версии FCM в манифесте платформы отключаются.
manifest.hal.override
Необязательный. Значение может быть одним из:
  • true : переопределить другие элементы <hal> с тем же <name> и основной версией. Если в этом элементе <hal> нет <version> или <fqname> , то элемент <hal> объявляет этот HAL отключенным.
  • false : не переопределять другие элементы <hal> с тем же <name> и основной версией.
manifest.hal.name
Необходимый. Полное имя пакета HAL. Несколько записей HAL могут использовать одно и то же имя. Примеры:
  • android.hardware.camera (HIDL или AIDL HAL)
  • GLES (собственный HAL, требуется только имя)
manifest.hal.transport
Требуется, когда manifest.hal.format == "hidl" . В противном случае НЕ ДОЛЖНО присутствовать. Указывает, какой транспорт используется, когда интерфейс из этого пакета запрашивается у диспетчера служб. Значение может быть одним из:
  • hwbinder : режим связывания
  • passthrough : сквозной режим
Необязательно, если manifest.hal.format == "aidl" . В противном случае НЕ ДОЛЖНО присутствовать. Указывает, какой транспорт используется при удаленном обслуживании интерфейса. Значение должно быть:
  • inet : Интернет-разъем
manifest.hal.transport.ip и manifest.hal.transport.port необходимо использовать для дальнейшего указания информации о подключении к Интернету.
manifest.hal.transport.arch
Требуется для passthrough и не должен присутствовать для hwbinder . Описывает разрядность предоставляемой транзитной услуги. Значение может быть одним из:
  • 32 : 32-битный режим
  • 64 : 64-битный режим
  • 32+64 : Оба
manifest.hal.transport.ip
Требуется для inet и НЕ должен присутствовать в противном случае. Описывает IP-адрес, с которого обслуживается удаленный интерфейс.
manifest.hal.transport.port
Требуется для inet и НЕ должен присутствовать в противном случае. Описывает порт, с которого обслуживается удаленный интерфейс.
manifest.hal.version
По желанию, могу повторить. Версия для тегов hal в манифесте.

Для HIDL и собственных HAL используется формат MAJOR . MINOR . Примеры см. в разделах hardware/interfaces , vendor/${VENDOR}/interfaces , frameworks/hardware/interfaces или system/hardware/interfaces .

HIDL и собственные HAL могут использовать несколько полей версии, если они представляют отдельные основные версии , при этом для каждой основной версии предоставляется только одна дополнительная версия. Например, 3.1 и 3.2 не могут сосуществовать, а 1.0 и 3.4 — могут. Это относится ко всем элементам hal с тем же именем, за исключением override="true" . Значения <version> не связаны с <fqname> поскольку <fqname> содержит версию.

Для AIDL HAL <version> не должна присутствовать на устройствах под управлением Android 11 и более ранних версий. <version> должна быть одним целым числом на устройствах под управлением Android 12 и более поздних версий. Для каждого кортежа (package, interface, instance) должна быть не более одной <version> . Если отсутствует, по умолчанию — 1 . Значение <version> связано со всеми <fqname> в одном и том же <hal> поскольку <fqname> не содержит версии.
manifest.hal.interface
Обязательно, можно повторять без дублей. Укажите интерфейс в пакете, имеющий имя экземпляра. В <hal> может быть несколько элементов <interface> ; имена должны быть разными.
manifest.hal.interface.name
Необходимый. Имя интерфейса.
manifest.hal.interface.instance
Обязательно, могу повторить. Имя экземпляра интерфейса. Может иметь несколько экземпляров интерфейса, но не дублировать элементы <instance> .
manifest.hal.fqname
По желанию, могу повторить. Альтернативный способ указать экземпляр HAL с именем manifest.hal.name .
  • Для HIDL HAL формат — @ MAJOR . MINOR :: INTERFACE / INSTANCE .
  • Для AIDL HAL используется формат INTERFACE / INSTANCE .
manifest.sepolicy
Необходимый. Содержит все записи, связанные с sepolicy.
manifest.sepolicy.version
Требуется для манифеста устройства. Объявляет версию SELinux. Он имеет формат SDK_INT . PLAT_INT .
manifest.vendor-ndk
Обязательно, могу повторить; требуется для манифеста платформы. Не должно присутствовать в манифесте устройства. Несколько записей <vendor-ndk> должны иметь разные <version> . Описывает набор снимков VNDK, предоставляемых платформой.
manifest.vendor-ndk.version
Необходимый. Это положительное целое число, представляющее версию снимка VNDK.
manifest.vendor-ndk.library
Необязательно, можно повторять, без дублей. Описывает набор библиотек VNDK, предоставляемых платформой для этого снимка поставщика VNDK. Значением является имя файла библиотеки, например libjpeg.so , включая префикс lib и суффикс .so . Никакие компоненты пути не допускаются.
manifest.system-sdk.version
Необязательно, может повторяться, без дубликатов; используется только манифестом платформы. Описывает набор версий системного SDK, предоставляемых платформой приложениям поставщиков.
manifest.kernel
Необязательный. Описывает статическую информацию о ядре.
manifest.kernel.target-level
Необязательный. Описывает ветку ядра. Его значение по умолчанию равно manifest.target-level если оно отсутствует. Должно быть больше или равно manifest.target-level . Подробности смотрите в правилах соответствия ядра .