Google is making it harder to build custom ROMs for Pixel phones

Unlike some of the best Android phones on the market, Google Pixels have traditionally given developers a clean, transparent canvas to inspect software, test early builds, and run alternative operating systems like GrapheneOS. However, a quiet shift in how Google handles Pixel source code is reportedly threatening that open reputation, and it could soon impact anyone using custom software on their phone.

According to GrapheneOS on X, Google has apparently replaced public, instant code downloads for Pixel phone drivers with a manual request form. Instead of publishing code directly to open developer platforms where anyone can grab it, Google now requires developers to fill out a Google Form and wait for someone to send them a Google Drive link.

What used to take a couple of hours is now taking weeks.

What actually changed?

Custom software relies on two distinct components: custom ROMs (alternative operating systems like GrapheneOS) and the low-level kernel (the code that bridges your phone’s hardware to its software).

Google is legally required under open-source licenses like GPLv2 to share the low-level kernel code. Previously, it posted kernel code as automatic updates to a public developer platform. Now, GrapheneOS says Google requires developers to manually request Pixel kernel code through a Google Form and wait weeks for a Google Drive link, all while squashing the update history into a single, hard-to-read file.

Because custom ROMs cannot function reliably without a working kernel, this change creates a major double bottleneck. Kernel developers lose visibility without a step-by-step update history to trace bug fixes. Meanwhile, custom ROM projects face multi-week delays waiting for kernel files, grinding their security patches and new Android ports to a halt.

An operating system like GrapheneOS cannot release new Android updates or security patches for Pixels until it receives the kernel source code and tests the kernel. Waiting weeks for a Drive link brings their entire pipeline to a crawl.

How does this affect you as a Pixel owner?

If you use your Pixel out of the box with standard Android, you won’t notice a difference today. Your regular software updates and security patches will still arrive directly from Google as usual. However, if you buy Pixels specifically to run custom, privacy-centric operating systems like GrapheneOS, this change hits home:

• Slower security updates for custom software: Alternative operating systems rely on early code drops to test and port new Android updates ahead of time. Multi-week delays mean your custom ROM could lag far behind standard Pixel updates.
• Less transparency: Without a clear view of code history, independent security researchers have a harder time auditing what Google is changing under the hood.
• Pixels are becoming less developer-friendly, while competing brands are stepping up: GrapheneOS noted that its upcoming hardware partnership with Motorola won’t suffer from these delays because they deal directly with the hardware maker.

The GrapheneOS team clarified that this doesn’t touch Android as a whole, and it won’t touch Motorola’s upcoming GrapheneOS phones either. It’s aimed squarely at Pixel. In fact, the team claims Motorola’s long-term partnership with GrapheneOS, which ends GrapheneOS’ years-long Pixel exclusivity, exists in large part because Google made building alternative Android versions for Pixel so difficult. Motorola will host its own code going forward, sidestepping Google’s approval process entirely.

A broader shift toward tighter control

This move isn’t happening in a vacuum. It follows Google’s shift to a twice-a-year AOSP source code release schedule, moving more of Android’s core development behind closed doors until major releases. Open-source developers argue that hiding code behind Google Drive links and forms violates the open-source spirit and potentially the software licenses (GPLv2) that govern the kernel.

Just a few years ago, Google used to go above and beyond, releasing not only the GPL-mandated kernel source code but also the full kernel commit history. In fact, Google used to go two steps beyond by also releasing device trees and driver binaries, which it was under no obligation to release at all.

The company’s reason for doing so was that the Pixel was treated as a reference platform for AOSP, so developers needed an easy way to build for it. With the release of Android 16, Google shifted the AOSP reference target from Pixel to a virtual device called “cuttlefish” and subsequently stopped supplying Pixel device trees and driver binaries. And now, as GrapheneOS highlights, Google is also making it very difficult to access the kernel source code for Pixels.

In that sense, the Pixel is no longer better than any other Android phone. The only developer-focused reason to buy a Pixel now is that they remain easy to unlock the bootloader on, and their factory images are easily available.

We’ve reached out to Google to ask why this manual process was introduced and whether they plan to speed up turnaround times for developers. We will update this story as soon as we hear back.