GrapheneOS is the only Android OS providing full security patches

I have been trying to come off of google and cloud by building — quite slowly — my own nas server which has 2 nodes in two geographic regions where I am building certain services like cloud storage and backup, webhosting etc. But I think there are a few key things that need to be community driven to really get rid of this duoply.

0. A privacy first approach would be something like this:

`You+App --Read/Write-> f_private(your_data) <--Write only- 3p` and App cannot communicate your data to 3p or google/apple.

Think of Yelp/Google Maps but with no _read_ permissions on location, functions can be run in a private middleware e.g. what's near an anonymous location or ads based on anonymous data. You can wipe your data from one button click and start again for EVERYTHING, no data is ever stored on a 3p server. Bonus: No more stupid horrible permission fiascos for app development that are just plain creepy.

1. An opensource data effort that can support (0) with critical infra e.g. precise positioning, anonymous or privacy preserving functions that don't reveal their data or processes to 3p.

Here is my favourite open source effort: Precise Location Positioning. A high recall, opensource, 3D building and sattelite-shadow Data-Infra effort[3]. This world class dataset on shadows and sattelites are a must. Most geo-location positioning tied to Radio signals is just a bandaid and fraught with privacy issues — thought there are heroic privacy first efforts in this direction[1][2] which though amazing will be playing catch-up with google already deploying [3].

[1]https://beacondb.net/

[2] https://github.com/wiglenet/m8b

[3] https://insidegnss.com/end-game-for-urban-gnss-googles-use-o...

    `You+App --Read/Write-> f_private(your_data) <--Write only- 3p`

I'm not knowledgeable enough -- what would it take to escape the Apple/Google duopoly?

I'm imagining a future where you buy a smartphone and when you do the first configuration, it asks you which services provider you want to use. Google and Apple are probably at the top of the list, but at the bottom there is "custom..." where you can specify the IP or host.domain of your own self-hosted setup.

Then, when you download an app, the app informs the app provider of this configuration and so your notifications (messenger, social media, games, banking, whatever) get delivered to that services provider and your phone gets them from there accordingly.

Is there anything like that in the world today?

  > Indeed the GrapheneOS community is known for attacking the GNU/Linux mobile with false claims, https://news.ycombinator.com/item?id=45562484.

You might also be interested in Jolla Phone https://news.ycombinator.com/item?id=46162368

> but still I'd like to choose my hardware and software separately interoperating via standards

This is why I can’t do GrapheneOS. Pixel devices do not suit my needs (& aren’t available). 2 of the big appeals for my going Android was 1) device options 2) ability to customize (appearance, apps from other sources, root access). Google has basically done everything to prevent #2 & GrapheneOS prevents #1. …This is why I also have a Linux phone to just leave these restrictions.

Pixel phones currently have the additional benefit of a full Debian OS running via AVP. This is (imo) on par with or better than having Termux on a rooted device. It's still fairly off-the radar which makes it a really good time to be exploring it's uses.

Totally agree. Pixel devices are probably still the best Android offering, but I originally got into the ecosystem because it was less confined and that appears to be changing. While I'm likely not representative of most consumers, I would love it if I could choose both the right device and right software for my particular needs .

Even if google breaks compatibility, still using some compatibillity mode it's possible to run such apps right ?

I’ve been an iPhone user from the beginning but this would really tempt me.

Worst case scenario we still have Google Pixels.

Non-Google attestation is still a bad thing.

I'd much rather GrapheneOS continue to get popular enough that banking apps are forced to support phones without attestation.

I'm writing this on a grapheneos pixel 5. I have the app for very-large-USbank and a few others. With 'exploit protection compatibility toggle' enabled they works fine. In what regard this applies to device attestation I couldn't say.

Never underestimate stupid, especially for that sector.

Safety net is a joke and google only has it to milk as much as they can from OEM manufactures and gives false sense of security

GrapheneOS has device attestation support on Pixel devices, i.e. it passes SafetyNet. It's just that some apps (e.g. Google Pay) explicitly exclude it.

