alt Hacker News>> Android has existing apps.
> Android has a massive app ecosystem including the largest open source mobile app ecosystem. Those apps are nearly entirely available for GrapheneOS. Very few apps are unavailable for GrapheneOS. It's nearly entirely banking and government apps, but as we said 90% of those work on GrapheneOS.
> AOSP and GrapheneOS have hardware-based virtualization usable to run desktop Linux software. It even provides opt-in GPU acceleration with gfxstream and will likely have native GPU virtualization support similar to NVIDIA's paid vGPU in the near future. AOSP and GrapheneOS have a very usable desktop mode which will be getting much better. Android is replacing ChromeOS and was already heavily improved for desktop use as part of being included within ChromeOS. We have that app ecosystem available too.
There was really no need to write 2 paragraphs to agree with me.
>> the existing apps largely do run on other Linux systems via waydroid
> A large portion of Android apps do not work via Waydroid. It has drastically lower compatibility than GrapheneOS and there are fundamental issues with how it approaches it.
What is a "large portion"? It's worked fine for me but I suppose if you have hard data that might be meaningful. Could you describe the "fundamental issues"? My impression is that they just run the whole Android userspace in a container, which seems like a reasonable approach.
> The approach they take also severely harms privacy and security through throwing away most of the privacy and security model used by Android. That would not be the case for running AOSP in a hardware accelerated virtual machine, which is what we would recommend doing. It would still have greatly reduced compatibility due to apps using hardware APIs such as the hardware keystores and many apps actively trying to stop themselves being run in a virtual machine or other weird environment. It would work a lot better than using namespaces but would require modern hardware with virtualization acceleration.
Again, I know security/privacy is your talking point, but this isn't actually the argument at hand.
>> apps refusing to run on non-stock systems are likely to refuse GOS as well
> A very tiny subset of overall Android apps entirely ban using a non-Google-certified OS. Most only have checks for the security model being intact and anti-tampering code interfering with running the apps in an atypical environment. We run into these issues with our privacy and security hardening features so we've done a lot of work to maintain compatibility.
So, yes.
>> GOS is supported by some apps that would refuse other non-stock systems.
> GrapheneOS exceeds all of the security and attestation expectations of these apps. They have no reason to ban using it and we make sure to avoid that being the case. It's only a tiny number of apps banning using GrapheneOS in the first place and a growing number of those are beginning to permit it since they don't actually have a reason to ban it. They do have a reason to ban an OS not providing the security model and attestation functionality they want. We disagree with attestation being used this way, but they can do that while supporting GrapheneOS and a growing number of these apps are doing so.
Which is a lot of words to agree that yes, many apps only allow stock and therefor block you just like any other OS.
>> yes you're probably ahead
> GrapheneOS provides drastically better compatibility.
I'd like evidence for "drastically", but again we mostly agree.
>> waydroid is also 90% AOSP
> It's a fork of outdated LineageOS with a compatibility layer to make it run as part of a non-AOSP host OS. It has SELinux disabled which means the app sandbox and other protections aren't intact along with many other major differences. Apps can see these differences and many apps ban it because they can see the security model isn't intact or detect what's happening as a form of tampering.
Right. So it's 90% AOSP. Old AOSP with worse security properties, but for compat purposes that's not important.
> In practice, GrapheneOS only gets banned by services enforcing the Play Integrity API device or strong integrity level without permitting GrapheneOS via hardware attestation. A growing number of apps are permitting it since they don't have any real reason to ban it. It's easy for them to stop endless negative reviews and customer support complaints from GrapheneOS users by simply implementing Android hardware attestation with Google's open source library for it and permitting GrapheneOS. They can also simply delete the code banning using non-Google-certified operating systems which is what we'd prefer over them hard-wiring permitting GrapheneOS and specific other alternatives.
You and I have different impressions of how apps approach attestatoin.
>> yes GOS has gotten some buy-in, but if 90% is good enough
> That was only about banking apps. Over 99.99% of overall Android apps work on GrapheneOS. The vast majority of apps are not banking or government apps.
And most apps work on waydroid. Of course the apps that go out of their way to block non-stock are the pain point.
>> compatibility as your advantage
> It has an immense compatibility advantage along with far better privacy, security, usability and battery life.
(You've carved out 3 words in a way that doesn't make sense alone; this is part of either the previous or next bit)
>> Basically, either users want 100% app compat - in which case GOS is out - or they don't, in which case waydroid is likely to be an option
> Most users have 100% compatibility since most people don't use the around 10% of banks banning GrapheneOS. Our userbase is also growing large enough that apps cannot ban using it without it being a huge hassle for them. They have no actual reason to ban it, so that's why a growing number of apps are removing the ban on using it. They're usually not willing to stop using the Play Integrity API but once this is on their radar due to complaints they often become willing to implement using the Android hardware attestation API to permit GrapheneOS and other alternatives meeting their requirements. It's not a full solution since it won't allow people's self-signed builds or forks of GrapheneOS but it's progress and it enables the apps to easily permit more operating systems in the same way. They can just add more to their list. We would prefer the Play Integrity API being banned by regulators but this is good enough for now.
90% of the time, it works 100% of the time. Anyways, you aren't 100% compatible, so my point stands.
>> since GOS is missing vitally important features compared to other Android ROMs let alone "normal" Linux systems
> GrapheneOS has similar functionality to mainstream Android smartphones. We highly prioritize providing missing functionality not available through apps.
I'm not comparing to stock, and you refuse to give apps root access so the shortcomings that they can fix are limited. (Yes, I know your threat model demands that the stupid helpless users can never be allowed to control their device. That's actually defensible if security+privacy is your #1 goal, but it does undermine the features that your OS can provide.)
> GrapheneOS is an operating system, not read-only memory firmware. There's a boot ROM which loads the main boot firmware from the SSD, verifies it and transfers control to it which then does the same with the OS. GrapheneOS is simply a regular OS installed on an SSD. Verified boot protects it from modification but it's not in read-only storage or anything like that. We don't misuse the term ROM to refer to it and prefer if others avoid it too.
I love pedantry as much as the next guy, but ROM has not meant read-only memory in like 20 years.
>> how long has GOS been without full backup functionality now?
> GrapheneOS has much better backup support than the stock Pixel OS and most Google Mobile Services Android devices.
> GrapheneOS has a built-in encrypted backup system. It backs up the same data as Google's device-to-device transfer for moving between Android devices. Every app targeting Android 12 or later gets backed up since allowBackup="false" was redefined to only disable cloud backups. Every Play Store app has been required to target Android 12 or later since under a year after the release of Android 12. The issue of apps opting out of backups has been in the past for years.
> Backing up more of the system settings and other system data is planned and requires gradually expanding what gets converted into a portable format transferable between devices and OS versions.
So, you're trailing, say, Debian, and have done for years, and have at most a plan for someday being able to compete.
>> What other secure options are those?
> It's up to these companies to define their security requirements. GrapheneOS is far more secure than anything permitted by the Play Integrity API device or strong integrity levels. It supports hardware-based attestation and we publish a signed JSON object providing our verified boot key fingerprints for use with it. They can easily use that and permit GrapheneOS. Other operating systems preserving the Android security model can do the same. Once they allow GrapheneOS, it's easy for them to allow more in the same way. It would be nicer if they stopped using the Play Integrity API and left OS security up to users but most of these apps are not open to doing that. A small portion of apps adopting the Play Integrity API didn't understand what it does and are willing to stop.
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.
> 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.