serp vhal

serp-vhal

serp-vhal — a SERP-generated VHAL (Vehicle Hardware Abstraction Layer) for Android Automotive OS (AAOS).

The project bridges SERP vehicle services to the AAOS AIDL VHAL interface. A generated VehicleHardwareAdapter translates SERP Property::connect() callbacks into AIDL onPropertyEvent calls that CarService consumes. Service interfaces, the adapter, and the process entry point are generated from SerpIDL specs. Domain logic lives in src/ and is never overwritten by the generator.

---

Why SERP for a VHAL

Property<T> is the VHAL property model serp::Property<T> with connect() and mutate() maps directly onto VHAL semantics: hardware or sensor code calls mutate() from any thread; SERP dispatches the write safely to the owner service's event loop and notifies all subscribers. The generated adapter wires those subscribers to CarService's onPropertyEvent. This infrastructure is native to SERP — in a hand-written VHAL it has to be built per-property.

Domain services instead of one monolithic class Vehicle domains (chassis, HVAC, driving, body…) become independent SERP services each with their own event loop thread. Domains don't share mutable state and don't compete for locks. More importantly: the decomposition is in the spec. Adding a domain, moving a property between services, or splitting a service is a spec edit followed by serpgen generate — the adapter, dispatch tables, and property config list all update automatically.

Generated dispatch tables and property configs getValues, setValues, subscribe, and getAllPropertyConfigs are generated from the same specs that define the services. They are always in sync with the actual properties. Adding a property means editing the spec, not hunting through switch statements.

Typed inter-service communication If one vehicle domain needs data from another — VehicleHvac reading engine state, for example — it uses a generated SERP Method: typed, thread-safe, and backed by whatever transport the deployment uses. No shared globals, no hand-rolled IPC.

Clear generated / hand-written boundary gen/ is regenerated freely; src/ is never touched by the generator. The structural separation is enforced by the toolchain, not by convention. There is no ambiguity about what is infrastructure and what is business logic.

Runtime inspection of a live VHAL The SERP runtime lets you call service methods and read property values on a running VHAL process via gRPC or the command line — without rebuilding or adding debug code. If CarService is not seeing an expected value, you can inspect the service state directly.

---

Architecture

SERP vehicle services
  │  Property::mutate() / connect()
  ▼
VehicleHardwareAdapter   (generated SERP ↔ AIDL bridge)
  │  onPropertyChangeEvent
  ▼
SerpVehicleService       (AIDL BnVehicle)
  │  Binder IPC
  ▼
CarService (AAOS)
  │  CarPropertyManager / CarHvacManager
  ▼
AAOS system apps

---

Deployment

# Build (requires SERP AAOS SDK and Android NDK)
SERP_AAOS_SDK=/path/to/sdk ./scripts/build.sh --android

# Push to connected AAOS emulator / device (requires adb root)
./scripts/push.sh

# Tail VHAL logcat
./scripts/run.sh --android

scripts/push.sh remounts /vendor, pushes the binary and init.rc, restarts the android.hardware.automotive.vehicle service, and sets up port forwarding for the SERP runtime.

---

Project Layout

Path	Contents
specs/serp.sidl	Workspace root
specs/services/	Service interface and service specs
specs/deployments/	AAOS deployment specs
src/services/	Domain logic (hand-written, survives regeneration)
build/gen/aaos/	Generated AAOS adapter and AIDL bridge
scripts/	Build, push, run, stop helpers

---

Prerequisites

• serp — SERP framework, generator, and AAOS SDK
• Android NDK r27+
• AAOS emulator or device with root access

---

Related Pages

• Deployment Configurations — AAOS as a deployment target
• Generator Overview — how serpgen produces the AAOS adapter
• Properties — serp::Property<T>, connect(), mutate()
• serp-mini-ivi — full IVI platform demonstration