Manifests

A VINTF object aggregates data from device manifest and framework manifest files (XML). Both manifests share a format, although not all elements apply to both (for details on the schema, see Manifest file schema).

Device manifest

The device manifest (provided by the device) consists of the vendor manifest and the ODM manifest.

  • The vendor manifest specifies HALs, SELinux policy versions, etc. common to an SoC. It is recommended to be placed in the Android source tree at device/VENDOR/DEVICE/manifest.xml, but multiple fragment files can be used. For details, see Manifest fragments and Generate DM from fragments.
  • The ODM manifest lists HALs specific to the product in the ODM partition. The VINTF object loads the ODM manifest in this order:
    1. If SKU is defined (where SKU is the value of the property ro.boot.product.hardware.sku), /odm/etc/vintf/manifest_SKU.xml
    2. /odm/etc/vintf/manifest.xml
    3. If SKU is defined, /odm/etc/manifest_SKU.xml
    4. /odm/etc/manifest.xml
  • The vendor manifest lists HALs specific to the product in the vendor partition. The VINTF object loads the vendor manifest in this order:
    1. If SKU is defined (where SKU is the value of the property ro.boot.product.vendor.sku), /vendor/etc/vintf/manifest_SKU.xml
    2. /vendor/etc/vintf/manifest.xml
  • The VINTF object loads the device manifest in this order:
    1. If the vendor manifest exists, combine the following:
      1. The vendor manifest
      2. Optional vendor manifest fragments
      3. Optional ODM manifest
      4. Optional ODM manifest fragments
    2. Otherwise, if the ODM manifest exists, combine the ODM manifest with the optional ODM manifest fragments.
    3. /vendor/manifest.xml (legacy, no fragments)
    4. Finally, combine manifest fragments from any vendor APEXes.

    Note that:

    • On legacy devices, the legacy vendor manifest and the ODM manifest are used. The ODM manifest may completely override the legacy vendor manifest.
    • On devices launched with Android 9, the ODM manifest is combined with the vendor manifest.
    • When combining a list of manifests, manifests that appear later in the list may override tags in manifests that appear earlier in the list, provided that the tags in the later manifest have the attribute override="true". For example, the ODM manifest may override some <hal> tags from the vendor manifest. See the documentation for attribute override below.

This setup enables multiple products with the same board to share the same vendor image (which provides common HALs) yet have different ODM images (which specify product-specific HALs).

Here's an example vendor manifest.

<?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>

Here's an example ODM manifest.

<?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>

Here's an example device manifest in an OTA package.

<?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>

For more details, see Device Manifest Development.

Framework manifest

The framework manifest file consists of the system manifest, the product manifest, and the system_ext manifest.

  • The system manifest (provided by Google) is manually generated and lives in the Android source tree at /system/libhidl/manifest.xml.
  • The product manifest (provided by the device) lists HALs serviced by modules installed on the product partition.
  • The system_ext manifest (provided by the device) lists the following:
    • HALs serviced by modules installed on the system_ext partition;
    • VNDK versions;
    • System SDK version.

Similar to the device manifest, multiple fragment files can be used. For details, see Manifest fragments.

Here's an example framework manifest.

<?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>

Manifest fragments

In Android 10 and higher, you can associate a manifest entry with a HAL module in the build system. This makes it easier to conditionally include the HAL module in the build system.

Example

In your Android.bp or Android.mk file, add vintf_fragments to any module. For example, you can modify the module with your implementation of your HAL (my.package.foo@1.0-service-bar). 

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

In a file called manifest_foo.xml, create the manifest for this module. At build time, this manifest is added to the device. Adding an entry here is the same as adding an entry in the device's main manifest. This allows clients to use the interface and allows VTS to identify which HAL implementations are on the device. Anything that a regular manifest does, this manifest also does.

The example below implements android.hardware.foo@1.0::IFoo/default, which is installed to the vendor or odm partition. If it's installed to the system, product, or system_ext partition, use type framework instead of 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>

If a HAL module is packaged in a vendor APEX, package its associated VINTF fragments within the same APEX with prebuilt_etc as explained in VINTF fragments.

Manifest file schema

This section describes the meaning of these XML tags. Some "required" tags can be missing from the source file in Android source tree and written by assemble_vintf at build time. Required tags must be present in the corresponding files on the device.

?xml
Optional. Only provides information to the XML parser.
manifest.version
Required. Meta-version of this manifest. Describes the elements expected in the manifest. Unrelated to XML version.
manifest.type
Required. Type of this manifest. It has the value device for the device manifest file and framework for the framework manifest file.
manifest.target-level
Required for the device manifest. Specifies the framework compatibility matrix (FCM) version that this device manifest is targeted to be compatible with. This is also called the shipping FCM version of the device.
manifest.hal
Optional, can repeat. A single HAL (HIDL or native, such as GL), depending on the format attribute.
manifest.hal.format
Optional. The value can be one of:
  • hidl: HIDL HALs. This is the default.
  • aidl: AIDL HALs. Only valid at manifest meta-version 2.0 and above.
  • native: Native HALs.