Not sure if the big manufacturers would want to depend on a proprietary Google OS. Samsung does make a lot of changes to the OS, for instance.

They won't because they literally control the mobile market by having Android open source.

Well, in the much longer term they have usually mentioned they would like to use a more secure/private foundation (more in the direction of Qubes/Redox/Fuchsia) with a compatibility layer for Android apps if they have the resources to do so.

Then Android gets forked.

They seem to refuse that they're working with fairphone, so it seems unlikely.

https://www.reddit.com/r/GrapheneOS/comments/1o3vmn5/comment...

My guess is that its either HMD or Nothing. Will probably still take a while until we learn about this

The most likely contenders are OnePlus, Motorola, and HMD.

> "It is a big enough OEM that there is good chance you may have owned a device from them in the past."

I think this takes Nothing out of contention.

If you've run a open source project almost of any size, it's quite a task having to support it on various devices scenarios.

The GrapheneOS devs are doing the right thing for the longevity of the project. Focus on a small number of phones/hardware. It guarantees its long term success.

Excellent work I think, also the Pixel hardware design offers slightly better security with the baseband.

Have you considered using mail forwarding, or sites like Swappa.com with forwarding built in?

Hoping this helps you get your hands on a cheap Pixel!

Pixel hardware is below average? Since when? That sounds like a flagship phone to me.

Pixel with GrapheneOS is still great. And it may take 1-2 years before GrapheneOS gets on this new device.

Now if you just bought a Pixel, it will be supported for 8 years, so by this time hopefully GrapheneOS will be available on many different devices :-).

probably good timing

this will take a while and RAM prices will be out of control for a while as well

I guess antitrust is the keyword here. Something that is considerably weakened in today's USA.

This and also cryptography technology was not nearly as sophisticated and easily accessible as it is today, and where it existed it was pretty slow on the hardware of the time.

Yeah but lots of phones you can't get ROMs for from a reputable source, and I sure as heck don't have the know how or time to build one, even if possible, which a lot of times is not due to locking down bootloaders, drivers, etc.

This just shows that the barrier of entry of a new phone OS is more than $0. You can pay app developers to port their apps off of play services, you can pay developers to add support for your attestation keys. Considering how many billions of dollars Android makes for Google, there is a room for a return on investment for an alternate OS to enable investments into a new OS.

  > You can pay app developers to port their apps off of play services, you can pay developers to add support for your attestation keys.

Most ARM devices don't have UEFI or a standardized hardware abstraction layer as x86/x64 does, a prerequisite for having a choice of OSes.

I generally agree, but as a caveat sometimes it's cheaper, more robust and more efficient to build an integrated system without having to worry about interoperability. BYD's electric vehicle chasis for example, seems to greatly cut manufacturing costs, even if it makes swap-in repairs harder down the road.

But, I'd guess this accounts for a relatively small fraction of corporate decision on lock-in strategies for rent extraction - advanced users should be able to treat their cell phones OS like laptops, with the same basic concepts, eg just lock down the firmware for the radio output, to keep the carriers happy, and open everything else, maybe with a warranty void if you swap out your OS. Laws are needed for that, certainly.

> So why would a company, in this new environment, invest resources in making their hardware compatible with competing software environments?

Because that's what customers want to buy. People are paying premium iPhone prices for hardware with mediocre specs and then the hardware sells out when someone like Purism or Fairphone actually makes an open one. How many sales would you get if you did the same thing on a phone that was actually price/performance competitive with the closed ones?

Meanwhile all of that "profit center" talk is MBA hopium. Nobody is actually using the Xiaomi App Store, least of all the people who would put a different OS on their phone.

The real problem here is Google. Hardware attestation needs to be an antitrust violation the same as Microsoft intentionally breaking software when you tried to run it on a competing version of DOS and for exactly the same reason.

