از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
تأیید سازگاری با چارچوب HIDL
با مجموعه‌ها، منظم بمانید
ذخیره و طبقه‌بندی محتوا براساس اولویت‌های شما.
HIDL HAL تضمین می‌کند که سیستم اصلی Android (با نام مستعار system.img یا فریمورک) سازگار با عقب است. در حالی که تست‌های مجموعه تست فروشنده (VTS) تضمین می‌کنند که HALها همانطور که انتظار می‌رود کار می‌کنند (مثلاً آزمایش‌های HAL 1.1 در تمام پیاده‌سازی‌های 1.2 اجرا می‌شوند)، آزمایش چارچوب لازم است تا اطمینان حاصل شود که وقتی یک HAL پشتیبانی شده (1.0، 1.1 یا 1.2) ارائه می‌شود، چارچوب به درستی با آن HAL کار می‌کند.
برای جزئیات بیشتر در مورد زبان تعریف رابط HAL (HIDL)، به HIDL ، نسخه‌سازی HIDL و حذف HIDL HAL مراجعه کنید.
درباره ارتقاء HAL
دو نوع ارتقاء HAL وجود دارد: عمده و جزئی . اکثر سیستم ها فقط یک پیاده سازی HAL را شامل می شوند، اما چندین پیاده سازی پشتیبانی می شوند. به عنوان مثال:
android.hardware.teleport@1.0 # initial interface
android.hardware.teleport@1.1 # minor version upgrade
android.hardware.teleport@1.2 # another minor version upgrade
...
android.hardware.teleport@2.0 # major version upgrade
...
پارتیشن سیستم معمولاً شامل یک دیمون فریمورک (مانند teleportd ) است که ارتباط با گروه خاصی از پیاده سازی های HAL را مدیریت می کند. روش دیگر، سیستم‌ها ممکن است در عوض شامل یک کتابخانه سیستمی (مانند android.hardware.configstore-utils ) باشند که رفتار راحت مشتری را پیاده‌سازی می‌کند. در مثال بالا، teleportd باید بدون توجه به اینکه چه نسخه ای از HAL روی دستگاه نصب شده است، کار کند.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و OpenJDK علامتهای تجاری یا علامتهای تجاری ثبتشده Oracle و/یا وابستههای آن هستند.
تاریخ آخرین بهروزرسانی 2025-07-29 بهوقت ساعت هماهنگ جهانی.
[[["درک آسان","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-29 بهوقت ساعت هماهنگ جهانی."],[],[],null,["# HIDL Framework backward compatibility verification\n\n[HIDL HALs](/docs/core/architecture#hidl)\nguarantee the Android core system (aka system.img or the framework) is\nbackward compatible. While [Vendor Test Suite (VTS)](/docs/compatibility/vts)\ntests ensure that HALs work as expected (e.g. 1.1 HAL tests are run on all\n1.2 implementations), framework testing is needed to ensure that when a\nsupported HAL (1.0, 1.1, or 1.2) is provided, the framework works properly\nwith that HAL.\n\nFor details on HAL interface definition language (HIDL), refer to\n[HIDL](/docs/core/architecture/hidl), [HIDL versioning](/docs/core/architecture/hidl/versioning), and [HIDL HAL Deprecation](/docs/core/architecture/vintf/fcm#hal-version-deprecation).\n\nAbout HAL upgrades\n------------------\n\nThere are two types of HAL upgrades: *major* and *minor*.\nMost systems include only one HAL implementation, but multiple\nimplementations are supported. For example: \n\n```\nandroid.hardware.teleport@1.0 # initial interface\nandroid.hardware.teleport@1.1 # minor version upgrade\nandroid.hardware.teleport@1.2 # another minor version upgrade\n...\nandroid.hardware.teleport@2.0 # major version upgrade\n...\n```\n\nThe system partition typically includes a framework daemon (such as\n`teleportd`) that manages communication with a specific group of\nHAL implementations. Alternatively, systems might instead\ninclude a system library (such as\n`android.hardware.configstore-utils`) that implements convenient\nclient behavior. In the example above, `teleportd` must work no\nmatter what version of the HAL is installed on the device."]]
