GrapheneOS is finally ready to break free from Pixels, and it may never look back
TL;DR
The makers of GrapheneOS have confirmed they are partnering with a major Android OEM to bring the privacy-focused Android fork to Snapdragon-powered smartphones.
The project has confirmed it’s bringing support for Pixel 10, but is unsure whether support will continue for Pixel 11.
GrapheneOS didn’t reveal the name of its new partner, but said that those devices will be priced in the same range as Pixels.
---
Saw this coming. It would have been nice to see more transparency and less "everything is fine, we've got it covered" when I engaged with them about the recent Google updates just two months ago. The technical realities I was asking about clearly pointed here, and the dismissive responses didn't inspire confidence.
Either way, this kind of partnership was supposed to happen years ago before that deal fell through. Let's hope all those who recently bought Pixels specifically to run GrapheneOS will get the years of updates they expected before needing to migrate to this new device.
I stopped using GOS as a primary device months ago—it was a pain getting my data off, and Google's Play Integrity API is making it harder for apps to install on custom ROMs.
I still recommend them to most people for secondary devices. The privacy fundamentals are solid, but GrapheneOS has always relied on Pixel's superior hardware security (Titan M2, verified boot, etc.).
Finding an OEM partner with comparable hardware security has been a bottleneck all along. I'm genuinely interested to see what they come up with.
#IKITAO #Privacy #GrapheneOS #Pixel
Android Authority
GrapheneOS is finally ready to break free from Pixels, and it may never look back
The makers of GrapheneOS have confirmed they are partnering with a major Android OEM to bring the OS to Snapdragon-powered flagships.
@GrapheneOS
What about the "real possibility that some hardware components or features could be permanently broken on custom ROMs. Features that rely on heavily customized drivers, such as advanced camera functionalities, may be particularly difficult to implement perfectly"?
And Google's move towards using a virtual device, codenamed "Cuttlefish," as its primary reference target for AOSP development - "intended to make AOSP development more hardware-agnostic"?
I think we're all interested in what your plans are for Cuttlefish.
But more specifically:
1. You acknowledge that "device tree configurations were dropped"—so why do you dismiss this as the article "not quite understanding what changed"? The loss of device tree configurations is exactly what multiple sources identify as the core problem requiring reverse engineering.
While you're correct that userspace driver code remains available, the missing device trees are what force developers into "blind guessing and reverse engineering from prebuilt binaries."
Your response seems to minimize the significance of losing these configurations. How substantial is the impact of having to recreate device tree configurations without Google's official versions.
2. Without complete kernel commit history, how do you ensure that monthly security patches don't inadvertently break hardware functionality? The HowToGeek article specifically mentions this as a major concern for maintaining feature parity.
3. Regarding automation improvements—are you building tooling to automatically extract and reverse engineer the missing device tree configurations from Google's proprietary builds each month? This would represent a significant ongoing maintenance burden that wasn't present before.
4. What's your contingency if Google's shift to Cuttlefish as the primary AOSP reference eventually leads to reduced Pixel-specific support in future Android versions?
This appears to be part of Google's strategy to make AOSP "hardware-agnostic."
5. Can you quantify the development time impact? While you've maintained Android 16 support, how much additional development time per release cycle are you now allocating to reverse engineering that was previously unnecessary?
The broader privacy community deserves transparency about whether this represents a sustainable long-term approach or if we should be preparing for reduced custom ROM viability on future Pixel generations.
View quoted note →
