AOSP isn’t dead, but Google just landed a huge blow to custom ROM developers

Earlier this year, Google announced it would develop the Android OS fully in private to simplify its development process. By focusing its efforts on a single internal branch, Google aimed to streamline work that was previously split. The news initially spooked some in the Android development community, but the controversy quickly subsided. The impact was minimal, as Google was already developing most of Android behind closed doors and promised that source code releases would continue. Now, however, a recent omission from Google has rekindled fears that the company might stop sharing source code for new Android releases, though Google has stated these concerns are unfounded.

As promised, Google published the source code for Android 16 this week, allowing independent developers to compile their own builds of the new operating system. This source code was uploaded to the Android Open Source Project (AOSP), as usual, under the permissive Apache 2.0 license.

However, multiple developers quickly noticed a glaring omission from the Android 16 source code release: the device trees for Pixel devices were missing. Google also failed to upload new driver binaries for each Pixel device and released the kernel source code with a squashed commit history. Since Google has shared the device trees, driver binaries, and full kernel source code commit history for years, its omission in this week’s release was concerning.

These omissions led some to speculate this week that Google was taking the first step in a plan to discontinue AOSP. In response, Google’s VP and GM of Android Platform, Seang Chau, refuted these claims. In a post on X, he addressed the speculation, stating that “AOSP is NOT going away.”

He also confirmed the omission of Pixel device trees is intentional, stating that “AOSP needs a reference target that is flexible, configurable, and affordable — independent of any particular hardware, including those from Google.” Instead of supporting AOSP builds on Pixel devices, Google will support the virtual Android device “Cuttlefish” as its reference target. Cuttlefish runs on PCs, allowing Google and platform developers to test new hardware features. Google will also continue to support GSI targets, which are generic system images that can be installed on nearly any Android device.

On one hand, this logic is sound. Google wants to move away from using Pixels as the AOSP reference device and is making changes to that effect. As Seang Chau notes, “AOSP was built on the foundation of being an open platform for device implementations, SoC vendors, and instruction set architectures.” In that regard, Cuttlefish is a more appropriate reference target because it isn’t a heavily customized piece of consumer hardware like a Pixel phone. However, since Cuttlefish is a virtual device, it can only simulate how hardware features behave, making it an imperfect reference in some ways.

The more significant issue, however, is the impact this decision will have on developers who build custom ROMs — the community term for hobbyist forks of AOSP. Nolen Johnson, a long-time contributor and reviewer for the LineageOS project, says the process of building these ROMs for Pixel phones will become “painful” moving forward.

Previously, Google made it simple for developers to build AOSP for Pixel devices, but that support is now gone. Developers simply had to “pull the configurations [that] Google created,” add their customizations, and then build. Now, however, they will need to take the old device trees that Google released for Android 15 and “blindly guess and reverse engineer from the prebuilt [binaries] what changes are needed each month.”

This is because making a full Android build for a device — not just a GSI — requires a device tree. This is a “collection of configuration files that define the hardware layout, peripherals, proprietary file listings, and other details for a specific device, allowing the build system to build a proper image for that device.” While Google previously handled this work, developers must now create their own device trees without access to the necessary proprietary source code.

Furthermore, Google’s decision to squash the kernel source code’s commit history also hinders custom development. The Pixel’s kernel source code was often used as a “reference point for other devices to take features, bug fixes, and security patches from,” but with the history now reduced to a single commit, this is no longer feasible.

While Google is under no obligation to release device trees, provide driver binaries, or share the full kernel commit history (in fact, it’s one of the few device makers to do these things), it has done so for years. The company’s reason for doing so was because the Pixel was treated as a reference platform for AOSP, so developers needed an easy way to build for it. Google’s decision to now discontinue the Pixel as an AOSP reference device is unfortunate, as it has pulled the rug from under developers like the teams at LineageOS and GrapheneOS who build Android for Pixel devices. These developers will still be able to build AOSP for Pixel devices, but it will now be more difficult and painful to do so than before.