Объект VINTF объединяет данные из файлов манифеста устройства и файлов манифеста платформы (XML). Оба манифеста имеют общий формат, хотя не все элементы применимы к обоим (подробные сведения о схеме см. в разделе Схема файла манифеста ).
Манифест устройства
Манифест устройства (предоставляемый устройством) состоит из манифеста поставщика и манифеста ODM.
- В манифесте поставщика указаны HAL, версии политики SELinux и т. д., общие для SoC. Рекомендуется размещать его в дереве исходного кода Android по адресу
device/ VENDOR / DEVICE /manifest.xml, но можно использовать несколько файлов фрагментов. Подробности см. в разделах «Фрагменты манифеста» и «Создание DM из фрагментов» . - В манифесте ODM в разделе ODM перечислены HAL, специфичные для продукта. Объект VINTF загружает манифест ODM в следующем порядке:
- Если
SKUопределен (гдеSKU— это значение свойстваro.boot.product.hardware.sku),/odm/etc/vintf/manifest_ SKU .xml -
/odm/etc/vintf/manifest.xml - Если
SKUопределен,/odm/etc/manifest_ SKU .xml -
/odm/etc/manifest.xml
- Если
- В манифесте поставщика перечислены HAL, специфичные для продукта, в разделе поставщика. Объект VINTF загружает манифест поставщика в следующем порядке:
- Если
SKUопределен (гдеSKU— это значение свойстваro.boot.product.vendor.sku),/vendor/etc/vintf/manifest_ SKU .xml -
/vendor/etc/vintf/manifest.xml
- Если
- Объект VINTF загружает манифест устройства в следующем порядке:
- Если манифест поставщика существует, объедините следующее:
- Манифест поставщика
- Необязательные фрагменты манифеста поставщика
- Дополнительный манифест ODM
- Необязательные фрагменты манифеста ODM
- В противном случае, если манифест ODM существует, объедините манифест ODM с дополнительными фрагментами манифеста ODM.
-
/vendor/manifest.xml(устаревший, без фрагментов) - Наконец, объедините фрагменты манифеста от APEX любого поставщика. Фрагменты манифеста загружаются из каталога
etc/vintfкаждого APEX (например,/apex/<apex name>/etc/vintf).
Обратите внимание, что:
- На устаревших устройствах используются устаревший манифест поставщика и манифест 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 к любому модулю, который явно установлен на устройстве, например cc_binary rust_binary . Например, вы можете изменить модуль, используя свою реализацию 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.
- Для HIDL HAL формат —
-
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. Подробности смотрите в правилах соответствия ядра .