A partir del 27 de marzo de 2025, te recomendamos que uses android-latest-release
en lugar de aosp-main
para compilar y contribuir a AOSP. Para obtener más información, consulta Cambios en AOSP.
Objeto de interfaz de proveedor
Organiza tus páginas con colecciones
Guarda y categoriza el contenido según tus preferencias.
En este documento, se describe el diseño del objeto de interfaz de proveedor (objeto VINTF), que agrega información relevante sobre un dispositivo y la pone a disposición a través de una API consultable.
Diseño del objeto VINTF
Un objeto VINTF recopila parte de la información que necesita directamente del dispositivo. Otros aspectos, como los manifiestos, se describen de forma estática en XML.
Figura 1: Manifiestos, matrices de compatibilidad y la información que se puede recopilar en el entorno de ejecución
El diseño de objetos VINTF proporciona lo siguiente para los componentes del dispositivo y del framework:
Para el dispositivo |
Para el framework |
- Define un esquema para el componente estático (el archivo de manifiesto del dispositivo).
- Se agregó compatibilidad con el tiempo de compilación para definir el archivo de manifiesto del dispositivo para un dispositivo determinado.
- Define la API consultable en el tiempo de ejecución que recupera el archivo de manifiesto del dispositivo (junto con la otra información que se puede recopilar en el tiempo de ejecución) y los empaqueta en el resultado de la consulta.
|
|
El objeto VINTF debe ser confiable y proporcionar la misma información completa sin importar cuándo se solicite (consulta las Advertencias).
Manifiestos y matrices
A partir de Android 8.0, una API de entorno de ejecución consulta lo que hay en el dispositivo y envía esa información al servidor de actualizaciones inalámbricas (OTA) y a otras partes interesadas (como CTS DeviceInfo
). Parte de la información se recupera durante el tiempo de ejecución y parte se define de forma estática.
- El manifiesto del dispositivo describe el componente estático de lo que el dispositivo puede proporcionar al framework.
- La matriz de compatibilidad del framework describe lo que el framework de Android espera de un dispositivo determinado. La matriz es una entidad estática cuya composición se determina de forma manual durante el desarrollo de la próxima versión del framework de Android.
- En el manifiesto del framework, se describen los servicios de alto nivel que el framework puede proporcionar al dispositivo.
- La matriz de compatibilidad de dispositivos describe los servicios que la imagen del proveedor requiere del framework. Su composición se determina de forma manual durante el desarrollo del dispositivo.
Estos dos pares de manifiestos y matrices deben reconciliarse en el momento de la actualización inalámbrica para garantizar que un dispositivo pueda obtener actualizaciones de framework que sean compatibles con sus capacidades. En general, un manifiesto describe lo que se proporciona y una matriz de compatibilidad describe lo que se requiere.
En esta sección, se incluyen los siguientes detalles sobre los manifiestos y las matrices:
- Manifiestos define el manifiesto del dispositivo, el manifiesto del framework y el esquema del archivo de manifiesto.
- Matrices de compatibilidad define el esquema de la matriz de compatibilidad.
- En el Ciclo de vida de FCM, se detalla cómo se dan de baja y se quitan los HAL de HIDL, y cómo se modifican los archivos de FCM para reflejar el estado de la versión de HAL.
- En Desarrollo de DM, se describe cómo los proveedores pueden definir y declarar la versión objetivo de FCM en el manifiesto del dispositivo para dispositivos nuevos, o bien implementar nuevas versiones de HAL y aumentar la versión objetivo de FCM cuando se actualiza la imagen del proveedor para dispositivos antiguos.
- Matching Rules define las reglas para que se establezca una coincidencia correcta entre una matriz de compatibilidad y un manifiesto.
El contenido y las muestras de código que aparecen en esta página están sujetas a las licencias que se describen en la Licencia de Contenido. Java y OpenJDK son marcas registradas de Oracle o sus afiliados.
Última actualización: 2025-07-27 (UTC)
[[["Fácil de comprender","easyToUnderstand","thumb-up"],["Resolvió mi problema","solvedMyProblem","thumb-up"],["Otro","otherUp","thumb-up"]],[["Falta la información que necesito","missingTheInformationINeed","thumb-down"],["Muy complicado o demasiados pasos","tooComplicatedTooManySteps","thumb-down"],["Desactualizado","outOfDate","thumb-down"],["Problema de traducción","translationIssue","thumb-down"],["Problema con las muestras o los códigos","samplesCodeIssue","thumb-down"],["Otro","otherDown","thumb-down"]],["Última actualización: 2025-07-27 (UTC)"],[],[],null,["# Vendor interface object\n\nThis document describes the design of the *vendor interface object*\n(VINTF object), which aggregates relevant information about a device and makes\nthat information available through a *queryable API*.\n\nVINTF object design\n-------------------\n\nA VINTF object gathers some of the information it needs directly from the\ndevice. Other aspects, such as the manifests, are described statically in\nXML.\n\n**Figure 1.** Manifests, compatibility matrixes, and runtime-collectible information.\n\nVINTF object design provides the following for device and framework\ncomponents:\n\n| For the Device | For the Framework |\n|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|\n| - Defines a schema for the static component (the [device manifest file](/docs/core/architecture/vintf/objects#device-manifest-file)). - Adds build time support for defining the device manifest file for a given device. - Defines the [queryable API](/docs/core/architecture/vintf/objects#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](/docs/core/architecture/vintf/objects#framework-manifest-file)). - Defines the [queryable API](/docs/core/architecture/vintf/objects#queryable-api) at runtime that retrieves the framework manifest file and packages it into the query result. |\n\nThe VINTF object must be reliable and provide the same complete information\nregardless of when the object is requested (see\n[Caveats](/docs/core/architecture/vintf/resources#caveats)).\n\nManifests and matrixes\n----------------------\n\nAs of Android 8.0, a runtime API queries what is on the device and sends that\ninformation to the [Over-the-Air (OTA)](/docs/core/ota)\nupdate server and other interested parties (such as CTS\n`DeviceInfo`). Some information is retrieved at runtime and some of\nit is statically-defined.\n\n- The **device manifest** describes the static component of what the device can provide to the framework.\n- 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.\n- The **framework manifest** describes high-level services the framework can provide to the device.\n- 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.\n\nThese two pairs of manifests and matrixes must be reconciled at OTA time to\nensure a device can get framework updates that are compatible with the device's\ncapabilities. In general, a *manifest* describes what is provided and a\n*compatibility matrix* describes what is required.\n\nThis section includes the following details on manifests and matrixes:\n\n- [Manifests](/docs/core/architecture/vintf/objects) defines the device manifest, framework manifest, and manifest file schema.\n- [Compatibility\n Matrixes](/docs/core/architecture/vintf/comp-matrices) defines the schema for the compatibility matrix.\n- [FCM Lifecycle](/docs/core/architecture/vintf/fcm) details how HIDL HALs are deprecated and removed and how FCM files are modifed to reflect the status of the HAL Version.\n- [DM Development](/docs/core/architecture/vintf/dm) 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.\n- [Matching Rules](/docs/core/architecture/vintf/match-rules) defines the rules for a successful match between a compatibility matrix and a manifest."]]