manifest.hal.max-level
Optional. Only valid on framework manifests. If set, HALs with a max level lower than the Target FCM Version in the framework manifest are disabled.
manifest.hal.override
Optional. The value can be one of:
  • true: Override other <hal> elements with the same <name> and major version. If no <version> or <fqname> are in this <hal> element, then the <hal> element declares this HAL to be disabled.
  • false: Don't override other <hal> elements with the same <name> and major version.
manifest.hal.name
Required. Fully qualified package name of the HAL. Multiple HAL entries can use the same name. Examples:
  • android.hardware.camera (HIDL or AIDL HAL)
  • GLES (native HAL, requires name only)
manifest.hal.transport
Required when manifest.hal.format == "hidl". Must NOT be present otherwise. States what transport is used when an interface from this package is queried from the service manager. The value can be one of:
  • hwbinder: Binderized mode
  • passthrough: Passthrough mode
Optional when manifest.hal.format == "aidl". Must NOT be present otherwise. States what transport is used when an interface is served remotely. The value must be:
  • inet: Inet socket
The manifest.hal.transport.ip and manifest.hal.transport.port must be used to further specify the Inet connection information.
manifest.hal.transport.arch
Required for passthrough and must not be present for hwbinder. Describes the bitness of the passthrough service being provided. The value can be one of:
  • 32: 32-bit mode
  • 64: 64-bit mode
  • 32+64: Both
manifest.hal.transport.ip
Required for inet and must NOT be present otherwise. Describes the IP address from which the remote interface is being served.
manifest.hal.transport.port
Required for inet and must NOT be present otherwise. Describes the port from which the remote interface is being served.
manifest.hal.version
Optional, can repeat. A version for the hal tags in a manifest.

For HIDL and native HALs, the format is MAJOR.MINOR. For examples, refer to hardware/interfaces, vendor/${VENDOR}/interfaces, frameworks/hardware/interfaces, or system/hardware/interfaces.

HIDL and native HALs may use multiple version fields as long as they represent distinct major versions, with only one minor version per major version provided. For example, 3.1 and 3.2 can't coexist, but 1.0 and 3.4 can. This applies to all hal elements with the same name, unless override="true". The values of <version> are not associated with <fqname> because a <fqname> carries a version.

For AIDL HALs, <version> must not be present on devices running Android 11 and below. <version> must be a single integer on devices running Android 12 and above. There must at most one <version> for each (package, interface, instance) tuple. If not present, default to 1. The value of <version> is associated with all <fqname> in the same <hal> because a <fqname> does not carry a version.
manifest.hal.interface
Required, can repeat without duplicates. State an interface in the package that has an instance name. There can be multiple <interface> elements in a <hal>; names must be distinct.
manifest.hal.interface.name
Required. Name of the interface.
manifest.hal.interface.instance
Required, can repeat. Instance name of the interface. Can have multiple instances for an interface but no duplicated <instance> elements.
manifest.hal.fqname
Optional, can repeat. An alternative way to specify an instance for the HAL with name manifest.hal.name.
  • For HIDL HALs, the format is @MAJOR.MINOR::INTERFACE/INSTANCE.
  • For AIDL HALs, the format is INTERFACE/INSTANCE.
manifest.sepolicy
Required. Contains all sepolicy-related entries.
manifest.sepolicy.version
Required for the device manifest. Declares the SELinux version. It has the format SDK_INT.PLAT_INT.
manifest.vendor-ndk
Required, can repeat; required for the framework manifest. Must not be present in the device manifest. Multiple <vendor-ndk> entries must have different <version>s. Describes a set of VNDK snapshots provided by the framework.
manifest.vendor-ndk.version
Required. This is a positive integer representing the version of the VNDK snapshot.
manifest.vendor-ndk.library
Optional, can repeat, without duplicates. Describes a set of VNDK libraries provided by the framework for this VNDK vendor snapshot. The value is the filename of a library, e.g. libjpeg.so, including the prefix lib and the suffix .so. No path components are allowed.
manifest.system-sdk.version
Optional, can repeat, without duplicates; used only by the framework manifest. Describes a set of system SDK versions provided by the framework to vendor apps.
manifest.kernel
Optional. Describes static information about the kernel.
manifest.kernel.target-level
Optional. Describes the kernel branch. Its value defaults to manifest.target-level if not present. Must be greater than or equal to manifest.target-level. See kernel match rules for details.