Skip to the content.

Pixel support dropped from Android 16: what it means for the AOSP developer community

2025-07: Chris Simmonds

Dropping Pixel support from Android 16 was a surprise. While the AOSP code base is still sufficient to build devices for new hardware, even without support from Google, it makes it harder because there is less reference code to show how the lower layers of the operating system are intended to work. Call to action: we can fill the gap by sharing the device knowledge that we have. That is exactly what we at aosp-devs.org are here for

A quiet change in the device/google/ directory

AOSP includes configurations for a range of hardware and emulated targets - you can find them in the device/ directory, with subdirectories organized by manufacturer. Device configuration in this context refers to the configuration files, build scripts, kernel sources and binary blobs that you need to compile and flash a working build. Up to Android 16 device/google contained configuration for the Nexus and Pixel devices that are currently in their support window. But in Android 16, device/google contains only configurations based on the Cuttlefish emulator.

Google confirmed that the omission is intentional. Bill Ye posted the following on the Android Building mail list

“We remain committed to AOSP updates. You continue to have the option to build Cuttlefish and GSI targets from the sources for experimentation.”

Separately, Seang Chau posted this on X:

“We’re seeing some speculation that AOSP is being discontinued. To be clear, AOSP is NOT going away. AOSP was built on the foundation of being an open platform for device implementations, SoC vendors, and instruction set architectures. AOSP needs a reference target that is flexible, configurable, and affordable – independent of any particular hardware, including those from Google. For years, developers have been building Cuttlefish (available on GitHub as the reference device for AOSP) and GSI targets from source. We continue to make those available for testing and development purposes.”

What’s left in AOSP 16?

Despite the purge, AOSP still ships several buildable reference devices:

Device family Purpose Location in tree
Cuttlefish The Android platform emulator and Google’s canonical reference for all hardware work device/google/cuttlefish
Trout Cuttlefish‑based emulator tailored for Android Automotive OS device/google/trout
Goldfish The classic Android Emulator, used by Android Studio device/generic/goldfish
DragonBoard 845c / RB5 / HiKey960 Dev boards supported by Linaro device/linaro
Khadas VIM3 / VIM3L Dev boards supported by BayLibre device/amlogic/yukawa

Why losing Pixel device configuration hurts

Cuttlefish as reference platform

Cuttlefish is the main reference platform from now on, which is fine for most of the code but it becomes more restricted the closer you get to the hardware. Sure, there are emulation layers for most subsystems, and reasonably good support for secure boot, but there is always a point when emulation fails to match reality. Having the Pixel device configurations available was nice because it gave us several examples to work from, each with different characteristics and HALs. Furthermore, the Cuttlefish device configuration has a lot of Cuttlefish specifics which muddy the waters somewhat

Reading the tea leaves: cost cutting and a narrower funnel

Google hasn’t said the move is about money, but AOSP maintenance is undeniably a cost center - it generates no direct revenue. Combined with last quarter’s decision to make aosp‑main read‑only and do active development on a private branch, the message is clear: Google wants to spend fewer engineering hours on public infrastructure and more on shipping Android for its own products.

This is not a sign that Android will turn closed‑source. Google explicitly reiterated that “AOSP is not going away”, and the Apache 2.0 licence isn’t changing. But it is another step back from the “AOSP first” philosophy.

Where do we go from here? - A call to action

Android has always grown through collaboration. Google’s retreat makes that collaboration harder, but also more necessary than ever. The future of open Android now depends less on Mountain View and more on us.