Even the batteries are not interchangeable on phones. You'd think all phones should have the same exact battery, that this kind of standardization is beneficial for phone manufacturers as it helps them bargain with their parts suppliers but no for whatever reason we can't have that.

Edit: I am not saying just user replaceable. I mean standardized so the same cells in a 2024 phone also works on 2025...

IBM was in a hurry.

From triumph of the nerds part 2 ( worth a watch.. they also explain how IBM ended up getting and operating system from Microsoft)

https://www.pbs.org/nerds/part2.html

https://youtu.be/_cMtZFwqPHc

“In business, as in comedy, timing is everything, and time looked like it might be running out for an IBM PC. I'm visiting an IBMer who took up the challenge. In August 1979, as IBM's top management met to discuss their PC crisis, Bill Lowe ran a small lab in Boca Raton Florida.

Bill Lowe:

Hello Bob nice to see you. BOB: Nice to see you again. I tried to match the IBM dress code how did I do? BILL: That's terrific, that's terrific.

He knew the company was in a quandary. Wait another year and the PC industry would be too big even for IBM to take on. Chairman Frank Carey turned to the department heads and said HELP!!!

Bill Lowe Head, IBM IBM PC Development Team 1980:

He kind of said well, what should we do, and I said well, we think we know what we would like to do if we were going to proceed with our own product and he said no, he said at IBM it would take four years and three hundred people to do anything, I mean it's just a fact of life. And I said no sir, we can provide with product in a year. And he abruptly ended the meeting, he said you're on Lowe, come back in two weeks and tell me what you need.

An IBM product in a year! Ridiculous! Down in the basement Bill still has the plan. To save time, instead of building a computer from scratch, they would buy components off the shelf and assemble them -- what in IBM speak was called 'open architecture.' IBM never did this. Two weeks later Bill proposed his heresy to the Chairman.

Bill Lowe:

And frankly this is it. The key decisions were to go with an open architecture, non IBM technology, non IBM software, non IBM sales and non IBM service. And we probably spent a full half of the presentation carrying the corporate management committee into this concept. Because this was a new concept for IBM at that point. BOB: Was it a hard sell? BILL: Mr. Carey bought it. And as result of him buying it, we got through it.

I don't think it's a felony to root/jailbreak one's own phone.

You can actually look at history and see what happens when IBM tries to wrest control of the PC platform back with the PS/2, which was a flop with consumers because it wasn't backwards compatible enough with IBM's own previous PCs or the wider PC market that developed. A bunch of PC clone manufacturers got together and came up with the EISA bus standard so they wouldn't have to pay IBM license fees for MCA, and made it backwards-compatible with ISA cards people already had. It was successful enough that IBM ended up adopting EISA for some of their PCs.

The other notable thing about the situation is that three companies ended up simultaneously responsible for a large part of the PC platform, originally -- IBM, Microsoft and Intel. They all worked in various ways to encourage competition to each other -- the reason we see OS competition on the PC platform is that IBM and Intel both found it in their interests to allow other OSes on the platform to reduce Microsoft's leverage over them. IBM in fact created one of the competing PC OSes out the gate, OS/2, which was originally an IBM/Microsoft joint project until they started feuding. Now, OS/2 is dead, but IBM's interest in being able to support their own OS instead of Microsoft's is a big reason the PC platform was built in an OS agnostic way. People criticize UEFI for locking down the PC platform more than the previous BIOS implementations, but UEFI is still _way_ more open than basically any other platform, most of which don't have a standard for bootloaders at all. It's really the absense of a standard for bootloaders that keeps most Android phones locked down. Two Android phones from the same OEM might have different bootloaders, much less two phones from different manufacturers. We've yet to see an alternate OS with the resources to support implementing their own bootloaders for a majority of Android phones.

I see people saying things like this all the time and then when I ask them for the specific text requiring them not to e.g. publish source code, nobody has been able to show me.

And a huge reason it seems like BS is this:

> PCs don't have that restriction.

