Introduction: Unlocking Granular Control in AAOS for ADAS

Android Automotive OS (AAOS) has emerged as the dominant platform for in-vehicle infotainment systems, but its capabilities extend far beyond media playback and navigation. At its core, AAOS provides a powerful framework for interacting with vehicle hardware through a standardized set of APIs and services. For developers aiming to implement advanced driver-assistance systems (ADAS), understanding and manipulating AAOS Vehicle Properties is paramount. This article delves into how to access, modify, and even create custom vehicle properties, empowering you to develop sophisticated and deeply integrated ADAS features.

Traditional ADAS development often relies on proprietary ECUs and vendor-specific APIs. AAOS offers a compelling alternative by providing a unified software stack. By leveraging Vehicle Properties, developers can gain granular control over vehicle sensors, actuators, and status information, opening doors for custom adaptive cruise control, lane-keeping assist, blind-spot detection, and more, all integrated seamlessly within the Android ecosystem.

Understanding AAOS Vehicle Properties and the VHAL

At the heart of AAOS’s interaction with vehicle hardware lies the Vehicle Hardware Abstraction Layer (VHAL). The VHAL defines a standardized interface between the Android framework and the underlying vehicle hardware, abstracting away the complexities of different vehicle manufacturers’ ECUs and bus systems (like CAN). Vehicle Properties are specific data points or control parameters exposed by the VHAL.

Each Vehicle Property is identified by a unique integer ID and has a defined data type (e.g., INT32, FLOAT, BYTE_ARRAY) and access permissions (read-only, write-only, read-write). Properties can be global (applying to the entire vehicle) or zoned (applying to specific areas like a door, seat, or display). Examples include vehicle speed, gear selection, turn signal status, fuel level, and even custom vendor-defined properties.

The Role of VHAL in ADAS

For ADAS, VHAL properties are the primary conduits for:

• Sensor Data Acquisition: Reading real-time data from vehicle sensors (e.g., wheel speed, steering angle, braking pressure, ambient light).
• Actuator Control: Sending commands to vehicle actuators (e.g., controlling a braking system for emergency braking, adjusting steering for lane keeping).
• Vehicle State Monitoring: Understanding the current operational state of the vehicle (e.g., whether the engine is on, doors are open, seatbelts fastened).

Accessing Vehicle Properties in AAOS

The primary way to interact with Vehicle Properties from an Android application is through the `CarPropertyManager` service. This service provides a higher-level abstraction over the VHAL, making it easier for apps to read and write properties.

Using CarPropertyManager (Java/Kotlin)

First, obtain an instance of `CarPropertyManager`:

import android.car.Car;import android.car.hardware.property.CarPropertyManager;import android.car.hardware.CarPropertyValue;...Car car = Car.createCar(context);CarPropertyManager carPropertyManager = (CarPropertyManager) car.getCarManager(Car.PROPERTY_SERVICE);

To read a property, such as vehicle speed:

if (carPropertyManager != null) {    CarPropertyValue<Float> speedProperty = carPropertyManager.getProperty(CarPropertyManager.VEHICLE_SPEED, 0);    if (speedProperty != null) {        float speed = speedProperty.getValue();        Log.d("ADAS_APP", "Current Speed: " + speed + " km/h");    } else {        Log.e("ADAS_APP", "Failed to get VEHICLE_SPEED property.");    }}

The second argument, `0`, represents the area ID. For global properties, it’s typically 0. For zoned properties (like specific door locks), you’d specify the relevant area ID.

Listing All Available Properties (Shell)

To explore existing properties on an AAOS device, you can use `adb shell`:

adb shell dumpsys activity service android.car.CarService

This command outputs a wealth of information about the `CarService`, including a list of all registered `CarPropertyManager` properties, their IDs, types, and permissions.

Modifying Vehicle Properties for Custom ADAS

Modifying vehicle properties is where custom ADAS development gains traction. This typically requires system-level permissions and often involves building a system application or having root access to the device.

Required Permissions

For sensitive operations, your app needs specific permissions declared in its `AndroidManifest.xml` and granted at runtime. For example, to control vehicle power or manipulate certain ADAS-related functions, you might need:

<uses-permission android:name="android.car.permission.CAR_CONTROL_VEHICLE_POWER" /><uses-permission android:name="android.car.permission.CAR_CONTROL_EXTERIOR_LIGHTS" /><uses-permission android:name="android.car.permission.CAR_READ_PROPERTY" /><uses-permission android:name="android.car.permission.CAR_WRITE_PROPERTY" />

Many critical ADAS properties are guarded by `signature|privileged` permissions, meaning only applications signed with the platform key or installed in the `/system/priv-app` directory can acquire them.

Setting a Vehicle Property

Assuming you have the necessary permissions, setting a property is straightforward. For instance, imagine a custom ADAS feature that adjusts headlight brightness based on external conditions, requiring control over `EXTERIOR_LIGHTS_STATE` (though this property might be read-only in real vehicles for safety, we use it as an example for demonstration):

