Skip to content

Build AOSP Android 16 for Raspberry Pi 4 and Pi 5

Use the Raspberry Vanilla Android 16 local manifest to add Raspberry Pi device projects to an AOSP checkout. The manifest currently documents Pi 4 and Pi 5 products for a standard Android UI, Android TV, and Android Automotive OS (AAOS).

Quick answer

Create a dedicated Ubuntu 22.04 build host, initialize the exact Android branch stated by the manifest, add its local manifest, sync the sources, select an aosp_rpi4 or aosp_rpi5 product, build the required images, and write the generated image only after verifying the target device name.

Before downloading source

Item Why it matters
Dedicated Linux build host AOSP downloads and intermediates are large; do not use a system volume that contains irreplaceable data.
Raspberry Pi 4 or Pi 5 The documented products are board-specific. Do not flash a Pi 4 image to a Pi 5 or the reverse.
Reliable power and display/input Required for first-boot validation and recovery.
Spare microSD, USB SSD, or NVMe target Keep the known-good Raspberry Pi OS storage untouched.
Serial console or physical access Essential if graphics, USB, or networking fail early in boot.

Follow the current AOSP build requirements as well as the manifest README. Tool and package requirements can change with the Android branch.

Initialize the source tree

The commands below reproduce the Android 16 branch and manifest URL documented by Raspberry Vanilla at the time this guide was written. Run them in a new workspace; they create and download a large source tree.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
mkdir -p ~/src/aosp-rpi-android-16
cd ~/src/aosp-rpi-android-16

repo init -u https://android.googlesource.com/platform/manifest \
  -b android-16.0.0_r4

curl -fL \
  -o .repo/local_manifests/manifest_brcm_rpi.xml \
  https://raw.githubusercontent.com/raspberry-vanilla/android_local_manifest/android-16.0/manifest_brcm_rpi.xml

repo sync

For a smaller initial clone, the upstream README also documents --depth=1 and a remove_projects.xml local manifest. Shallow history reduces download size, but can make later history inspection and branch changes less convenient.

Select the right product

Load the build environment, then choose one target. userdebug is appropriate for development because it provides debugging facilities; it is not a production security configuration.

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

# Raspberry Pi 4 examples
lunch aosp_rpi4-bp4a-userdebug
lunch aosp_rpi4_tv-bp4a-userdebug
lunch aosp_rpi4_car-bp4a-userdebug

# Raspberry Pi 5 examples
lunch aosp_rpi5-bp4a-userdebug
lunch aosp_rpi5_tv-bp4a-userdebug
lunch aosp_rpi5_car-bp4a-userdebug

Use exactly one lunch command per shell. Confirm the product printed by the build environment before compiling.

Build and create an image

1
2
3
4
5
6
make bootimage systemimage vendorimage -j"$(nproc)"

# Pick the script that matches the selected board.
./rpi4-mkimg.sh
# or
./rpi5-mkimg.sh

The manifest project determines the exact output paths and image layout. Inspect the script and generated filenames before writing anything. Never infer a block-device path from an example.

Write and validate safely

  1. Disconnect any storage device that is not the intended test medium.
  2. Identify the medium by model, size, and serial number—not only /dev/sdX ordering.
  3. Write the generated image using a tool that shows the target clearly.
  4. Reinsert the medium and confirm the expected partitions are present.
  5. Boot with a display and USB keyboard attached for the first run.
  6. Collect the build branch, manifest commit, image checksum, board model, power supply, display, and boot result in a lab note.

Common first-build failures

Symptom First evidence to collect Avoid
repo sync fails branch name, failing project, disk space, proxy settings deleting .repo before identifying the failing project
build stops early exact error, host OS release, Java/toolchain version, free space rerunning with more jobs until memory exhaustion
wrong display or no UI selected product, Pi model, display path, serial logs assuming the tablet, TV, and car images configure graphics identically
image does not boot generated image name, board target, partitions, power, serial output repeatedly reflashing without preserving the first log

Next steps