Эта страница переведена с помощью Cloud Translation API.

Манифесты

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

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

В этом разделе описывается значение этих тегов 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 . Подробности смотрите в правилах соответствия ядра .