> What is a "large portion"?

20% of apps from the Play Store not working as opposed to less than 1/10000.

> Could you describe the "fundamental issues"?

Many Android apps use functionality such as the hardware keystore APIs and other hardware APIs.

> My impression is that they just run the whole Android userspace in a container, which seems like a reasonable approach.

Using namespaces in the way they do is not a reasonable approach since they're running it with SELinux disabled which means most of the privacy and security model is disabled. It also isn't set up to run that way and requires very problematic hacks. It also ends up not being possible to run more than one instance of it due to those hacks.

> Again, I know security/privacy is your talking point, but this isn't actually the argument at hand.

It is not a 'talking point' and is very relevant in all cases. You may not care about it but most people reading this thread do.

> So, yes. > > Which is a lot of words to agree that yes, many apps only allow stock and therefor block you just like any other OS.

GrapheneOS has better app compatibility than plenty of Google certified devices. In practice, the only issues are with apps going out of the way to ban other operating systems and GrapheneOS does better than anything else. Apps are increasingly permitting it since it exceeds all their requirements and it's just a little bit of extra work for them to not solely depend on Google's API.

> I'd like evidence for "drastically", but again we mostly agree.

It's easy to check and other people have done so.

> Right. So it's 90% AOSP. Old AOSP with worse security properties, but for compat purposes that's not important.

No, you're wrong. It's very important for compatibility. Apps can and do detect large parts of the security model being disabled. A far larger portion of banking and government apps won't run on it. Having 90% compatibility with those is certainly better with 30% or less.

> You and I have different impressions of how apps approach attestatoin.

You don't have the experience and data we do. We have a large number of users and reports from them. We also have conversations ongoing with numerous banking apps about it and have seen multiple apps permit GrapheneOS. Revolut is currently talking to us, although the app works on GrapheneOS since we worked around how it was being banned in January 2025. We're also talking to Square (Cash App, etc.) and others. It is a problem which can be solved and these companies are largely not against solving it or even actively want to solve it, it just isn't something they've gotten to yet. The GrapheneOS userbase growing has begun to make this problem solve itself.

> And most apps work on waydroid. Of course the apps that go out of their way to block non-stock are the pain point.

No, a large portion of Android apps do not work with it because they use APIs unavailable or broken with it. Many banking and similar apps check that the security model is intact which it clearly isn't so they ban it but they would happily run on a non-stock OS which appears to have it intact.

> You've carved out 3 words in a way that doesn't make sense alone

What we wrote makes sense.

> 90% of the time, it works 100% of the time. Anyways, you aren't 100% compatible, so my point stands.

90% compatibility with banking apps is far better than less than 30%. You're trying to make it seem black and white when it isn't. Google certified Android devices don't truly have 100% app compatibility in the first place. Apps have plenty of required features, minimum Android version requirements, requirements for specific models (some apps only work on Pixels, Samsung flagships, etc.) and a lot more. Some low-end devices have broken support for Camera2 and other APIs despite the CTS. GPU drivers are buggy and games are buggy so there are compatibility issues. Perfect compatibility never exists. Nearly every non-banking app working fine and 90% of the special case of banking apps working fine is very good compatibility.

> I'm not comparing to stock

Most people are using OEM Android forks or iOS.

> and you refuse to give apps root access so the shortcomings that they can fix are limited

A userdebug build of GrapheneOS has root access. It's not suitable for production builds used by the vast majority of users and isn't in those. It's also incredibly niche and not very useful. What you're actually referring to is using a rootkit framework providing app accessible root access where a huge portion of the OS has root access. You're not talking about the user having root but rather a framework for apps built with disregard and even disdain for security being granted root via a dialog which a user cannot truly ever revoke or undo the consequences of granting beyond a reinstall of the whole OS.

> I know your threat model demands that the stupid helpless users can never be allowed to control their device

The app accessible root frameworks you're talking about drastically reduce the privacy and security of the OS for all users including ones never using it to grant root access to an app. Granting root access to apps built with such disregard for following security best practices is also not somehow unproblematic because you think they're trustworthy since they're open source.

> but it does undermine the features that your OS can provide

No, it means we build features with proper implementations following security best practices instead of doing it with half-baked hacks via a massive portion of the OS having full root access and granting that to apps.

> I love pedantry as much as the next guy, but ROM has not meant read-only memory in like 20 years.

It means read-only memory in embedded, information security and in the context of GrapheneOS which is an overlap of both. GrapheneOS works on security including boot security where it's very relevant. When someone says ROM recovery in the context of GrapheneOS, that means the boot ROM recovery mode loaded when firmware on the SSD can't be loaded. It does not mean the OS recovery mode. It's not correct terminology to refer to GrapheneOS. It propagates unnecessary misconceptions and confusion.

> So, you're trailing, say, Debian, and have done for years, and have at most a plan for someday being able to compete.

No, it doesn't provide a similar backup system portable across devices and major OS versions.

> So when you wrote "GrapheneOS and other secure options", you just meant GOS because nothing else matches your definition of security. Again, I don't exactly mind that, but it's disingenuous to gesture at other options that don't exist.

No, our response said the apps should set a security standard and enforce it fairly. They should not enforce Google certification but rather define the standard security expectations and permit anything meeting them. GrapheneOS is much more secure than any Google certified OS, so it would meet actual security standards they set. Whether other alternate operating systems meet those standards depends on what the app developers set as the requirements. Many Google certified operating systems won't meet reasonable security standards and would need to be banned if the enforcement is fair.