There are obviously PCs with Wi-Fi and even cellular modems, so this can't be an excuse for a phone to not be at least as open as a PC.

> The company making a device that is licensed by the FCC has to do everything that they can to mitigate the risk of an unlicensed broadcast on their devices.

Where do you see this in the rules? The only thing I see that even comes close is the following sentence:

"Manufacturers and importers should use good engineering judgment before they market and sell these products, to minimize possible interference"

Maybe it's because I don't routinely deal with the FCC but to me, that language doesn't imply anything close to your ironclad rule you posted.

I'll also point out there are plenty of other devices that get sold that seemingly break your rule. SDRs, walkie talkies with the power to transmit for miles, basically every computer motherboard made since the year 2010, the Flipper, etc. At most, they simply have some fine print in the manual saying "you should probably have an FCC license to use this".

Furilabs was just in the news here because they discontinued their device models from a few years ago, and released a new device for a big price bump with _significantly worse_ hardware.

I know I would love to give them a try, but a 720 screen is an absolute non starter for me. It would be hard for anyone to sell me on just a FullHD (1080) screen in the era of QHD (2K) being industry standard. Additionally, I believe their FAQ even admits that their already low power devices only get a few hours of battery life.

FWIW, Jolla just announced a new phone: https://commerce.jolla.com/products/jolla-phone-preorder

https://liberux.net/ looks promising as well.

> I don't think that's a fair comparison.

Fair?

> OEMs have quite a lot of extra steps before releasing any build to the public.

AIUI updates are less stringent and burdensome than initial certification. Regardless much of the process is automated. Graphene has CI too. 3PL's taking 4 weeks to run automated tests is also absurd. There are some "manual steps" to run CTS-V but they shouldn't be weeks level burdensome either. This is the point, this is an industry problem.

The reason that the OEMs even have to deal with this 3PL test mess is for GMS certification, so again this is a policy decision that enforces a poor process. The bad properties of the process are not inherent to the problem space of validating builds against requirements. An industry problem.

> There are "quicker" release channels for security fixes, but I don't think it's common for OEMs to only ship those without any other change to the system.

Seems like a decision that is not user-centric.

> I don't think Graphene does anything of sort, they take what's already certified in the Pixel builds and uses it. Not like they could do much aside testing on the public part of xTS.

Private test suites for software are a toxic idea, it's in the same box as "SSO tax", and other such "pay for security" models. Given the software industry can't be trusted not to do this, I'm almost keen to see legislation to explicitly ban this practice.

We'll have the same update pace for security updates and major releases with the devices we're working on with our OEM partner. That's not specific to Pixels. It will in fact be easier to support the devices with the OEM partner due to them planning on doing most of the device support work including getting MTE working properly. For Pixels, we have to do a lot of work on device support, while for non-Pixels that work is going to be done for us. Our OEM partner is actively getting what's needed from Qualcomm including getting them to fix things. We're in direct contact with Qualcomm ourselves and plan to deploy new security features they've developed which are not yet available elsewhere.

Samsung and Google ship a small subset of the security preview patches early while we're shipping all of them. We're doing a lot of work to integrate and test those. We also have to port them from Android 16 to Android 16 QPR1 and now Android 16 QPR2. It seems they might start providing them for Android 16 QPR2 themselves but for now we had to port them for our QPR2 releases.

We also have to test and fix all the issues caused by us having much more advanced exploit protections including full system hardware memory tagging with a more advanced implementation. We uncover MANY upstream memory corruption bugs we need to fix. Features like Contact Scopes, Storage Scopes, 2-factor fingerprint authentication, etc. are not always easy to port to new versions. We still don't have early access to upcoming quarterly and yearly releases but we'll get it and then we can have day 1 updates for those instead of it taking days for an experimental release and around 1-2 weeks before it reaches the Stable channel. We intend to do much better than we are now, we just need the same early access OEMs have but don't actually use to make day 1 releases for major OS updates.

