Reference implementation

We provide a reference implementation for the AIDL VHAL. The main service thread is implemented at VehicleService.cpp. The VHAL interface implementation is located at DefaultVehicleHal.cpp.

The reference implementation is based on a two-layer architecture. On the upper layer, DefaultVehicleHal, implements VHAL AIDL interface and provides VHAL logic generic to all hardware devices. On the lower layer, FakeVehicleHardware, implements the IVehicleHardware interface. This class simulates the VHAL logic of interacting with actual hardware or vehicle bus and is device-specific. Optionally, vendors can adapt this same architecture, reuse the same DefaultVehicleHal class (extending it to overwrite a method), and provide their own IVehicleHardware implementation.

DefaultVehicleHal contains the following logic, which is considered to be generic and can apply to any VHAL implementation.

• Implements the IVehicle interface.
• Performs basic input checks, including a check for duplicate IDs.
• Allocates client objects (for example, GetValuesClient) for each operation for each binder client, and adds each to a global pool.
• 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.
• Serializes and deserializes LargeParcelable (see ParcelableUtils.h).
• Manages subscription (see SubscriptionManager.h).
• Checks permissions. (See the checkReadPermission and checkWritePermission functions).
• Periodically calls IVehicleHardware.checkHealth and sends heartbeat signals (see the checkHealth function).

IVehicleHardware is a generic interface used to represent a VHAL’s hardware-specific implementation. The reference implementation for IVehicleHardware is FakeVehicleHardware, which uses an in-memory map to store property value and does not communicate with an actual vehicle bus. It's intended to run on an emulator and have no hardware-specific dependencies. Vendor implementations must not use it as-is and must add vehicle bus-specific logic.

Starting in Android 14, FakeVehicleHardware reads the supported property config at run-time during initialization from the device’s /vendor/etc/automotive/vhalconfig/ folder, which contains a JSON-style config file. See the reference VHAL README file for config file format and config file content.

FakeVehicleHardware also supports config file override for testing. If the system property persist.vendor.vhal_init_value_override is set (this property must be set at build time or very early during boot before VHAL initialization), it uses the config file from the /vendor/etc/automotive/vhaloverride/ folder on the device to override the existing configuration. A vendor implementation can use a similar approach so that the VHAL- supported property configuration is not hard-coded and can be dynamically decided at start time. The list of vehicle property configs must be static after VHAL is initialized.

Starting in Android 16, GRPCVehicleHardware provides another reference IVehicleHardware implementation. This implementation assumes there is a separate server running on a remote machine or VM which contains the property handling logic. The VHAL running on AAOS devices acts as a proxy that forwards requests to the remote server. See grpc for more details.