Vendor interface object

This document describes the design of the vendor interface object (VINTF object), which aggregates relevant information about a device and makes that information available through a queryable API.

VINTF object design

A VINTF object gathers some of the information it needs directly from the device. Other aspects, such as the manifests, are described statically in XML.

Figure 1. Manifests, compatibility matrixes, and runtime-collectible information.

VINTF object design provides the following for device and framework components:

For the Device For the Framework
  • Defines a schema for the static component (the device manifest file).
  • Adds build time support for defining the device manifest file for a given device.
  • Defines the queryable API at runtime that retrieves the device manifest file (along with the other runtime-collectible information) and packages them into the query result.
  • Defines a schema for the static component (the framework manifest file).
  • Defines the queryable API at runtime that retrieves the framework manifest file and packages it into the query result.

The VINTF object must be reliable and provide the same complete information regardless of when the object is requested (see Caveats).

Manifests and matrixes

As of Android 8.0, a runtime API queries what is on the device and sends that information to the Over-the-Air (OTA) update server and other interested parties (such as CTS DeviceInfo). Some information is retrieved at runtime and some of it is statically-defined.

  • The device manifest describes the static component of what the device can provide to the framework.
  • The framework compatibility matrix describes what the Android framework expects from a given device. The matrix is a static entity whose composition is determined manually during development of the next release of the Android framework.
  • The framework manifest describes high-level services the framework can provide to the device.
  • The device compatibility matrix describes the services the vendor image requires of the framework. Its composition is determined manually during the development of the device.

These two pairs of manifests and matrixes must be reconciled at OTA time to ensure a device can get framework updates that are compatible with the device's capabilities. In general, a manifest describes what is provided and a compatibility matrix describes what is required.

This section includes the following details on manifests and matrixes:

  • Manifests defines the device manifest, framework manifest, and manifest file schema.
  • Compatibility Matrixes defines the schema for the compatibility matrix.
  • FCM Lifecycle details how HIDL HALs are deprecated and removed and how FCM files are modifed to reflect the status of the HAL Version.
  • DM Development describes how vendors can define and declare the Target FCM Version in the device manifest for new devices or implement new HAL versions and increment the Target FCM Version when upgrading the vendor image for old devices.
  • Matching Rules defines the rules for a successful match between a compatibility matrix and a manifest.