Google is complicating the development of alternative Android ROMs, calling into question their very existence. Starting with Android 16, the company stopped publicly sharing data that enabled the creation of these forks.
They are clearly no longer as popular as they were in the early days of Android, but alternative ROMs are still part of the identity of the mobile operating system. However, their development is likely to become significantly more complicated, which could eventually lead to their disappearance. Is Google nailing the coffin on alternative Android distributions like LineageOS and GrapheneOS? Here's an update.
Concerns began to grow in March 2025. Google announced that Android development would now be done 100% in-house to streamline workflows. In reality, this decision doesn't change much, since a large portion of development was already taking place privately. In addition, the company promised to continue publishing the source code and contributing to the Android Open Source Project (AOSP), the public and publicly available version of Android.
Android 16 Shuffles the Deck
But enthusiasts got a nasty surprise with the recent release of the first stable version of Android 16. Google did make the source code for the update available via AOSP. As usual, it's released under Apache 2.0, a permissive license that allows its use, distribution, modification, and the distribution of modified versions, allowing the creation of new custom ROMs from the provided base.
However, there are a few things missing from what Google used to provide. Pixel device trees are no longer available, as are driver binaries and commit history. The disappearance of these three types of data reflects Google's increasingly opaque transparency in Android development. And above all, it seriously complicates the task of developers who want to develop Android forks.
This revelation has led some to believe that Google is taking the first step towards completely eliminating AOSP. While it may not be as useful as it once was, its closure would still be a shock. It would symbolize Android's withdrawal, making it much closer to iOS than to the Android of the early years. In truth, Google has taken multiple directions over the years, making its OS less open and customizable. Killing AOSP would just be the final blow.
AOSP is not in question, according to Google
But we are not there yet. Having heard of the general panic spreading through the developer community, Seang Chau, head of Android, wanted to be reassuring. “Some are speculating about the abandonment of AOSP. Let’s be clear: AOSP is not going away. AOSP was designed as an open platform for device implementations, SoC vendors, and instruction set architectures,” he responded on X (Twitter).
He also gave an explanation for the end of sharing Pixel device trees. “AOSP needs a flexible, configurable, and affordable reference target that is independent of any hardware, including Google’s,” he said. By no longer making Pixel tree structures public, Google wants to force creators of alternative distributions to no longer use its Pixel as a reference target.
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…
— Seang Chau (@seangchau) June 12, 2025
Seang Chau clarified that his teams will continue to make the Cuttlefish virtual Android device available for testing and development purposes. It is even becoming the new reference target, now that Pixel trees are becoming inaccessible to the public. “Cuttlefish is a configurable virtual Android device that can run both remotely (using third-party cloud offerings such as Google Cloud Engine) and locally (on x86 and ARM64 Linux machines),” Google states in AOSP.
Its goal is to free developers from a certain dependence on physical hardware to develop and validate code changes. “Reproduce the framework-based behavior of a real device with a focus on high fidelity by maintaining close alignment with the core framework,” Google writes on the AOSP page introducing Cuttlefish. It is added that there are many similarities between Android Emulator and Cuttlefish, but that the latter “guarantees complete fidelity to the Android framework”, whether it is pure AOSP or a previously customized version.
Alternative ROMs in danger?
Generic system images (GSI), pure Android implementations containing unmodified AOSP code, are also still supported by Google, we learned. Wanting to free oneself from a commercial and customized device like Pixel smartphones can be a good idea. But the alternative, a virtual machine, also has its limits. It can only simulate hardware features, which can make it difficult for developers to detect or fix bugs, or even develop a new feature.
And that's not the only factor that will complicate the development of Android forks. Quoted by Android Authority, LineageOS contributor Nolen Johnson believes that it will become a "pain" to create custom ROMs in the future. Until now, “it was enough to retrieve the configurations created by Google”, then add a layer of customization and compile everything to develop an Android fork for Pixel. This is no longer possible as of Android 16, since Google keeps the trees for itself.
It will therefore be necessary to base ourselves on the old device trees published by Google (those for Android 15 being the most recent), to then “blindly guess and reverse engineer, from the pre-compiled binaries, the necessary modifications”, explains the developer. This set of configuration files is critical, because it allows the build system to create an image appropriate for the target device.
No longer having access to the source code commit history does not help the situation either. This was useful as a reference point for the development of ROMs for other models. It made it easier to integrate features, bug fixes, and security patches.
So it's likely we'll see even fewer custom forks in the future, whether for Pixels or other brands. And for devices that are still supported, updates may take longer to arrive, as development times will lengthen.
0 Comments