از 27 مارس 2025، توصیه می کنیم از android-latest-release به جای aosp-main برای ساختن و کمک به AOSP استفاده کنید. برای اطلاعات بیشتر، به تغییرات AOSP مراجعه کنید.
پیاده سازی مرجع بر اساس معماری دو لایه است. در لایه بالایی، DefaultVehicleHal ، رابط VHAL AIDL را پیاده سازی می کند و منطق کلی VHAL را برای تمام دستگاه های سخت افزاری ارائه می دهد. در لایه پایین، FakeVehicleHardware ، رابط IVehicleHardware را پیاده سازی می کند. این کلاس منطق VHAL تعامل با سخت افزار واقعی یا اتوبوس وسیله نقلیه را شبیه سازی می کند و برای دستگاه خاص است. به صورت اختیاری، فروشندگان می توانند همین معماری را تطبیق دهند، از همان کلاس DefaultVehicleHal مجددا استفاده کنند (آن را برای بازنویسی یک متد گسترش دهند)، و پیاده سازی IVehicleHardware خود را ارائه دهند.
شکل 1. پیاده سازی مرجع VHAL
DefaultVehicleHal شامل منطق زیر است که عمومی در نظر گرفته می شود و می تواند برای هر پیاده سازی VHAL اعمال شود.
رابط IVehicle را پیاده سازی می کند.
بررسی های ورودی اولیه، از جمله بررسی شناسه های تکراری را انجام می دهد.
اشیاء کلاینت (به عنوان مثال GetValuesClient ) را برای هر عملیات برای هر کلاینت بایندر اختصاص می دهد و هر کدام را به یک استخر جهانی اضافه می کند.
منطق پاسخهای تماس غیرهمگام را مدیریت میکند، مانند افزودن یک درخواست در حال انتظار به یک مجموعه درخواست در انتظار. زمانی که نتایج را دریافت میکنیم، درخواستهای معلق را حل میکند یا زمانی که زمان یکی از درخواستهای در انتظار تمام میشود، خطا را برمیگرداند.
LargeParcelable را سریالسازی و از سریال خارج میکند (به ParcelableUtils.h مراجعه کنید).
اشتراک را مدیریت می کند (به SubscriptionManager.h مراجعه کنید).
مجوزها را بررسی می کند. (به توابع checkReadPermission و checkWritePermission مراجعه کنید).
به طور دوره ای IVehicleHardware.checkHealth را فراخوانی می کند و سیگنال های ضربان قلب را ارسال می کند (به تابع checkHealth مراجعه کنید).
IVehicleHardware یک رابط عمومی است که برای نشان دادن پیاده سازی سخت افزاری خاص VHAL استفاده می شود. پیاده سازی مرجع برای IVehicleHardwareFakeVehicleHardware است که از یک نقشه در حافظه برای ذخیره ارزش دارایی استفاده می کند و با اتوبوس واقعی وسیله نقلیه ارتباط برقرار نمی کند. در نظر گرفته شده است که روی یک شبیه ساز اجرا شود و هیچ وابستگی خاص سخت افزاری ندارد. پیاده سازی فروشنده نباید آن را همانطور که هست استفاده کند و باید منطق اتوبوس وسیله نقلیه خاص را اضافه کند.
با شروع اندروید 14، FakeVehicleHardware پیکربندی ویژگی پشتیبانیشده را در زمان اجرا و در حین اولیهسازی از پوشه /vendor/etc/automotive/vhalconfig/ دستگاه، که حاوی یک فایل پیکربندی به سبک JSON است، میخواند. برای فرمت فایل پیکربندی و محتوای فایل پیکربندی به فایل مرجع VHAL README مراجعه کنید.
FakeVehicleHardware همچنین از لغو فایل پیکربندی برای آزمایش پشتیبانی می کند. اگر ویژگی سیستم persist.vendor.vhal_init_value_override تنظیم شده باشد (این ویژگی باید در زمان ساخت یا خیلی زود هنگام راهاندازی قبل از شروع VHAL تنظیم شود)، از فایل پیکربندی پوشه /vendor/etc/automotive/vhaloverride/ روی دستگاه استفاده میکند تا پیکربندی موجود را لغو کند. پیاده سازی فروشنده می تواند از رویکرد مشابهی استفاده کند تا پیکربندی ویژگی پشتیبانی شده از VHAL به صورت سخت کدگذاری نشده باشد و بتوان در زمان شروع به صورت پویا تصمیم گیری کرد. پس از مقداردهی اولیه VHAL، لیست تنظیمات ویژگی خودرو باید ثابت باشد.
با شروع اندروید 16، GRPCVehicleHardware مرجع دیگری برای پیاده سازی IVehicleHardware ارائه می دهد. این پیاده سازی فرض می کند که یک سرور جداگانه در حال اجرا بر روی یک ماشین راه دور یا VM است که حاوی منطق مدیریت ویژگی است. VHAL در حال اجرا بر روی دستگاه های AAOS به عنوان یک پروکسی عمل می کند که درخواست ها را به سرور راه دور ارسال می کند. برای جزئیات بیشتر به grpc مراجعه کنید.
محتوا و نمونه کدها در این صفحه مشمول پروانههای توصیفشده در پروانه محتوا هستند. جاوا و 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,["# Reference implementation\n\nWe provide a\n[reference implementation](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current)\nfor the AIDL VHAL. The main service thread is implemented\nat\n[`VehicleService.cpp`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current/vhal/src/VehicleService.cpp).\nThe VHAL interface implementation is located at\n[`DefaultVehicleHal.cpp`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current/vhal/src/DefaultVehicleHal.cpp).\n\n\nThe reference implementation is based on a two-layer architecture. On the upper layer,\n`DefaultVehicleHal`, implements VHAL AIDL interface and provides VHAL logic\ngeneric to all hardware devices. On the lower layer, `FakeVehicleHardware`,\nimplements the `IVehicleHardware` interface. This class simulates the VHAL logic\nof interacting with actual hardware or vehicle bus and is device-specific. Optionally, vendors\ncan adapt this same architecture, reuse the same `DefaultVehicleHal` class (extending\nit to overwrite a method), and provide their own `IVehicleHardware` implementation.\n**Figure 1.** VHAL reference implementation\n\n[`DefaultVehicleHal`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current/vhal/src/DefaultVehicleHal.cpp)\ncontains the following logic, which is considered to be generic and can apply to any VHAL\nimplementation.\n\n- Implements the `IVehicle` interface.\n- Performs basic input checks, including a check for duplicate IDs.\n- Allocates client objects (for example, `GetValuesClient`) for each operation for each binder client, and adds each to a global pool.\n- Manages async callbacks logic, such as adding a pending request to a pending request pool. Resolves pending requests when we receive the results or returns error when one of the pending requests times out.\n- Serializes and deserializes `LargeParcelable` (see `ParcelableUtils.h`).\n- Manages subscription (see `SubscriptionManager.h`).\n- Checks permissions. (See the `checkReadPermission` and `checkWritePermission` functions).\n- Periodically calls `IVehicleHardware.checkHealth` and sends heartbeat signals (see the `checkHealth` function).\n\n[`IVehicleHardware`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current/hardware/include/IVehicleHardware.h)\nis a generic interface used to represent a VHAL's hardware-specific\nimplementation. The reference implementation for `IVehicleHardware` is\n[`FakeVehicleHardware`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current/fake_impl/hardware/src/FakeVehicleHardware.cpp),\nwhich uses an in-memory map to store property value and does\nnot communicate with an actual vehicle bus. It's intended to run on an emulator and have no\nhardware-specific dependencies. Vendor implementations must not use it as-is and must add\nvehicle bus-specific logic.\n\nStarting in Android 14, `FakeVehicleHardware` reads the supported property config at run-time\nduring initialization from the device's `/vendor/etc/automotive/vhalconfig/` folder,\nwhich contains a JSON-style config file. See the\n[reference VHAL README file](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current/default_config/config/README.md)\nfor config file format and config file content.\n\n`FakeVehicleHardware` also supports config file override for testing. If the\nsystem property `persist.vendor.vhal_init_value_override` is set (this property must be\nset at build time or very early during boot before VHAL initialization), it uses the config\nfile from the `/vendor/etc/automotive/vhaloverride/` folder on the device to override\nthe existing configuration. A vendor implementation can use a similar approach so that the VHAL-\nsupported property configuration is not hard-coded and can be dynamically decided at start time.\nThe list of vehicle property configs must be static after VHAL is initialized.\n\nStarting in Android 16, [`GRPCVehicleHardware`](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current/grpc/GRPCVehicleHardware.cpp)\nprovides another reference `IVehicleHardware` implementation. This implementation\nassumes there is a separate server running on a remote machine or VM which contains the property\nhandling logic. The VHAL running on AAOS devices acts as a proxy that forwards requests to\nthe remote server. See [grpc](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/aidl/impl/current/README.md#grpc)\nfor more details."]]