Hopefully you don't mind me asking this question, but didn't you work with people who managed to do exactly what you are suggesting with a fairly small team at Essential for a few years?

Yep. And GrapheneOS's changes to the kernels of devices they ship are laughably small, 20-30 commits at most. I don't think they even do any basic CVE checks on any of the source code.

Fuzzing, actual security analysis - all those things are done by Google.

There more sources if you google, but someone leaked a Cellebrite meeting.

https://www.androidauthority.com/cellebrite-leak-google-pixe...

https://arstechnica.com/gadgets/2025/10/leaker-reveals-which...

Their marketing slides include GOS, and they have since 2021 I think was just said "can't access that".

I would imagine it's a very high priority if you have powerful targets. They're not gonna be running an off-the-shelf android phone.

Considering they mention it on their marketing materials, they definitely did bother

Don't worry, Apple can do it themselves as they have full remote access

He never shows any evidence. Always accusing without any images/links. I love the project but it looks not normal.

You're making libelous claims without evidence while falsely claiming that I'm doing it. This typically goes along with baseless claims that I'm insane, delusional, schizophrenic, etc. with links to extraordinarily dishonest content filled with obvious fabrications from a couple serial harassers. One of those serial harassers has an identity verified Kiwi Farms account and was the one who involved them in targeting me (kiwifarms . st/members/larossmann.132201/). We've provided a large amount of evidence. Here's the leader of Murena and /e/ linking to libelous harassment content towards me on a conspiracy site this week: https://archive.is/SWXPJ + https://archive.is/n4yTO and we have dozens more examples archived for him specifically. You target us with libelous claims, bullying and harassment then claim we're creating drama for defending ourselves from it and documenting it. If you want the 'drama' to stop then stop engaging in harassment.

And the unreasonable man has decades of security research under his belt and somehow you know what's best?

You can't equate actions from a part of the community with actions by the project. If you would see any bigotry by a GrapheneOS community member, please report it to the moderators. Bullying, toxcity and misinfo are not allowed. Action will be taken.

I havent noticed a lot of that in the community myself, in which im very active. Its exceptional in my eyes. Common though is technical criticism on other projects when people ask advice about it or want a comparison with alternative. Also common is people being fed up by harassment by other projects.

The founder of /e/OS repeatdely attacks GrapheneOS in random internet threads that are only mention GrapheneOS. This contrast with the approach of GrapheneOS where they will only do a comparison with /e/OS in reponse to posts where both are mentioned and compared by others. Or, in reponse of wrong comparisons in the media or harassment (personal attacks etc.) stemming from them.

F-Droid does also have some maintainers that engaged in personal attacks against the GOS founder. And anyway what do you expect the project to do if people ask whether to get apps from Play Store or F-Droid? Pretend there is no technical security difference? If people ask questions, the project and community try to inform.

There is big conflict with Debian or Linux kernel at all. They also dont mismarket themselves or spread misinfo about GrapheneOS. They are concerned though that both heavily used projects lack a security focus.

Not for the ones on the receiving end.

Listing a bunch of projects I've not heard of and attacking me for "supporting" them is exactly the kind of behaviour I'm talking about :P

>Your project's team has regularly engaged in very underhanded attacks on ours despite us never doing anything to you. We have archives of it.

What team are you talking about? JMP/Cheogram? This is the first I've heard of this.

> It's quite surreal how unsafe the standard Android

Well that's untrue. I'd even venture to say that with how many OEMs there are it's insane how safe Android is. Google for one updates their devices for 7 years since Pixel 6, they can't control OEMs who might have ~10 people working on their devices.

Here's the discussion forum post going over it: https://discuss.grapheneos.org/d/27068-grapheneos-security-p...

afaict it's more like "making sure <OEM>'s next flagship supports graphene"

Don't understand your statement about avoiding client-side scanning of text messages. I've always assumed it would be done by the apps themselves, e.g. WhatsApp, Telegram, etc..

That sounds amazing. I aspire to get a setup like yours. I am on a Pixel with the stock OS and I can't stand the way Google is pushing AI into everything on my phone.

