Kể từ ngày 27 tháng 3 năm 2025, bạn nên sử dụng android-latest-release
thay vì aosp-main
để xây dựng và đóng góp cho AOSP. Để biết thêm thông tin, hãy xem phần Thay đổi đối với AOSP.
Đối tượng giao diện nhà cung cấp
Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Tài liệu này mô tả thiết kế của đối tượng giao diện nhà cung cấp (đối tượng VINTF). Đối tượng này tổng hợp thông tin liên quan về một thiết bị và cung cấp thông tin đó thông qua một API có thể truy vấn.
Thiết kế đối tượng VINTF
Đối tượng VINTF thu thập một số thông tin cần thiết trực tiếp từ thiết bị. Các khía cạnh khác, chẳng hạn như tệp kê khai, được mô tả tĩnh trong XML.
Hình 1. Tệp kê khai, ma trận khả năng tương thích và thông tin có thể thu thập trong thời gian chạy.
Thiết kế đối tượng VINTF cung cấp những thông tin sau cho các thành phần thiết bị và khung:
Đối với thiết bị |
Đối với Khung |
- Xác định giản đồ cho thành phần tĩnh (tệp kê khai thiết bị).
- Thêm tính năng hỗ trợ thời gian xây dựng để xác định tệp kê khai thiết bị cho một thiết bị nhất định.
- Xác định API có thể truy vấn trong thời gian chạy để truy xuất tệp kê khai thiết bị (cùng với các thông tin khác có thể thu thập được trong thời gian chạy) và đóng gói các tệp đó vào kết quả truy vấn.
|
|
Đối tượng VINTF phải đáng tin cậy và cung cấp cùng một thông tin đầy đủ bất kể thời điểm yêu cầu đối tượng (xem Thận trọng).
Tệp kê khai và ma trận
Kể từ Android 8.0, API thời gian chạy sẽ truy vấn nội dung trên thiết bị và gửi thông tin đó đến máy chủ cập nhật qua mạng không dây (OTA) và các bên quan tâm khác (chẳng hạn như CTS DeviceInfo
). Một số thông tin được truy xuất trong thời gian chạy và một số thông tin được xác định tĩnh.
- Tệp kê khai thiết bị mô tả thành phần tĩnh của những gì thiết bị có thể cung cấp cho khung.
- Ma trận tương thích khung mô tả những gì khung Android mong đợi từ một thiết bị nhất định. Ma trận là một thực thể tĩnh, có thành phần được xác định theo cách thủ công trong quá trình phát triển bản phát hành tiếp theo của khung Android.
- Tệp kê khai khung mô tả các dịch vụ cấp cao mà khung có thể cung cấp cho thiết bị.
- Ma trận khả năng tương thích của thiết bị mô tả các dịch vụ mà hình ảnh nhà cung cấp yêu cầu đối với khung. Thành phần của nó được xác định theo cách thủ công trong quá trình phát triển thiết bị.
Hai cặp tệp kê khai và ma trận này phải được điều chỉnh cho phù hợp tại thời điểm OTA để đảm bảo thiết bị có thể nhận được các bản cập nhật khung tương thích với chức năng của thiết bị. Nhìn chung, tệp kê khai mô tả nội dung được cung cấp và ma trận khả năng tương thích mô tả nội dung bắt buộc.
Phần này bao gồm các thông tin chi tiết sau đây về tệp kê khai và ma trận:
- Tệp kê khai xác định tệp kê khai thiết bị, tệp kê khai khung và giản đồ tệp kê khai.
- Ma trận tương thích xác định giản đồ cho ma trận tương thích.
- Vòng đời FCM trình bày chi tiết cách các HAL HIDL không còn được dùng nữa và bị xoá, cũng như cách các tệp FCM được sửa đổi để phản ánh trạng thái của Phiên bản HAL.
- Phát triển DM mô tả cách nhà cung cấp có thể xác định và khai báo Phiên bản FCM mục tiêu trong tệp kê khai thiết bị cho thiết bị mới hoặc triển khai các phiên bản HAL mới và tăng Phiên bản FCM mục tiêu khi nâng cấp hình ảnh nhà cung cấp cho thiết bị cũ.
- Quy tắc so khớp xác định các quy tắc để so khớp thành công giữa một ma trận khả năng tương thích và một tệp kê khai.
Nội dung và mã mẫu trên trang này phải tuân thủ các giấy phép như mô tả trong phần Giấy phép nội dung. Java và OpenJDK là nhãn hiệu hoặc nhãn hiệu đã đăng ký của Oracle và/hoặc đơn vị liên kết của Oracle.
Cập nhật lần gần đây nhất: 2025-07-27 UTC.
[[["Dễ hiểu","easyToUnderstand","thumb-up"],["Giúp tôi giải quyết được vấn đề","solvedMyProblem","thumb-up"],["Khác","otherUp","thumb-up"]],[["Thiếu thông tin tôi cần","missingTheInformationINeed","thumb-down"],["Quá phức tạp/quá nhiều bước","tooComplicatedTooManySteps","thumb-down"],["Đã lỗi thời","outOfDate","thumb-down"],["Vấn đề về bản dịch","translationIssue","thumb-down"],["Vấn đề về mẫu/mã","samplesCodeIssue","thumb-down"],["Khác","otherDown","thumb-down"]],["Cập nhật lần gần đây nhất: 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."]]