By ByteBot
Google has replaced public Git tag access to Pixel kernel driver source code with a Google Forms request process — developers now wait weeks for a Google Drive link containing a history-stripped tarball. The change, surfaced by GrapheneOS and trending on Hacker News today with over 300 points, breaks Android’s standard build pipeline and creates direct multi-week gaps in security patch delivery for the privacy-focused Android distributions that depend on timely kernel access. Google has offered no public explanation.
What Changed and Why It Breaks the Build
The old workflow was simple: clone a public repo, check out a tagged commit, build. It took hours. The new workflow requires filling out a Google Form, waiting for a human at Google to respond, and receiving a Google Drive link to a compressed tarball — no Git history, no individual commits. Android Authority reported that wait times now stretch from hours to weeks, and Google has not responded to requests for comment.
The tarball delivery breaks things immediately. Android’s build system expects Git repositories with proper tags. Delivering tarballs instead means developers must write custom workarounds, add fragility to their build pipelines, and lose the commit history that lets them trace exactly which change fixed which bug. For projects that publish monthly security patches — like GrapheneOS — that lost audit trail is not a minor inconvenience. It is a functional regression in the security workflow.
The Security Consequence: Your Patch Window Just Got Bigger
GrapheneOS confirmed what developers already suspected: kernel access is a blocking dependency for security updates. The project stated that its releases for Pixel devices depend on receiving and testing the relevant kernel source before updates can be completed. A multi-week delay in kernel delivery means a multi-week delay in shipping patches to users. The people running privacy-hardened Android distributions are, almost by definition, the users with the highest security requirements. They are now the ones with the largest exposure window.
The commit history loss compounds this. When Google published kernel source with full Git history, security researchers could examine individual patches, trace the origin of bugs, and audit backports. A squashed tarball provides the end state but erases the reasoning. Vulnerabilities that were quietly fixed without public disclosure become harder to detect. This is a regression that affects not just patch delivery speed but the quality of third-party security analysis.
Related: GrapheneOS Duress Password Case: Is Privacy a Crime?
The GPL Question: Technically Legal, Practically Hostile
GPLv2 Section 3 permits distributing binaries paired with a written offer to provide source code upon request — which Google’s form technically satisfies. However, the GNU GPL FAQ is clear that reasonable access cannot mean arbitrary delays imposed by the distributor. A multi-week manual review process, at a company with $100B+ in annual revenue, is a hard argument to call reasonable. Most legal observers say Google is technically compliant. Most open-source lawyers say this violates the spirit of the license and invites enforcement action from the Software Freedom Conservancy.
The irony is almost too obvious to state: Google built Android on the Linux kernel, which is GPL-licensed. For over a decade, Google went beyond the minimum — publishing not just source but full commit history, ahead of schedule. The regression from exemplary compliance to “fill out this form and wait” is a choice, not a technical necessity.
AOSP’s Slow Burial
This is not an isolated incident. In 2025, Google shifted AOSP’s reference target from Pixel hardware to a virtual device called “Cuttlefish” and removed Pixel device trees and driver binaries from the AOSP repository. In January 2026, Google cut AOSP release cadence from four times per year to two (Q2 and Q4 only). OSnews called this latest move another, extremely petty nail in the Android Open Source Project’s coffin — and the pattern supports that reading.
GrapheneOS is already acting on the obvious conclusion. The project confirmed a Motorola partnership specifically because Google made Pixel development untenable. First compatible Motorola devices are expected around 2027 — not a quick fix, but a signal that the community sees this trajectory as irreversible. If the most security-conscious Android project is planning its Pixel exit, that tells you something about where AOSP is headed.
Key Takeaways
- Google replaced instant Git access to Pixel kernel source with a Google Forms process that takes weeks — breaking build pipelines and eliminating commit history
- Security patch delivery for GrapheneOS and similar projects is now directly delayed by Google’s kernel access bottleneck
- Google is technically GPLv2-compliant via a written offer, but the practical barriers invite legal scrutiny from the Software Freedom Conservancy
- This follows a clear pattern: Cuttlefish reference shift, Pixel device tree removal, biannual AOSP releases — AOSP is being repositioned away from community development
- Custom ROM maintainers should submit Google Forms proactively and build multi-week lead times into release pipelines; GrapheneOS’s Motorola pivot signals a longer-term hardware exit from Pixel
