AFAIK the Pixel devices are the only ones that reliably allow bootloader unlocking / re-locking, that is required to perform custom os installs.
There are others e.g. Motorola ones or Fairphone, that also allow this but it's a good idea to focus on a specific set of devices keeping maintenance as low as possible and security focus as high as possible.
There are alternatives like /eOS/ or CalyxOS supporting more devices and I experienced exactly this "no longer supported" issue with my Xiaomi A2, which suddenly disappeared from the list of supported devices (see https://calyxos.org/news/2021/03/29/mi-a2-ten-firmware/).
Pixels are the most secure Android devices and the only ones meeting the hardware security requirements for GrapheneOS at this time. GrapheneOS is working with a major Android OEM towards their future devices meeting these requirements.
Neither /e/ or CalyxOS is a hardened OS. They provide much weaker protection against these attacks than the stock Pixel OS or especially an iPhone. They're weakening privacy and security substantially including lagging many months and even years behind on standard security patches. CalyxOS has not shipped the June 2025-06-05 patch level or later. /e/ is regularly many months behind on OS and browser security patches along with very often being a year or more behind on kernel updates and firmware/driver updates.
Pixels are the only devices that are out right now that meet the project's requirements. The project is in talks with a major OEM to have some of their devices meet GrapheneOS's requirements and have official support for GrapheneOS. Assuming all continues to go well, the project has said they expect those devices to be out in 1-2 years.
Kind of. I don't use grapheneOS and I'd like to, but de-googling your phone by buying a Google phone seems a bit sketchy. I don't want to take away from a privacy focused project. I'm super thankful for this option and I can't stand android or iPhone. But in the back of my mind I wonder if I'm being tricked.
As for why graphene uses graphene uses pixels - their FAQ does a good job explaining. As for why google keeps the bootloader opened and maintains (until recently) good enough device-tree support- I would guess mostly historical reasons? Before becoming as mainstream as they are now nexus and pixel phones used to be in part android development devices and certain creature comforts stuck. This seems to be souring though, so some of the people there may be in talks with an OEM for a graphene os specific device[1].
> It still seems strange. A big part of GrapheneOS is to provide a safeguard from Googles data hoarding, yet it works primarily on Google phones.
That's the most confusing part. IMO GrapheneOS is not mainly about "provide a safeguard from Googles data hoarding", instead this is more like a side quest.
GrapheneOS is about creating a mobile OS that is more secure against advanced threats [0] than anything else, including stock Pixel OS and iOS.
[0] Currently my rule of thumb is, anyone who can find and write exploits for new memory corruption bugs for the wanted attack surface, or who can buy such capability, qualifies as advanced threat. Hence Cellebrite qualifies as a borderline "advanced threat".
That doesn't seem odd to me. Google's data hoarding is done in software, not hardware. Remove Google's add-on software and you have a more or less blank slate to work with. I don't see why we'd expect any different.
This is the answer. Google play services and related privileged components are the non-open source blob hoarding data, along with whatever backend services you use from Google. These components are part of the stock android image that comes on the device that's replaced entirely by GrapheneOS.
Naturally if you continue to use Google services then the data hoarding continues.
Considering last years development and quite open Google hostility?
No.
GoS have provided a lot of patches upstream, Some of which were even applied. Despite that they wouldn't get early access to A16 just because. Access EVERY vendor promising to preinstall privileged Google services has.
Allegedly Google security team was very happy about that idea, but got vetoed by management.
I don't have and never had any connection to GrapheneOS developers, positive or negative, online or offline, nor am I working for any of their competitors. I only have the philosophical disagreement with their decisions explained in my link above.
He's not wrong from a computer freedom perspective. GrapheneOS is actively hostile to things like complete root access. It blows a hole in the security model. It's also very much enabled by the exact same sort of user hostile cryptography that corporations use to lock down their devices. Things like hardware attestation which protects apps from us. We can't easily do things like MITM an app to reverse engineer it.
I still it's superior to any stock Android OS but the risks associated with giving up freedom for security must be considered. The ideal is to have security while simultaneously maintaining our power as the owners of the machine.
GrapheneOS only supports devices where users can have full control over the OS and replace it. Choosing to use GrapheneOS is fully optional and people who don't want a strong security model can use something else. Not clear how GrapheneOS in any way hurts people's freedom by giving them a highly private and secure OS option for devices which meet our requirements. We're working with an OEM on towards more devices meeting our requirements which will support using other operating systems too. If you want another OS, you can use one. If you want to modify GrapheneOS in any way you want, that's fully supported. We provide easy to follow build instructions. You can make a userdebug build with ro.adb.secure=1 if you want root access at the cost of security.
> people who don't want a strong security model can use something else
You have a very special threat model, which you for some reason always call the best or the only one reasonable. In reality, depending on the user's threat model, your approach can fail miserably. For example, if my threat model includes that Google can utilize their control over the hardware to undermine my security, then your approach fails [0]. And this is a real-world example.
Don't get me wrong, I still agree that your approach is very secure, it should exist, and you're doing an amazing job for the Community. Just that you shouldn't behave as it's the only viable one.
> Not clear how GrapheneOS in any way hurts people's freedom
It's not GrapheneOS itself that's doing this. It's technology like hardware attestation. Stock Android is rapidly becoming just as bad as iOS in this regard.
Remote attestation is a technology that enables discrimination against us. By using it, corporations can tell we've "tampered with" our own phones by doing things such as installing GrapheneOS. That's simply not a power I want them to ever have. They should be none the wiser.
The problem is they will abuse that power to deny service to anyone who isn't using a phone owned by corporations. GrapheneOS itself will probably be among the casualties. Bank apps work on it for now but there's no guarantee at all that they'll keep working in the future. Banks can just flip a switch and the apps simply stop working. No valid attestation that a corporation such as Samsung owns your phone? No service. Discrimination.
For corporations, device security means their app is secure from us. They should never be safe from us. That is my ideological point. We should be able to do anything we want, and they should be able to do nothing we don't allow.
I understand that you're doing your best to use this cryptography to protect us. I really respect the work that's being put into GrapheneOS. In fact I'd be using it right now if I could get my hands on a Pixel.
I'm just saying this hardware attestation technology enables discrimination against us.
