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,
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
contains the following logic, which is considered to be generic and can apply to any VHAL
- Implements the
- 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
- Manages subscription (see
- Checks permissions. (See the
- Periodically calls IVehicleHardware.checkHealth and sends heartbeat signals (see the
is a generic interface used to represent a VHAL’s hardware-specific
implementation. The reference implementation for
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.
In Android 14,
FakeVehicleHardware reads the supported property config at run-time
during initialization from the device’s
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
persist.vendor.vhal_init_value_override is set, 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 vehicle property config must be static once the device is started.