If you’re getting started with Android Automotive OS (AAOS), you’ll quickly run into something called Car Service in AOSP. It’s one of those essential components that makes Android work inside a car — not on your phone, but actually on the car’s infotainment system.
In this guide, we’ll break down Car Service in AOSP step-by-step, explain how it works, what it does, and walk through code examples so you can understand and start building with confidence.
What Is Car Service in AOSP?
In the world of Android Open Source Project (AOSP), Car Service is a system service designed specifically for the automotive version of Android. It’s what bridges the gap between car hardware (like sensors, HVAC, speed, fuel level) and Android apps or services that need that data.
Think of it as the middleman that manages and exposes car hardware features to Android applications safely and consistently.
Why Is Car Service Important in Android Automotive?
- Access to Vehicle Data: It lets apps access data like speed, gear, HVAC status, fuel level, etc.
- Security: Only authorized components can access sensitive vehicle data.
- Abstraction: It hides the car’s hardware complexity behind clean Android APIs.
- Interoperability: Developers can build apps that work across different car manufacturers.
Core Components of Car Service in AOSP
Let’s simplify the architecture. Here’s how the system flows:
Car Hardware Abstraction Layer (HAL)
↓
Car Service (System)
↓
Car APIs / CarApp Library
↓
Third-party or System Apps
1. Car HAL (Hardware Abstraction Layer)
This is the lowest layer. It connects directly to the car’s ECU and other hardware via vendor-specific code.
2. Car Service
This lives in packages/services/Car
in AOSP. It reads from the HAL and exposes data to the rest of Android using APIs.
3. Car APIs
Available via android.car
namespace. Developers use these in their apps to access vehicle data in a clean, safe way.
Where Is Car Service Code in AOSP?
You’ll find the Car Service source code here:
/packages/services/Car/
Key files:
CarService.java
– The main system service.CarPropertyService.java
– Handles access to vehicle properties.VehicleHal.java
– Bridges to the HAL.VehicleStubHal.java
– A fake HAL used for emulators and testing.
Let’s Look at Code: How Car Service Works
Here’s a super simplified example from CarService.java
:
public class CarService extends Service {
@Override
public void onCreate() {
super.onCreate();
Log.i(TAG, "CarService started");
// Initialize vehicle property manager
mCarPropertyService = new CarPropertyService();
mCarPropertyService.init();
// Register the service to ServiceManager
ServiceManager.addService("car_service", this);
}
}
Here,
- The system starts
CarService
during boot. - It initializes
CarPropertyService
which talks to the HAL. - It registers itself to
ServiceManager
so apps can bind to it.
This is what makes vehicle data accessible through Android’s Car APIs.
Permissions and Security
Accessing vehicle data isn’t open to everyone — and that’s a good thing.
You’ll need permissions like:
<uses-permission android:name="android.car.permission.CAR_SPEED"/>
<uses-permission android:name="android.car.permission.CAR_ENGINE"/>
And apps must be system-signed or granted via whitelist in car_service.xml
.
Accessing Vehicle Data from an App
Here’s how a developer might access the vehicle speed:
Car car = Car.createCar(context);
CarPropertyManager propertyManager = (CarPropertyManager) car.getCarManager(Car.PROPERTY_SERVICE);
float speed = (Float) propertyManager.getProperty(
VehiclePropertyIds.PERF_VEHICLE_SPEED, 0);
Here,
- Connect to the Car service.
- Get the CarPropertyManager.
- Read the vehicle speed using a property ID.
Testing Car Service Without a Real Car
Don’t have an actual car ECU to test with? Use the VehicleStubHal!
In VehicleStubHal.java
, you can simulate data:
@Override
public void getProperty(...) {
if (propertyId == VehiclePropertyIds.PERF_VEHICLE_SPEED) {
return new VehiclePropValue(..., 42.0f); // Fake speed
}
}
Perfect for development and debugging on emulators.
Customizing Car Service for Your OEM
If you’re building a custom ROM for a car, you’ll likely need to:
- Implement your own Car HAL in
hardware/interfaces/automotive/vehicle
. - Customize Car Service components in
/packages/services/Car/
. - Define new vehicle properties if needed.
Make sure you align with VHAL (Vehicle HAL) AIDL interface definitions.
Summary: Key Takeaways
- Car Service in AOSP is the system layer that gives Android Automotive access to vehicle hardware.
- It abstracts complex car hardware into simple APIs.
- Apps use the
android.car
APIs to safely read and respond to vehicle state. - Testing is possible with stub HALs — no real car needed!
- It’s secure, modular, and extensible.