import static android.car.hardware.property.CarPropertyManager.CAR_SET_PROPERTY_ERROR;import static android.car.hardware.property.CarPropertyManager.CAR_SET_PROPERTY_SUCCESS;...int newLightState = 1; // Example: Turn on low beamsint result = carPropertyManager.setIntProperty(CarPropertyManager.EXTERIOR_LIGHTS_STATE, 0, newLightState);if (result == CAR_SET_PROPERTY_SUCCESS) {    Log.d("ADAS_APP", "Exterior lights state set successfully.");} else if (result == CAR_SET_PROPERTY_ERROR) {    Log.e("ADAS_APP", "Failed to set exterior lights state.");}

For ADAS features, you might set properties related to steering torque requests (if available and permissible), braking commands, or even custom feedback to the driver display.

Creating Custom Vehicle Properties for Advanced ADAS

For truly novel ADAS functionalities, existing VHAL properties might not suffice. This is where defining custom properties becomes essential. This process requires modifying the AOSP source code and recompiling the AAOS image, as it involves extending the VHAL definition itself.

Defining New Properties in VHAL

Custom properties are typically defined in the `hardware/interfaces/automotive/vehicle/V2_0/types.hal` file (or its AIDL equivalent in newer versions of Android). You’d add a new entry to the `VehicleProperty` enum:

// In hardware/interfaces/automotive/vehicle/V2_0/types.hal or similarinterface IVehicle {    ...    /**     * Custom property for Lane Keeping Assist (LKA) status.     * 0: Inactive, 1: Active, 2: Warning, 3: Intervention.     */    LKA_STATUS = 0x21100100; // Vendor property range (0x21000000 - 0x210000FF)    /**     * Custom property for Pre-Collision Warning (PCW) sensitivity.     * Range: 0 (Low) - 100 (High).     */    PCW_SENSITIVITY = 0x21100101;    ...}

Note the property IDs: custom vendor properties typically start within the range `0x21000000` to `0x2100FFFF`. These IDs ensure they don’t conflict with standard AOSP properties.

Next, you define the property’s metadata in the VHAL implementation, usually in `hardware/interfaces/automotive/vehicle/V2_0/default/impl/VehicleHal.cpp` or a custom VHAL module. This involves specifying its type, permissions, and other characteristics:

// In VehicleHal.cpp or your custom VHAL implementationaddProperty(VehiclePropertyStore.Builder(VehicleProperty.LKA_STATUS)        .setType(VehiclePropertyType.INT32)        .setChangeMode(VehiclePropertyChangeMode.ON_CHANGE)        .setAccess(VehiclePropertyAccess.READ_WRITE)        .addArea(VehicleArea.GLOBAL)        .build());addProperty(VehiclePropertyStore.Builder(VehicleProperty.PCW_SENSITIVITY)        .setType(VehiclePropertyType.INT32)        .setChangeMode(VehiclePropertyChangeMode.ON_CHANGE)        .setAccess(VehiclePropertyAccess.READ_WRITE)        .setMinValue(0).setMaxValue(100)        .addArea(VehicleArea.GLOBAL)        .build());

After recompiling and flashing the AAOS image, these new properties become available through `CarPropertyManager`, just like standard properties, using their defined integer IDs.

Integrating with Custom ADAS Modules

With custom properties defined, your ADAS application or service can now read and write these values. For instance, an external ADAS control unit could write `LKA_STATUS` to indicate its operational state, and your Android application could read it to display driver feedback or adjust UI elements.

// In your custom ADAS service/appprivate static final int CUSTOM_LKA_STATUS = 0x21100100;private static final int CUSTOM_PCW_SENSITIVITY = 0x21100101;...// Reading LKA statusCarPropertyValue<Integer> lkaStatus = carPropertyManager.getProperty(CUSTOM_LKA_STATUS, 0);if (lkaStatus != null) {    int status = lkaStatus.getValue();    // Update UI based on LKA status}...// Setting PCW sensitivity (e.g., from a user setting)int newSensitivity = 75; // User selects 'Medium-High'carPropertyManager.setIntProperty(CUSTOM_PCW_SENSITIVITY, 0, newSensitivity);

This two-way communication allows for sophisticated interactions, where ADAS algorithms running on dedicated hardware can feed data into AAOS, and AAOS applications can provide user input or high-level commands back to the ADAS system.

Security and Safety Considerations

Manipulating vehicle properties directly carries significant safety and security implications. Incorrect modifications can lead to unpredictable vehicle behavior, compromise safety systems, or even create security vulnerabilities.

• Strict Permissions: Always adhere to the principle of least privilege. Request only the necessary permissions.
• Validation and Error Handling: Implement robust error checking and input validation for all property writes.
• Testing: Thoroughly test any custom ADAS implementation in a controlled environment, ideally with hardware-in-the-loop (HIL) or vehicle-in-the-loop (VIL) simulations, before deploying to a real vehicle.
• Over-the-Air Updates (OTA): Plan for how your custom VHAL extensions and ADAS applications will be updated and maintained securely.

Conclusion

Hacking AAOS Vehicle Properties provides an unprecedented level of control and flexibility for developing custom ADAS features. By understanding the VHAL, utilizing `CarPropertyManager`, and even extending the property set with custom definitions, developers can move beyond standard infotainment functionalities and create deeply integrated, innovative driver-assistance systems. While the process of defining custom VHAL properties requires deep dives into AOSP and recompilation, the reward is a truly bespoke and powerful automotive experience. Always prioritize safety and rigorous testing when venturing into these advanced realms of vehicle control.