ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release แทน aosp-main เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
ออบเจ็กต์อินเทอร์เฟซของผู้ให้บริการ
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
เอกสารนี้อธิบายการออกแบบออบเจ็กต์อินเทอร์เฟซของผู้ให้บริการ (ออบเจ็กต์ VINTF) ซึ่งรวบรวมข้อมูลที่เกี่ยวข้องเกี่ยวกับอุปกรณ์และทำให้ข้อมูลดังกล่าวพร้อมใช้งานผ่าน API ที่ค้นหาได้
การออกแบบออบเจ็กต์ VINTF
ออบเจ็กต์ VINTF จะรวบรวมข้อมูลบางอย่างที่ต้องการจากอุปกรณ์โดยตรง ส่วนอื่นๆ เช่น ไฟล์ Manifest จะอธิบายแบบคงที่ใน XML
รูปที่ 1 ไฟล์ Manifest, ตารางความเข้ากันได้ และข้อมูลที่รวบรวมได้ในช่วงรันไทม์
การออกแบบออบเจ็กต์ VINTF มีข้อมูลต่อไปนี้สำหรับคอมโพเนนต์ของอุปกรณ์และเฟรมเวิร์ก
| สำหรับอุปกรณ์ |
สําหรับเฟรมเวิร์ก |
- กําหนดสคีมาสําหรับคอมโพเนนต์แบบคงที่ (ไฟล์ Manifest ของอุปกรณ์)
- เพิ่มการรองรับเวลาสร้างสำหรับการกำหนดไฟล์ Manifest ของอุปกรณ์สำหรับอุปกรณ์หนึ่งๆ
- กำหนดAPI ที่ค้นหาได้ที่รันไทม์ซึ่งจะเรียกข้อมูลไฟล์ Manifest ของอุปกรณ์ (พร้อมกับข้อมูลอื่นๆ ที่รวบรวมได้ในรันไทม์) และแพ็กเกจไว้ในผลการค้นหา
|
- กําหนดสคีมาสําหรับคอมโพเนนต์แบบคงที่ (ไฟล์ Manifest ของเฟรมเวิร์ก)
- กำหนดAPI ที่ค้นหาได้ขณะรันไทม์ ซึ่งจะดึงข้อมูลไฟล์ Manifest ของเฟรมเวิร์กและจัดแพ็กเกจเป็นผลการค้นหา
|
ออบเจ็กต์ VINTF ต้องเชื่อถือได้และให้ข้อมูลที่สมบูรณ์แบบเดียวกันไม่ว่าจะขอเมื่อใดก็ตาม (ดูข้อควรระวัง)
ไฟล์ Manifest และ Matrix
ตั้งแต่ Android 8.0 เป็นต้นไป API รันไทม์จะค้นหาสิ่งที่อยู่ในอุปกรณ์และส่งข้อมูลนั้นไปยังเซิร์ฟเวอร์การอัปเดตแบบ OTA และบุคคลอื่นๆ ที่สนใจ (เช่น CTSDeviceInfo) ระบบจะดึงข้อมูลบางอย่างในรันไทม์และกำหนดข้อมูลบางอย่างแบบคงที่
- ไฟล์ Manifest ของอุปกรณ์จะอธิบายคอมโพเนนต์แบบคงที่ของสิ่งที่อุปกรณ์สามารถมอบให้เฟรมเวิร์ก
- ตารางความเข้ากันได้ของเฟรมเวิร์กจะอธิบายสิ่งที่เฟรมเวิร์ก Android คาดหวังจากอุปกรณ์หนึ่งๆ เมทริกซ์คือเอนทิตีแบบคงที่ซึ่งกำหนดองค์ประกอบด้วยตนเองในระหว่างการพัฒนาเฟรมเวิร์ก Android รุ่นถัดไป
- ไฟล์ Manifest ของเฟรมเวิร์กจะอธิบายบริการระดับสูงที่เฟรมเวิร์กสามารถให้บริการแก่อุปกรณ์
- เมทริกซ์ความเข้ากันได้ของอุปกรณ์จะอธิบายบริการที่รูปภาพผู้ให้บริการต้องการจากเฟรมเวิร์ก โดยกำหนดองค์ประกอบด้วยตนเองในระหว่างการพัฒนาอุปกรณ์
คุณต้องปรับยอดไฟล์ Manifest และเมทริกซ์ 2 คู่นี้เมื่อถึงเวลา OTA เพื่อให้อุปกรณ์รับการอัปเดตเฟรมเวิร์กที่เข้ากันได้กับความสามารถของอุปกรณ์ โดยทั่วไป ไฟล์ Manifest จะอธิบายสิ่งที่มีให้ และตารางความเข้ากันได้จะอธิบายสิ่งที่จําเป็น
ส่วนนี้ประกอบด้วยรายละเอียดต่อไปนี้เกี่ยวกับไฟล์ Manifest และตาราง
- ไฟล์ Manifest จะกำหนดไฟล์ Manifest ของอุปกรณ์ ไฟล์ Manifest ของเฟรมเวิร์ก และสคีมาไฟล์ Manifest
- เมทริกซ์ความเข้ากันได้จะกำหนดสคีมาสำหรับเมทริกซ์ความเข้ากันได้
- รายละเอียดวงจรชีวิตของ FCM กล่าวถึงการเลิกใช้งานและนํา HIDL HAL ออก รวมถึงการแก้ไขไฟล์ FCM ให้แสดงสถานะของเวอร์ชัน HAL
- การพัฒนา DM อธิบายวิธีกำหนดและประกาศเวอร์ชัน FCM เป้าหมายในไฟล์ Manifest ของอุปกรณ์สำหรับอุปกรณ์ใหม่ หรือติดตั้งใช้งาน HAL เวอร์ชันใหม่และเพิ่มเวอร์ชัน FCM เป้าหมายเมื่ออัปเกรดรูปภาพผู้ให้บริการสำหรับอุปกรณ์เก่า
- กฎการจับคู่
กำหนดกฎสำหรับการจับคู่ที่สำเร็จระหว่างเมทริกซ์ความเข้ากันได้กับไฟล์ Manifest
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา 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."]]
