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 matrices, 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 & matrices
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 matrices 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 matrices:
- Manifests defines
the device manifest, framework manifest, and manifest file schema.
- Compatibility
Matrices 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.