Vendor Interface (VINTF)

The Vendor Interface Object (VINTF object) is a foundational component of Project Treble in the Android Open Source Project (AOSP). It serves the critical purpose of formally declaring and verifying the vendor interface, ensuring compatibility between the Android framework and the vendor implementation. The VINTF object aggregates data from the device and the framework, enabling the system to mathematically prove that the provided HALs match the framework's requirements before allowing an OTA update or system boot.

Purpose of VINTF: Declaring and Verifying Vendor Interfaces

Prior to Project Treble, updating the Android OS often resulted in breakages because the vendor implementation (HALs, kernel drivers) was tightly coupled with the Android framework. VINTF introduces a rigid contract system.

The fundamental goals of VINTF are:

• Verification: Ensure that an updated framework image (system.img) can boot safely with an older vendor image (vendor.img), or vice versa.
• Discovery: Provide a standardized way for system components to query which HALs and versions are available on the device at runtime.
• OTA Safety: Prevent Over-The-Air (OTA) updates that would brick the device due to mismatched dependencies.

The Device Manifest (manifest.xml)

The device manifest is essentially the vendor's promise to the framework. It defines precisely what the vendor implementation provides.

This XML file (typically located at /vendor/etc/vintf/manifest.xml) explicitly lists:

1. HALs: The Hardware Abstraction Layers supported by the device, including their format (HIDL or AIDL), versions, and transport mechanisms (binder, passthrough).
2. Kernel Details: The kernel version and specific kernel configurations that the vendor image was built against and supports.
3. SEPolicy: The version of the SELinux policy supported by the vendor.

Example Device Manifest Snippet

<manifest version="5.0" type="device" target-level="7">
    <hal format="aidl">
        <name>android.hardware.light</name>
        <version>2</version>
        <interface>
            <name>ILights</name>
            <instance>default</instance>
        </interface>
    </hal>
    <hal format="hidl">
        <name>android.hardware.camera.provider</name>
        <transport>hwbinder</transport>
        <version>2.4</version>
        <interface>
            <name>ICameraProvider</name>
            <instance>legacy/0</instance>
        </interface>
    </hal>
    <sepolicy>
        <version>33.0</version>
    </sepolicy>
</manifest>

In this snippet, the device explicitly declares it provides version 2 of the AIDL ILights HAL and version 2.4 of the HIDL ICameraProvider HAL.

The Framework Compatibility Matrix (compatibility_matrix.xml)

If the device manifest is the vendor's promise, the framework compatibility matrix is the framework's requirement.

Located typically at /system/etc/vintf/compatibility_matrix.device.xml, this file details what the system.img needs from the vendor.img to function correctly.

It dictates:

• Required HALs: Which HALs are mandatory and what version ranges are acceptable.
• Optional HALs: HALs that the framework can use if provided, but aren't strictly required for boot.
• Kernel Requirements: The minimum kernel version and required kernel configs (e.g., specific CONFIG_* flags) needed by the framework.

Verification Process

During build time and OTA updates, libvintf compares the Device Manifest against the Framework Compatibility Matrix. If the vendor image does not satisfy all the "required" elements of the framework's matrix, the build fails or the OTA is rejected.

You can manually trigger VINTF checks on a device using the vintf command line tool:

adb shell vintf

This dumps the merged VINTF object state, showing both the matrices and the manifests.

VINTF Versioning (Target FCM Level)

To maintain backwards compatibility, VINTF uses the concept of a Target Framework Compatibility Matrix (Target FCM) Version, also known as the Target Level.

When a device launches, it is frozen to a specific Target FCM Level (e.g., Level 7 for Android 13). This level defines the baseline requirements. Even if the device receives a framework update to Android 14 (which might have a base FCM level of 8), the new framework must still remain compatible with the device's original Target FCM Level 7 vendor image.

This matrix versioning ensures that silicon vendors do not need to rewrite their HALs for every single Android release, significantly reducing the cost and effort of providing OS updates.