Объект 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 любого поставщика.
Обратите внимание, что:
- На устаревших устройствах используются устаревший манифест поставщика и манифест 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
.
- Для 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
. Подробности смотрите в правилах соответствия ядра .