Throughout 2026, GrapheneOS documented a growing gap between Android’s open-source code and the freedom to build and use an independent system. The story moved from service access to source access, then to new APIs shipping without an AOSP release.

AOSP still provides open-source code. What is shrinking is the practical openness around it: the ability to keep up with the platform, use its services, and inspect the software on your own device.

2024–2025 — the warning signs

In October 2024, a Pixel 6a user reported that Documents on IO rejected their device despite a locked bootloader and no root access. In July 2025, another user requested GrapheneOS support after being unable to add a driving licence. These reports concern Italy’s IO app, rather than every European identity wallet. They show the stakes: choosing an OS can affect access to public services.

May, 2026

GrapheneOS warned that more services were adopting Apple and Google’s attestation systems. Hardware attestation can provide evidence about a device’s boot state and software identity. Platform policies decide whether that identity is acceptable. The proof is cryptography; the approval is policy.

For example, Google’s Play Integrity criteria for MEETS_DEVICE_INTEGRITY on Android 13 and later require a certified manufacturer image. An alternative OS can preserve Verified Boot and a locked bootloader yet fail that requirement. Services choose whether to require the verdict, but doing so makes Google’s certification rules part of their access policy.

August, 2026

GrapheneOS reported that some source previously published through Git tags now required a Google Forms request and delivery through Google Drive, with increasingly slow responses. The post did not name the affected repositories. Its GPLv2 allegation remains an allegation.

The practical issue is straightforward: downstream developers need timely source to audit releases and maintain their systems. Having to request it adds friction before that work can begin.

September, 2026

GrapheneOS reported that Android 17 QPR1 introduced new app APIs without a corresponding AOSP release, leaving them exclusive to Pixel OS at the time. The post linked Google’s API 37 to 37.1 changes.

GrapheneOS had already ported Android 17. This report concerned QPR1: independent systems could build the earlier release, but lacked the corresponding public source for the new interfaces. The gap was now between the platform shipping to users and the platform others could build.

Also that month, HTTP Toolkit described another obstacle to HTTPS inspection. For apps targeting API 37 on Android 17, Certificate Transparency requirements complicate HTTPS inspection using a custom CA added to the system trust store. CT protects against misissued public certificates, but also adds work for owners auditing app traffic.

Developers can still configure private CAs and CT exceptions in their own apps. The harder case is inspecting third-party apps without those options. HTTP Toolkit found a workaround using private CT infrastructure, so inspection remains possible, with more complexity.

October, 2026

GrapheneOS’s October 16 release notes reported that its update to October’s Pixel kernel drivers had been delayed by what the project described as Google’s ongoing lack of GPLv2 compliance. This concerns Pixel kernel sources, rather than the AOSP framework release itself, and the compliance claim remains GrapheneOS’s allegation.

The same notes clarify that none of the security patches listed in October’s Pixel Update Bulletin were in those kernel drivers for Pixel generations 6 through 10. The reported delay therefore does not establish that those listed fixes were held back. It does show the practical dependency behind an AOSP-based system: maintaining a build for real hardware also requires timely access to the corresponding device sources.

Where this leaves us

These events show how Android can remain open source while becoming harder to build independently, inspect, and use outside the approved ecosystem.

Alternatives such as Unified Attestation offer another way to verify devices, but services still decide whom to accept. What matters is timely source, clear acceptance rules, and a fair path for independent systems to qualify.

Secure should not have to mean vendor-approved.