2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
ベンダー インターフェース オブジェクト
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
このドキュメントでは、ベンダー インターフェース オブジェクト(VINTF オブジェクト)の設計について説明します。このオブジェクトは、デバイスに関連する情報を集約し、クエリ可能な API でその情報を利用できるようにします。
VINTF オブジェクトの設計
VINTF オブジェクトは、必要とする情報の一部をデバイスから直接収集します。一方、マニフェストなどの他の要素は XML で静的に記述されます。
図 1. マニフェスト、互換性マトリックス、実行時に収集可能な情報
VINTF オブジェクトの設計では、デバイスとフレームワークのコンポーネントについて以下を行います。
デバイス |
フレームワーク |
- 静的コンポーネント(デバイス マニフェスト ファイル)のスキーマを定義します。
- 特定のデバイスのデバイス マニフェスト ファイルを定義するためのビルド時サポートを追加します。
- デバイス マニフェスト ファイル(およびその他の実行時に収集可能な情報)を取得してクエリ結果にパッケージングする、クエリ可能な API を実行時に定義します。
|
|
VINTF オブジェクトは信頼できるものでなければならず、いつオブジェクトがリクエストされても同一の完全な情報を提供する必要があります(注意事項を参照)。
マニフェストとマトリックス
Android 8.0 以降、ランタイム API はデバイス上の情報をクエリし、その情報を無線(OTA)アップデート サーバーや CTS DeviceInfo
などに送信するようになりました。一部の情報は実行時に取得され、一部の情報は静的に定義されます。
- デバイス マニフェストには、静的コンポーネント(デバイスがフレームワークに提供できるもの)が記述されます。
- フレームワーク互換性マトリックスには、Android フレームワークが特定のデバイスに期待する情報が記述されます。マトリックスは静的エンティティです。その構成は、Android フレームワークの次回リリースの開発中に手動で決定されます。
- フレームワーク マニフェストには、フレームワークがデバイスに提供できるハイレベルのサービスが記述されます。
- デバイス互換性マトリックスには、ベンダー イメージがフレームワークについて必要とするサービスが記述されています。その構成は、デバイスの開発中に手動で決定されます。
OTA 時には、この 2 つのマニフェストとマトリックスのペアが整合性を持ち、デバイスの機能と互換性があるフレームワーク アップデートをデバイスが取得できるようにする必要があります。一般的に、マニフェストには何が提供されるかが記述され、互換性マトリックスには何が必要かが記述されます。
マニフェストとマトリックスの詳細については、以下のページで説明しています。
- マニフェストでは、デバイス マニフェスト、フレームワーク マニフェスト、マニフェスト ファイルのスキーマを定義しています。
- 互換性マトリックスでは、互換性マトリックスのスキーマを定義しています。
- FCM ライフサイクルでは、HIDL HAL のサポート終了および削除の仕組みと、HAL バージョンのステータスを反映するために FCM ファイルを変更する方法について説明しています。
- デバイス マニフェストの開発では、ベンダーが新しいデバイスのデバイス マニフェストでターゲット FCM バージョンを定義および宣言する方法を説明しています。また、古いデバイスのベンダー イメージをアップグレードする際に、新しい HAL バージョンを実装するかターゲット FCM バージョンをインクリメントする方法を説明しています。
- マッチング ルールでは、互換性マトリックスとマニフェストが一致するためのルールを定義しています。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-07-27 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 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."]]