Google restricts Pixel source code tags in AOSP, hindering custom ROMs

Google has stopped pushing Git tags for Pixel kernel and userspace driver repositories to the Android Open Source Project (AOSP), creating new hurdles for the community of developers who build alternative operating systems. This change marks a significant departure from how the company has historically shared device-specific source code.

According to reports discussed on Hacker News and the GrapheneOS forums, Google has ceased pushing AOSP releases specific to Pixel devices. Instead, the company has transitioned to a release model consisting of yearly updates, QPR2 releases, and security backports. A representative for GrapheneOS noted that Google "stopped pushing tags for any of the Pixel kernel or userspace driver repositories to AOSP," a move that coincides with the rollout of Android 16.

The shift in AOSP transparency

For years, Google provided detailed Git tags and device-specific releases within AOSP. This infrastructure allowed third-party developers to track granular changes, audit code, and build custom ROMs efficiently by pulling specific versions of the source. The transition to Android 16 has seen a tightening of this process, with some reports indicating that histories for Pixel kernel driver repositories are now being squashed, further obscuring the evolution of the code.

Implications for independent OS developers

This shift increases the technical friction for security-focused operating systems, such as GrapheneOS, which rely on these repositories to support new hardware. By removing the transparency and ease of Git-based tracking, Google makes it more difficult for the community to patch and maintain open-source alternatives to the stock Android experience. One user on the GrapheneOS forum remarked that the project is becoming "less Android Open Source Project and more Android Closed Source Project."

What to watch

While the core source code remains available, the removal of the tagging system forces developers to find alternative ways to synchronize their builds with Google's official releases. The industry is now watching to see if this restrictive approach extends to other hardware lines or if the community can establish new standards for tracking device-specific implementations in the absence of official Git tags. The long-term impact will likely be measured by how quickly independent projects can adapt to this fragmented release model without sacrificing the auditability that defines the open-source ecosystem.