החל מ-27 במרץ 2025, מומלץ להשתמש ב-android-latest-release במקום ב-aosp-main כדי ליצור תרומות ל-AOSP. מידע נוסף זמין במאמר שינויים ב-AOSP.
אובייקט של ממשק הספק
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
במסמך הזה מתוארת התכנון של אובייקט ממשק הספק (אובייקט VINTF), שמאגד מידע רלוונטי על מכשיר ומאפשר גישה למידע הזה דרך API שניתן לשלוח אליו שאילתות.
עיצוב אובייקט VINTF
אובייקט VINTF אוסף חלק מהמידע הדרוש לו ישירות מהמכשיר. היבטים אחרים, כמו המניפסטים, מתוארים באופן סטטי ב-XML.
איור 1. מניפסטים, מטריצות תאימות ומידע שניתן לאסוף בזמן ריצה.
עיצוב האובייקט של VINTF מספק את האפשרויות הבאות לרכיבי המכשיר והמסגרת:
אובייקט ה-VINTF חייב להיות מהימן ולספק את אותו מידע מלא, ללא קשר למועד שבו מבקשים את האובייקט (ראו אזהרות).
מניפסטים ומטריצות
החל מגרסה 8.0 של Android, ממשק API בסביבת זמן הריצה שולח שאילתה לגבי מה שנמצא במכשיר ושולח את המידע הזה לשרת העדכונים Over-the-Air (OTA) ולגורמים אחרים שעשויים להתעניין בו (כמו CTS DeviceInfo). חלק מהמידע מאוחזר בסביבת זמן הריצה וחלק מוגדר באופן סטטי.
- מניפסט המכשיר מתאר את הרכיב הסטטי של מה שהמכשיר יכול לספק למסגרת.
- מטריצה של תאימות המסגרת מתארת את מה שמערכת Android מצפה ממכשיר נתון. המטריצה היא ישות סטטית שההרכב שלה נקבע באופן ידני במהלך הפיתוח של הגרסה הבאה של מסגרת Android.
- מניפסט המסגרת מתאר שירותים ברמה גבוהה שהמסגרת יכולה לספק למכשיר.
- במטריצה של תאימות המכשירים מתוארים השירותים שהמסגרת צריכה לספק לתמונת הספק. ההרכב שלו נקבע באופן ידני במהלך הפיתוח של המכשיר.
צריך להתאים בין שני זוגות המניפסטים והמטריצות האלה בזמן ה-OTA כדי לוודא שמכשיר יכול לקבל עדכוני מסגרת שתואמים ליכולות שלו. באופן כללי, מניפסט מתאר את מה שסופק, ומטריצה של תאימות מתארת את מה שנדרש.
בקטע הזה מפורטים הפרטים הבאים לגבי מניפסטים ומטריצות:
- מניפסטים מגדירים את המניפסט של המכשיר, את המניפסט של המסגרת ואת הסכימה של קובץ המניפסט.
- Compatibility
Matrixes מגדיר את הסכימה של מטריצת התאימות.
- במאמר מחזור החיים של FCM מוסבר איך מוציאים משימוש ומסירים ממשק HAL של HIDL, ואיך משנים את קבצי FCM כך שישקפו את הסטטוס של גרסת ה-HAL.
- בקטע פיתוח DM מוסבר איך ספקים יכולים להגדיר ולהצהיר על גרסת היעד של FCM במניפסט של המכשיר למכשירים חדשים, או להטמיע גרסאות HAL חדשות ולהגדיל את גרסת היעד של FCM כשמשדרגים את קובץ האימג' של הספק למכשירים ישנים.
- Matching Rules (כללי התאמה) מגדירים את הכללים להתאמה בין מטריצה של תאימות לבין מניפסט.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. 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."]]