I haven't switched it to Graphene OS yet because I read that there are issues with NFC and a few other things. I assume this new phone won't have those problems so I think that will be my catalyst to do a big overhaul.

that is simply wrong.

GrapheneOS is both in terms of security and privacy the best but currently only supports pixel phones.

LineageOS is trying to support as many devices as possible still with lot of google connections and missing security updates.

>Good news is that if you have a boot passphrase, it's security is somewhat close to GrapheneOS

its not anywhere close https://grapheneos.org/features

How can LOS's security be somewhat close to GOS if it's worse than OEM? LOS lacks verified boot, hardware security features, it's often behind is security patches.. With "advanced protection" enabled stock OEMs are even more secure, but GOS is even more secure still. When it comes to EOL devices, LOS may be more secure than OEM depending on your threat model.

https://eylenburg.github.io/android_comparison.htm

That comparison shows "Deblobbed? Yes" for GrapheneOS. That implies they've replaced (most of) the blobs for wifi, bluetooth, 5g chips etc.

Is that actually true? It's such a big deal, and I see little to no work being done on this front.

Anyone have any idea what GrapheneOS actually deblobbed?

Nice! Thanks for the link. I noticed they didn't mention MOCOR OS (for the new Nokia 3210), but then I remembered that that's not an Android version. I'll see if they can add it somewhere else.

Unrelated, but this led me to find gnuclad, which may be somewhat externally maintained and is used to create the cladogragms.

This is a great resource! Thanks

It might be important to mention, that Lineage OS is available on a number of the devices abandoned by their original vendors, so sometimes it may be a much better solution to get a Lineage OS onto their former "flagship" which stopped getting updates 18 months after the release.

So if the bootloader can be relocked and not passing Play Integrity scam is not a problem, Lineage may be a better option. Better than nothing, that is.

I believe you can root GrapheneOS. It just breaks the security model, so it's not recommended to do so.

It's not really locked down. You can toggle or enable some of the more activist-orientated features. The only limitation I'm aware of is that some apps requiring the strongest Play Integrity setting (ChatGPT, some banks, very few airline apps) just won't work on GrapheneOS.

https://unifiedpush.org/ fixes this for a number of apps. Self-hostable.

Battery life is still better than stock in my case, and it's just as reliable as sandboxed Play. Highly recommend.

This is true if you opt not to install Google Play Services.

One caveat--you have to be certain that you get a Pixel with an unlocked bootloader. There are a lot of Pixels (mostly sold by Verizon) that are unlocked for use with any carrier, but whose bootloaders remain locked. If you have one of these ex-Verizon phones, there is no way as of now to unlock the bootloader.

Unrelated to bootloader or rooting. Pixels are the only phones that adhere to the device requirements that are listed in the FAQ.

https://grapheneos.org/faq#future-devices

I won't be silent to the obvious honeypotting and mob tactics to silence people around here.

It's inaccurate that GrapheneOS fully endorses Signal and Tor. The GrapheneOS founder was blocked by Moxie (when they were still leading the project) for criticising their approach. They have also warned countless times about the limitations and weaknesses of Tor.

> Please consider saner options such as LineageOS or Replicant which support dozens and dozens of different device types.

An important motivation for a FOSS OS for phones is not having to buy a new phone just to have up-to-date software.

Also, "people" who buy a Google-Pixel-level phone every two years are likely among the richer... let's say 10% of the world's population? Probably even less. The rest - don't do that.

I don't think that is a consideration for the project. Their OEM partnership also includes supporting a current generation Snapdragon SoC which seems to feature an integrated modem.

>A component being on a separate chip is orthogonal to whether it's isolated. In order to be isolated, the drivers need to treat it as untrusted. If it has DMA access, that needs to be contained via IOMMU and the driver needs to treat the shared memory as untrusted, as it would do with data received another way.

from https://grapheneos.org/faq#baseband-isolation