Car Service

The Role of CarService in AAOS

In Android Automotive OS (AAOS), CarService is the central nervous system. It acts as the intermediary between the hardware (via the Vehicle HAL) and the applications (via the Car API).

Unlike standard Android services like ActivityManagerService or WindowManagerService which run inside the system_server process, CarService runs in its own distinct process (com.android.car). This isolation is a deliberate architectural choice to ensure that automotive specific logic does not destabilize the core Android framework.

CarService Initialization

The boot sequence of CarService is critical, as the IVI system cannot function properly until it is running.

1. SystemServer Boots: Standard Android core services initialize.
2. CarServiceHelperService Starts: Running within system_server, this helper prepares the environment for CarService and binds to it.
3. CarService Process Starts: The OS launches the com.android.car application.
4. Service Binding: CarService binds to the Vehicle HAL (VHAL) to establish communication with the vehicle bus.
5. Manager Initialization: Internal managers (like CarPropertyService, CarAudioService, etc.) are initialized sequentially.

// Example conceptual flow of CarService initialization
public class ICarImpl extends ICar.Stub {
    private final CarPropertyService mCarPropertyService;
    private final CarPowerManagementService mCarPowerManagementService;

    public ICarImpl(Context serviceContext, IVehicle vehicle) {
        // Initialize core services bridging to VHAL
        mCarPropertyService = new CarPropertyService(serviceContext, vehicle);
        mCarPowerManagementService = new CarPowerManagementService(serviceContext, mCarPropertyService);
        
        // Initialize all managers
        mAllServices.add(mCarPropertyService);
        mAllServices.add(mCarPowerManagementService);
    }
}

The Car API and Core Managers

Applications interact with CarService using the Android Car API object. An app must first connect to the Car service before it can request specific managers.

// Connecting to the Car API from an application
Car car = Car.createCar(context);
CarPropertyManager propertyManager = (CarPropertyManager) car.getCarManager(Car.PROPERTY_SERVICE);

Key Managers

• CarPropertyManager: Provides read and write access to vehicle properties (e.g., speed, gear, HVAC temperature).
• CarAudioManager: Handles complex audio routing, volume grouping, and audio ducking specific to automotive cabin environments.
• CarPowerManager: Allows apps to listen for specific vehicle power states (like preparing for shutdown) and defer operations.
• CarUxRestrictionsManager: Broadcasts the current driving state to enforce user distraction guidelines, disabling complex UI elements while the vehicle is in motion.

OEM Service Extension (CarServiceBase)

While AOSP provides a robust CarService, Original Equipment Manufacturers (OEMs) frequently need to implement custom, proprietary logic that is not part of the open source release. Modifying the AOSP CarService directly creates significant maintenance overhead during OS upgrades.

To solve this, OEMs utilize the extensibility points within CarService. You can create custom services by implementing the CarServiceBase interface.

// Example of a custom OEM Car Service
public class OemCustomDiagnosticService implements CarServiceBase {
    
    private final Context mContext;
    private final CarPropertyService mPropertyService;

    public OemCustomDiagnosticService(Context context, CarPropertyService propService) {
        mContext = context;
        mPropertyService = propService;
    }

    @Override
    public void init() {
        // Initialization logic, register listeners
    }

    @Override
    public void release() {
        // Cleanup resources
    }

    @Override
    public void dump(PrintWriter writer) {
        // Output state for dumpsys
        writer.println("OemCustomDiagnosticService state: OK");
    }
}

These custom services are then registered within the ICarImpl (often requiring an OEM specific overlay or patch to the CarService repository, though architectural patterns exist to inject them dynamically).

By thoroughly understanding CarService, engineers can build robust automotive applications that react cleanly to vehicle hardware states and build maintainable OEM platform extensions.