自 2025 年 3 月 27 日起,我們建議您使用 android-latest-release
而非 aosp-main
建構及貢獻 AOSP。詳情請參閱「Android 開放原始碼計畫變更」。
供應商介面物件
透過集合功能整理內容
你可以依據偏好儲存及分類內容。
本文件說明供應商介面物件 (VINTF 物件) 的設計,該物件會匯總裝置相關資訊,並透過可查詢的 API 提供這些資訊。
VINTF 物件設計
VINTF 物件會直接從裝置收集所需的部分資訊。其他方面 (例如資訊清單) 則會在 XML 中以靜態方式描述。
圖 1. 資訊清單、相容性矩陣和可在執行階段收集的資訊。
VINTF 物件設計可為裝置和架構元件提供下列功能:
裝置 |
適用於架構 |
- 定義靜態元件 (裝置資訊清單檔案) 的結構。
- 新增建構時間支援功能,可為特定裝置定義裝置資訊清單檔案。
- 在執行階段定義可查詢的 API,用於擷取裝置資訊清單檔案 (以及其他可在執行階段收集的資訊),並將這些資訊封裝至查詢結果。
|
|
VINTF 物件必須可靠,且無論何時要求物件,都能提供相同的完整資訊 (請參閱「注意事項」)。
資訊清單和矩陣
自 Android 8.0 起,執行階段 API 會查詢裝置上的內容,並將該資訊傳送至無線 (OTA) 更新伺服器和其他相關方 (例如 CTS DeviceInfo
)。部分資訊會在執行階段擷取,部分資訊則會以靜態方式定義。
- 裝置資訊清單會說明裝置可向架構提供的靜態元件。
- 架構相容性矩陣說明 Android 架構對特定裝置的預期需求。矩陣是靜態實體,其組合是在開發 Android 架構的下一個版本時手動決定。
- 架構資訊清單會說明架構可為裝置提供的高層服務。
- 裝置相容性矩陣說明供應商映像檔對架構所需的服務。其組合是在裝置開發期間手動決定。
這兩組資訊清單和矩陣必須在 OTA 期間進行調和,以確保裝置可取得與其功能相容的架構更新。一般來說,資訊清單會說明提供的內容,而相容性矩陣則會說明所需的內容。
本節包含以下資訊,說明如何設定資訊清單和矩陣:
- 「資訊清單」會定義裝置資訊清單、架構資訊清單和資訊清單檔案結構定義。
- 相容性矩陣定義相容性矩陣的結構定義。
- FCM 生命週期詳細說明如何淘汰及移除 HIDL HAL,以及如何修改 FCM 檔案,以反映 HAL 版本的狀態。
- 「DM 開發」一文說明供應商如何在裝置資訊清單中為新裝置定義及宣告目標 FCM 版本,或在為舊裝置升級供應商映像檔時,實作新版 HAL 並增加目標 FCM 版本。
- 比對規則定義相容性矩陣和資訊清單之間成功比對的規則。
這個頁面中的內容和程式碼範例均受《內容授權》中的授權所規範。Java 與 OpenJDK 是 Oracle 和/或其關係企業的商標或註冊商標。
上次更新時間:2025-07-27 (世界標準時間)。
[[["容易理解","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 (世界標準時間)。"],[],[],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."]]