
At the beginning of the year, Google announced its decision to develop Android entirely behind closed doors, aiming to streamline and accelerate the development process. This shift involved consolidating into a single internal branch, rather than maintaining several parallel ones. While some members of the Android developer community initially reacted with concern, the uproar soon faded—after all, the company had long implemented most changes privately, while still committing to releasing source code publicly. However, recent alterations in the open-source side of Android have reignited fears that Google might eventually abandon comprehensive source code dissemination altogether.
This week, Google did, as promised, release the source code for Android 16 under the Apache 2.0 open license through the AOSP project. Yet developers were quick to observe glaring omissions. Notably absent were the device tree files for Pixel devices—a crucial set of configurations that once made it straightforward to compile Android for specific models. Additionally, no new binary drivers were published, and the kernel source’s commit history was condensed into a single generalized commit. Historically, Google had shared all of these elements regularly, and their disappearance has raised red flags.
Some speculated this marked the first step toward winding down the AOSP project. In response, Google’s VP of Android Platform, Dave Burke, insisted such fears were unfounded, reaffirming the company’s commitment to openness. He clarified that Android requires a reference device decoupled from any specific manufacturer and universally accessible to developers. Henceforth, the role of reference platform will be filled by Cuttlefish, a virtual device that runs on standard PCs and allows for testing Android features without dependence on physical hardware. Google will also continue supporting Generic System Images (GSI), which are compatible with a wide range of devices.
From Google’s perspective, the rationale behind these changes is clear. The company no longer wishes to treat Pixel as the AOSP benchmark, given that it is a consumer-end product infused with proprietary enhancements. In contrast, Cuttlefish represents a more neutral, adaptable alternative—albeit one that cannot fully emulate real hardware behavior.
More pressing, however, are the implications for the custom ROM developer community, including teams behind projects like LineageOS. Nolan Johnson, a prominent contributor, lamented that building custom ROMs for Pixel will now become “painfully” difficult. Previously, developers could simply utilize Google’s ready-made configurations, apply their own modifications, and compile the system. Now, they must rely on outdated Android 15 configurations and engage in painstaking trial and error to identify changes by reverse-engineering precompiled binaries.
Without device tree files, it becomes nearly impossible to build Android tailored to specific hardware, as these files define essential components such as drivers and hardware specifications. Furthermore, the omission of kernel commit histories strips developers of the ability to track bug fixes and security patches. Although Google is under no legal obligation to provide these resources, it has done so for years—largely because Pixel functioned as an open testing platform.
That paradigm has now shifted. For teams like LineageOS and GrapheneOS, which create customized Android builds for Pixel devices, the process has become significantly more arduous. While it remains technically feasible to build AOSP, they must now reconstruct the entire configuration from scratch—much as they have long done for other Android devices. The Pixel’s only remaining advantage lies in its unlockable bootloader and accessible factory images. Yet the road to a stable custom ROM has grown markedly more challenging.