Starting March 27, 2025, we recommend using android-latest-release instead of aosp-main to build and contribute to AOSP. For more information, see Changes to AOSP.
Stay organized with collections
Save and categorize content based on your preferences.
To migrate an existing HIDL VHAL implementation to an AIDL VHAL,
use the
AIDL reference implementation
structure to implement the IVehicleHardware interface.
If the existing HIDL implementation also follows
HIDL reference implementation,
the vendor has implemented the VehicleHal class. IVehicleHardware is
very similar to VehicleHal.
HIDL VHAL
AIDL VHAL
getAllPropertyConfigs()
Same as VehicleHal.listProperties()
getValues(callback, requests)
Can call VehicleHal.get() for each request and can call callbacks.
dump()
Same as VehicleHal.dump()
checkHealth()
Can return VehicleHal.get()
registerPropertyChangeCallback()
Similar to setting VehicleHal.mOnHalEvent
Type differences in AIDL
When migrating from the HIDL VHAL to the AIDL VHAL, consider these differences.
HIDL generates one header file (types.h) for all types generated from
types.hal. AIDL generates one header file for each type. For example,
VehiclePropValue.h from VehiclePropValue.aidl.
As a result, you must include all header files for the types you need. A helper file,
VehicleHalTypes.h in the VehicleHalUtils library contains most of
the common types.
Instead of ...
Use
hidl_vec
std::vector
hidl_string
std::string
android::sp
std::shared_ptr
android::wp
std::weak_ptr
All types defined in types.hal are the same in AIDL except for:
SubscribeFlags is removed as it's not used because
onPropertySet is removed
UserFlags is now defined in UserInfo.aidl and should be defined
as a flag instead of an enum. A user flag field is an integer that has multiple
UserInfo.USER_FLAG_XXX bit-or together.
RawValue in VehiclePropValue is renamed as
RawPropValue
bytes in RawValue is renamed as byteValues
Content and code samples on this page are subject to the licenses described in the Content License. Java and OpenJDK are trademarks or registered trademarks of Oracle and/or its affiliates.
Last updated 2025-08-29 UTC.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Missing the information I need","missingTheInformationINeed","thumb-down"],["Too complicated / too many steps","tooComplicatedTooManySteps","thumb-down"],["Out of date","outOfDate","thumb-down"],["Samples / code issue","samplesCodeIssue","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-29 UTC."],[],[],null,["# HIDL VHAL migration guide\n\nTo migrate an existing **HIDL** VHAL implementation to an **AIDL** VHAL,\nuse the\n[AIDL reference implementation](/docs/automotive/vhal/reference-implementation)\nstructure to implement the `IVehicleHardware` interface.\n\nIf the existing HIDL implementation also follows\n[HIDL reference implementation](https://android.googlesource.com/platform/hardware/interfaces/+/refs/heads/android16-release/automotive/vehicle/2.0/default/impl/vhal_v2_0),\nthe vendor has implemented the `VehicleHal` class. `IVehicleHardware` is\nvery similar to `VehicleHal`.\n| **Note:** AIDL uses different types than HIDL. Some types used in the HIDL implementation must be migrated. For detail, see [Type differences in AIDL](#aidl-diffs) below.\n\n| HIDL VHAL | AIDL VHAL |\n|------------------------------------|----------------------------------------------------------------------|\n| `getAllPropertyConfigs()` | Same as `VehicleHal.listProperties()` |\n| `getValues(callback, requests)` | Can call `VehicleHal.get()` for each request and can call callbacks. |\n| `dump()` | Same as `VehicleHal.dump()` |\n| `checkHealth()` | Can return `VehicleHal.get()` |\n| `registerPropertyChangeCallback()` | Similar to setting `VehicleHal.mOnHalEvent` |\n\nType differences in AIDL\n------------------------\n\nWhen migrating from the HIDL VHAL to the AIDL VHAL, consider these differences.\n\n1. HIDL generates one header file (`types.h`) for all types generated from `types.hal`. AIDL generates one header file for each type. For example, `VehiclePropValue.h` from `VehiclePropValue.aidl`.\n\n As a result, you must include all header files for the types you need. A helper file,\n `VehicleHalTypes.h` in the `VehicleHalUtils` library contains most of\n the common types.\n\n| Instead of ... | Use |\n|----------------|-------------------|\n| `hidl_vec` | `std::vector` |\n| `hidl_string` | `std::string` |\n| `android::sp` | `std::shared_ptr` |\n| `android::wp` | `std::weak_ptr` |\n\n2. All types defined in `types.hal` are the same in AIDL **except** for:\n - `SubscribeFlags` is removed as it's not used because `onPropertySet` is removed\n - `UserFlags` is now defined in `UserInfo.aidl` and should be defined as a flag instead of an enum. A user flag field is an integer that has multiple `UserInfo.USER_FLAG_XXX` bit-or together.\n - `RawValue` in `VehiclePropValue` is renamed as `RawPropValue`\n - `bytes` in `RawValue` is renamed as `byteValues`"]]
