Skip to content

Run Android Automotive OS on Raspberry Pi

Android Automotive OS (AAOS) is Android running directly on in-vehicle hardware; it is different from Android Auto, which runs on a phone and projects its interface to a vehicle display. On a Raspberry Pi, the AAOS car product is a useful development and learning environment for the Android automotive stack.

Development image only

Do not connect a Raspberry Pi AAOS experiment to a real vehicle's CAN bus, OBD port, safety systems, or driving controls. This guide covers a standalone display-and-input development setup only.

Choose the car product

After completing the source setup, select the board-specific car target.

1
2
3
4
5
6
7
8
9
. build/envsetup.sh

# Raspberry Pi 4
lunch aosp_rpi4_car-bp4a-userdebug

# Raspberry Pi 5
lunch aosp_rpi5_car-bp4a-userdebug

make bootimage systemimage vendorimage -j"$(nproc)"

Build the matching flashable image with the manifest project's rpi4-mkimg.sh or rpi5-mkimg.sh. The full source and media-writing workflow is in Build AOSP Android 16 for Raspberry Pi.

What AAOS adds to AOSP

AAOS shares the Android codebase and core platform with other Android products, then adds automotive APIs, system services, UI, and hardware abstractions. In a production vehicle, the Vehicle HAL (VHAL) represents vehicle properties for approved framework and system components. A Raspberry Pi test build lets you study those software boundaries without treating the board as vehicle hardware.

Term Role in an AAOS test build
Android Automotive OS Android platform that runs directly on the target hardware
Android Auto Phone-based projection platform; not the car system image
Car Service and Car API Automotive framework services and APIs used by suitably privileged components
Vehicle HAL (VHAL) Hardware abstraction boundary for vehicle properties in an actual integration
userdebug Development build variant with debugging support; not a production deployment profile

First boot checklist

  1. Use the exact board image that you built.
  2. Attach a known-good power supply, display, and USB keyboard before first power-on.
  3. Record the first successful boot time and the visible build identifier.
  4. Enable and use ADB only on an isolated development network.
  5. Keep a serial-console or physical recovery path available before changing framework or vendor code.

When a shell is available, begin with evidence rather than modifications:

1
2
3
4
getprop ro.build.fingerprint
getprop ro.build.version.release_or_codename
adb shell dumpsys car_service
adb shell logcat -b all -d | tail -n 300

Run adb from the host; omit the adb shell prefix if you are already at the device shell. dumpsys output differs between revisions and product configurations, so save it alongside the source revision rather than comparing only screenshots.

Safe experiments

Experiment Observe Keep out of scope
UI and input display composition, rotary/keyboard behavior, system UI logs driver-distraction policy claims for a real vehicle
Car service service availability, permissions, Binder errors exposing privileged APIs to ordinary apps
VHAL study interfaces, property model, service logs physical vehicle signals or control commands
Performance cold boot, CPU temperature, memory, frame timing publishing a result without board, cooling, power, and image revision

Troubleshooting order

  1. Verify the Pi model, selected lunch target, and generated image name match.
  2. Capture display state and serial or kernel logs before changing the image.
  3. Verify USB input and network separately; a UI failure is not necessarily a networking failure.
  4. For service issues, capture the relevant dumpsys and logcat output with the build fingerprint.
  5. Return to the known-good image before testing the next code change.