AOSP & AAOS on Raspberry Pi¶
This section follows a practical path from an Android 16 source checkout to a Raspberry Pi image, then explains the AOSP layers that make the image work. It is for experimentation and platform development, not for controlling a vehicle.
Use a dedicated test device
The car product is an Android Automotive OS (AAOS) development image. It is useful for learning the automotive stack on a Raspberry Pi, but it is not a certified in-vehicle system and must not be connected to vehicle control, safety, or diagnostic networks.
Choose your route¶
| Goal | Start here | You will learn |
|---|---|---|
| Build an Android 16 image for Pi 4 or Pi 5 | Build AOSP Android 16 | repo, local manifests, product selection, images, and safe media writing |
| Run the automotive product | Run AAOS on Raspberry Pi | aosp_rpi*_car targets, first boot, logs, and the boundaries of a demo system |
| Understand platform internals | AOSP Architecture Explained | Apps, System Server, Binder, ART, HALs, vendor partitions, and the kernel |
| Explore components visually | Android Architecture Map | Relationships among framework, native, HAL, and automotive components |
What the Raspberry Pi manifest provides¶
The Raspberry Vanilla Android 16 local manifest supplies Raspberry Pi-specific configuration for Android 16 on Raspberry Pi 4 and Raspberry Pi 5. Its documented products cover the standard tablet UI, Android TV, and Android Automotive (car) variants.
The project pins an Android branch and device configuration at a point in time. Before a large download or a new build, read its current README and issue tracker, record the commit you use, and keep your host build tree separate from personal files.
Learning order¶
- Build the tablet target once to validate the host, storage image, display, USB input, and log collection.
- Build the
cartarget and treat it as a UI/platform development target. - Trace one feature end to end: app → framework API → Binder/AIDL → system service → HAL → kernel driver.
- Only then change a device, vendor, framework, or car-service component—and preserve a known-good image before each experiment.