اعتبارًا من 27 آذار (مارس) 2025، ننصحك باستخدام android-latest-release بدلاً من aosp-main لإنشاء AOSP والمساهمة فيه. لمزيد من المعلومات، يُرجى الاطّلاع على التغييرات في AOSP.
عنصر واجهة المورّد
تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
يصف هذا المستند تصميم عنصر واجهة المورّد
(VINTF)، الذي يجمع المعلومات ذات الصلة بالجهاز ويُتيح
هذه المعلومات من خلال واجهة برمجة تطبيقات قابلة للبحث.
تصميم عنصر VINTF
يجمع عنصر VINTF بعض المعلومات التي يحتاجها مباشرةً من
الجهاز. ويتم وصف الجوانب الأخرى، مثل ملفات البيان، بشكل ثابت في ملف XML.
الشكل 1: ملفات البيان ومصفوفات التوافق والمعلومات التي يمكن جمعها في وقت التشغيل
يقدّم تصميم عنصر VINTF ما يلي لمكونات الإطار والجهاز:
| للجهاز |
بالنسبة إلى "إطار العمل" |
|
|
|
يجب أن يكون عنصر VINTF موثوقًا وأن يقدّم المعلومات الكاملة نفسها
بغض النظر عن وقت طلب العنصر (راجِع
الاحتياطات).
ملفات البيانات والمصفّحات
اعتبارًا من Android 8.0، تبحث واجهة برمجة التطبيقات لوقت التشغيل في المحتوى المتوفّر على الجهاز وترسل هذه
المعلومات إلى خادم التحديث اللاسلكي (OTA)
والجهات المعنيّة الأخرى (مثل CTS
DeviceInfo). ويتم استرداد بعض المعلومات في وقت التشغيل، ويكون بعضها
محددًا بشكل ثابت.
- يصف بيان الجهاز المكوّن الثابت لما يمكن أن يوفّره الجهاز للإطار.
- تصف مصفوفة توافق إطار العمل المتطلبات التي يتوقعها
إطار عمل Android من جهاز معيّن. المصفوفة هي عنصر ثابت
يتم تحديد تركيبته يدويًا أثناء تطوير الإصدار التالي
من إطار عمل Android.
- يصف بيان إطار العمل الخدمات العالية المستوى التي يمكن لإطار العمل تقديمها للجهاز.
- توضِّح مصفوفة توافق الأجهزة الخدمات التي تتطلّب
صورة المورّد من إطار العمل. ويتم تحديد تركيبته يدويًا
أثناء تطوير الجهاز.
يجب مراجعة هذين الزوجين من البيانات والمصفّحات في وقت التحديث عبر شبكة غير سلكيّة لضمان حصول الجهاز على تحديثات إطار العمل المتوافقة مع إمكانات الجهاز. بشكل عام، يصف البيان ما يتم تقديمه، وتصف
مصفوفة التوافق ما هو مطلوب.
يتضمّن هذا القسم التفاصيل التالية حول نماذج البيانات والمصفّحات:
- تحدِّد ملفات البيان
بيان الجهاز وبيان إطار العمل ومخطّط ملف البيان.
- مصفوفات
التوافق: تحدِّد هذه السمة مخطّط مصفوفة التوافق.
- تفاصيل دورة حياة FCM:
كيفية إيقاف واجهات HIDL HAL نهائيًا وإزالتها وكيفية تعديل ملفات FCM لعكس حالة إصدار HAL
- يصف تطوير إدارة الخدمات
كيفية تحديد المورّدين للإصدار المستهدَف من "إطار عمل إدارة إشعارات Android" وتعريفه في بيان
الجهاز للأجهزة الجديدة أو تنفيذ إصدارات جديدة من HAL وزيادة
الإصدار المستهدَف من "إطار عمل إدارة إشعارات Android" عند ترقية صورة المورّد للأجهزة القديمة.
- تحدِّد قواعد المطابقة
قواعد المطابقة الناجحة بين مصفوفة التوافق وملف البيان.
يخضع كل من المحتوى وعيّنات التعليمات البرمجية في هذه الصفحة للتراخيص الموضحّة في ترخيص استخدام المحتوى. إنّ 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."]]
