GrapheneOS statement on Mastodon: https://grapheneos.social/@GrapheneOS/114661914197695338
Calyx made an official statement on this development here: https://calyxos.org/news/2025/06/11/android-16-plans/
Concerning stuff. Hopefully a workaround or solution is found at some point, but if not, I’m already thinking of how to manage without them.
I can’t see myself going back to a standard Android phone, so I suppose worse case scenario, I’d have to settle with LineageOS, or potentially abandon Android altogether and see if I can manage with discrete separate devices to fulfill the same needs, such as:
- a pocketable mini-Linux PC like a MNT Pocket Reform, which has the ability to use cellular networks. Should be able to text, browse web, and maybe GPS? Alternatively, perhaps the Mecha Comet?
- Small pocket-able dumb camera
- MP3 player
- Dumb-phone kept in a faraday bag when not in use?
EDIT:
Update on the situation from GrapheneOS in this thread (using Redlib, a proxy of Reddit)
The biggest problem for GrapheneOS is not the change to AOSP but rather our lead developer since 2022 being forcibly conscripted to fight in a war in April. That’s why we’ve been asking for help since April.
In April, we were contacted by someone about upcoming changes to AOSP impacting us including the removal of device support in Android 16. We talked about it internally but didn’t know if the information was credible. We prepared as much as we could for the Android 16 port but didn’t know exactly what would happen with device support. If we had clearer information on it and knew it was accurate, we could have prepared much more in advanced.
Porting to Android 16 is required to continue shipping full Android privacy/security patches regardless of device. Only the latest stable release gets full privacy/security patches, which was the May release of Android 15 QPR2 and is not Android 16. Older releases only get backports.
Pixels also only have their driver and firmware patches for Android 16, although we’re working on a release within the next 24 hours with backports of the most important firmware patches. We would normally have an experimental Android 16 release out already, if they hadn’t made changes to AOSP.
There are further changes coming to AOSP. It is not only what is talked about there.
In another comment:
We’re going to be continuing GrapheneOS but in the long term we’ll need to shift to our own devices with an OEM partner.
It’s not only Pixels which are going to be impacted. Pixels are still the only devices meeting our hardware requirements (https://grapheneos.org/faq#future-devices). It’s clear we need our own hardware in partnership with an OEM that’s serious about security and capable of delivering on it. We’ve had several attempts at OEM partnerships but they were unable to provide what we needed. It will cost millions of dollars to get a device meeting our basic requirements. We can do that, but we hoped for an OEM wanting to work with us instead of us needing to pay for everything through raising funds. We didn’t end up finding a good OEM to work with that way so we’ll do it the hard way.
frankly i just laugh at the concept of safe and secure, anyone who seriously wants into your device will get into it, if you can’t live with that idea then you shouldn’t own a modern complex device with chips that could be doing precisely whatever the fuck they want without you knowing.
it’s the same as physical locks, someone who wants to get past them will get past them, locks don’t exist to wholesale prevent entry, they exist so only the highly motivated break in, and that’s just a fact we have to live with.
This is paranoia.
Encryption works very differently. A user can encrypt a machine with an Argon2id password that requires 1GB of ram per parallel attempt, requires an average of 1s per attempt, and would take every computer on earth billions of years for a 0.1% chance to crack it if they all worked in parallel.
It’s not even close to as insecure as a physical lock.
Yes it is. There are locks out there, that have extremely sophisticated keys that are basically impossible to clone or “break in”. The way those locks are cracked or opened is nearly always unrelated to the key itself. Same goes for Encryption. Even a “simple” 20 Characters password is near impossible to brute force. Most entry points are through various other ways, which is also why i find GrapheneOS for the average user stupid.
There are other things that are needed to actually protect privacy and one of the main things it awareness. Just because stuff is sandboxed and you have some Ad-Blockers on, doesn’t mean shit these days.
With encryption, the data is changed so that only the key could decrypt it. If there are no encryption backdoors, then the key is the only end goal of attack. Compared to a physical lock, where, even if the lock was perfect, you still need to secure the structure it locks.
I still appreciate defense against the less common. Easier to focus on the more common.
Sandboxing and Ad-blockers are quite different. One gives restricted permissions, so a program has less tools to be able to cause harm, and less visibility into the system to violate privacy. Ad blockers need only to stop an ad from displaying. The security and privacy gain would likely only come from stopping you from clicking them (since they’re blocked), or stopping the resources from being networked to in the first place.
Sandboxing I would consider much better for security and privacy. That’s why its a valuable tool for security researchers.