GrapheneOS Says Google Is Building Walls Around Android
Google built Android to be open. A decade of decisions has made it harder to use for anything Google did not approve — and two mechanisms working together have turned what looked like an open platform into something structurally closer to a locked garden.
GrapheneOS, the security-focused mobile operating system based on AOSP, posted a lengthy thread on X this week laying out what it says is a systematic effort by Google and Apple to close off the platforms their software runs on. The tools in question — Google's Play Integrity API, Apple's App Attest, and Google's reCAPTCHA — are marketed as security features. GrapheneOS calls them something else: infrastructure for locking users into approved hardware and software. The two mechanisms reinforce each other: a surface-level API layer that restricts which software can run, and a hardware-and-source layer underneath that makes it harder to build alternatives in the first place.
The pattern is familiar in technology, even if it rarely plays out this completely. IBM opened the PC architecture in 1981 and watched the PC ecosystem flourish; then Microsoft layered Windows and Office on top until the openness became an obstacle to Microsoft's preferred position. The early web was genuinely open; it became a set of walled gardens when the platforms discovered that controlling distribution was more valuable than enabling it. Google is now following the same sequence in mobile: the openness was real, it attracted the developers, and now the mechanisms are arriving.
The API-layer lock is the most visible piece. Play Integrity, used by banking apps and other sensitive services to verify that a device is genuine and running certified software, blocks GrapheneOS from running. "Google's Play Integrity API bans using GrapheneOS despite it being far more secure than anything they permit," the project wrote. The system is designed to catch rooted phones running banking trojans. It also catches a mobile OS that independent security researchers have repeatedly found harder to compromise than stock Android or iOS. The justification is not invented — modified OSes do create real security surface area. But the same mechanism also prevents users from running software that Google did not certify, regardless of whether it is more secure.
The technical dependency underneath makes this worse in 2025 than it would have been in earlier eras. A functional Android fork in 2025 requires more than AOSP source code. Google Play Services — the suite of APIs that connect to Google Maps, push notifications, Firebase, cast, and dozens of other backend services — sits underneath a large fraction of popular apps. Many apps will not function properly, or at all, without it. This is not a theoretical concern: apps that depend on Play Services are the ones that trigger Integrity checks. The result is that an Android fork can be technically sound and practically unusable, not because the OS is broken but because the service layer it needs was designed to be controlled.
The more structural problem is what Google has done to the development environment underneath AOSP itself. Google moved Android OS development to a fully private internal branch in early 2025, abandoning the public development model that AOSP was built around. Summer security updates and the Android 16 beta source code took significantly longer to arrive as a result — delaying work on custom ROMs that depend on being able to read and modify the OS code. Google also stopped releasing complete and timely device trees, driver binaries, and kernel sources for Pixel phones, steering developers toward a virtual reference device called Cuttlefish instead. Without those files, building a custom OS for a Pixel is substantially harder; without an easy path to building, Pixels are less useful as a base for privacy-focused alternatives.
"Without easy developer access to source code, Pixels have become a less practical base for custom ROMs — eroding one of the series' few advantages over other Android devices," Mishaal Rahman wrote at Android Authority.
Security patches compound the problem in a way that affects existing Pixels, not just future ones. Google has been releasing critical updates to OEMs under a multi-month embargo before publishing the corresponding source code. GrapheneOS can ship binary updates during the embargo period, but it cannot publish the source code until Google's restrictions lift. Low-level vulnerabilities in firmware or drivers are outside GrapheneOS's ability to patch independently — they wait on Google's timeline, regardless of how serious the vulnerability is.
There is a genuine tension here that the story should not flatten. Play Integrity and similar attestation systems exist, in part, because unmodified software stacks are actually harder to attack in certain ways. A device running a known, tested configuration is more predictable than one running a modified OS with unknown configurations. Banks and payment systems have legitimate reasons to verify the software environment before granting access to financial accounts. Google can reasonably argue it is enforcing compatibility standards rather than specifically targeting GrapheneOS — and indeed, the checks block any modified OS, not GrapheneOS specifically. The security argument is real even if the implementation is also being used for anti-competitive purposes.
The second-order implications extend beyond privacy enthusiasts and developers. Google's reCAPTCHA, used across a significant portion of the web, increasingly requires users to verify themselves with a certified Android or iOS device. In some cases, users must scan a QR code with their phone to prove they are human. GrapheneOS argues this puts Google in a position to require either an iPhone or a certified Android device to access a substantial portion of the internet — and governments and banks are adopting the same verification systems for payments, digital ID, and age verification. If critical government services and financial access are built on these APIs, Google and Apple become de facto gatekeepers for participation in digital public life, on the strength of a security justification that also conveniently closes the platform.
Whether large-scale consumer mobile alternatives have ever existed without major platform-layer dependencies is an open question among security researchers and platform economists. On the desktop, GNU/Linux has existed for decades as a genuinely independent alternative — but it has never reached more than a few percent of consumer desktops, in part because of driver gaps, software compatibility issues, and the convenience cost of leaving the mainstream. Mobile has historically been harder: the hardware is more integrated, the baseband and application processor are more coupled, and the app ecosystem is more concentrated in two stores. An Android fork that runs fine but cannot run most apps is not an alternative in any meaningful sense. The structural obstacles are real, and the history of mobile openness suggests that even technically sound alternatives struggle to cross the usability threshold that would make them viable for mainstream users.
GrapheneOS is not walking away quietly. The project announced it is partnering with an unnamed smartphone maker to officially support a Snapdragon-powered device — a shift from Google's in-house Tensor chips toward hardware that may offer more predictable developer access and firmware update commitments. Pixel 10 will be the last Pixel supported; Pixel 11 is still undecided. The move is less a philosophical statement than an engineering one: when the development environment becomes hostile and the platform APIs start blocking your users, you go where the tools work.
Google and Apple have not responded publicly to the accusations. That silence is itself meaningful. Both companies have calculated that the security rationale is sufficient cover and that the affected user base — people who actively choose not to run the default OS on their phone — is small enough not to generate meaningful pressure. The history of platform enclosure suggests they may be right in the short term. The history also suggests that the moment alternatives become genuinely useful to mainstream users rather than just developers, the same mechanisms that are locking GrapheneOS out today will face a very different kind of scrutiny.