>At the time of writing, within ~12 months, in 2027, the 2027 Signature, Razr fold, and Razr flip will meet the hardware security requirements and should have official GrapheneOS support. Motorola is currently porting GrapheneOS to their devices.
I have a Moto G running LineageOS and it's my favorite phone ever. The ability to have my 800GB of music synced to a sdcard is something I'm loath to give up.
Snapdragon 8 Elite Gen 5 is the first Qualcomm SoC with hardware memory tagging (MTE). MTE isn't even available on the slightly lower end Snapdragon 8 Gen 5. A lot of the SoC security features are segmented based on price and only the flagship SoC platform has everything we need. Snapdragon's upcoming next generation SoC is the first truly providing everything we need. There's still a lot of work to do since providing the features on paper is different from having those fully integrated to match what we have on Pixels.
I'm one of those people who is affected by PWM on OLED screens. I tried a Pixel 9 Pro XL and it didn't work for me. Have a Razr 2024 which mostly works and that's thanks to some custom PWM settings from Motorola.
Will Graphene OS have these custom PWM mitigation settings on 2027 Motorolas?
I think I'll buy one of those new Motorolas with GrapheneOS just to hopefully vote with my wallet a bit, and make them port it/use it for more phones in the future, which just maybe might eventually be a "normal" sized phone again.
Snapdragon 8 Elite Gen 5 is the only current Snapdragon SoC with hardware memory tagging since even the slightly lower end Snapdragon 8 Gen 5 didn't provide it due to being developed a bit earlier despite being launched later. They tried to provide it for both but didn't get it fully working in time. The next generation makes major secure element improvements. We potentially could have supported a Snapdragon 8 Elite Gen 5 with a secure element from another company but there wasn't enough time and the next generation is a lot better in multiple ways. There's still a large amount of porting and integration work remaining to do.
> Lower end devices will take more time to meet our requirements since the updates and security features aren't as good. It's mostly due to how Qualcomm handles it. The latest Snapdragon flagships have the best security features. We'll also need Motorola to start paying them for longer updates below flagships
I got stuck in Spotify for new music but that obviously doesn’t work long term
I'm using syncthing to avoid the chore of having to copy them into my SD card
As for acquiring music, I use Bandcamp. If they aren't on there, I'm not above finding it via file sharing.
I have a bunch of python scripts that help me rename all my files once I get their tags sorted out. For that I mostly use AudioRanger because it's so simple and I only process one album at a time.
From there, I use Syncthing. But I'm thinking about replacing it with rsync and just kick it off manually when I want to update everything about once a month.
For playback, I mainly use Navidrome.
For autotagging and importing (moving files), Beets.
For tagging edge cases, MusicBrainz Picard as the GUI and the Python tagging lib underneath it (mutagen iirc) with an LLM inside the pi cli agent for automation.
For format conversion and copying to portable devices, ffmpeg in custom bash scripts managed by an LLM.
Expandable storage is priceless to me and the main reason I opt for this product.
We think folding devices are a lot more useful and likely to get more users but we already have those via Pixels so flip devices are compelling as a new form factor. We're also interested in having support for new tablets.
I've never really tried a flip but it does sound cool.
It will be highly unlikely that they modify the hardware exterior look for GrapheneOS.
* before replying snarkily that Android is Linux, please take a long walk off a short pier, thanks
We have waydroid for that.
> You can't have a bank account on a Linux phone* because they won't let you, but you can on Android including on Graphene.
Unless of course it uses those stupid integrity apis to block anything that isn't stock.
https://privsec.dev/posts/android/banking-applications-compa...
Moving to a far less private and secure desktop software stack is going in the opposite direction from GrapheneOS. GrapheneOS doesn't exist to simply provide an alternative to mainstream operating systems but rather to offer much better privacy and security. We wouldn't be doing that if we were forking a desktop Linux environment and doing similar work for it. It would be nowhere close to the privacy and security of simply using an iPhone. That's a major part of why GrapheneOS is based on AOSP rather than it solely being about compatibility.
Desktop distributions are incredibly far behind on privacy/security and lack any clear path to achieving the same things. Every year, Android makes backwards incompatible privacy and security improvements as part of a new target SDK version. Android retains compatibility with legacy apps, but apps distributed through the Play Store (and other app stores to an extent) are required to move to the new target API level within around a year. This results in apps being forced to conform to a gradually improving privacy and security model. There's no such thing for desktop Linux apps but rather apps choose how much they want to participate in nascent sandboxing efforts.
GrapheneOS has near perfect compatibility apps from the Play Store via our sandboxed Google Play compatibility layer with the exception of banking and government apps. 90% of banking apps currently work on GrapheneOS because it greatly succeeds all of their security requirements and is only wrongly banned by a subset of those apps. These apps are gradually adding more anti-tampering and attestation checks for the hardware and OS, so maintaining compatibility has required us to gradually add more functionality working around it. We've also had to actively convince apps to stop banning non-Google-certified operating systems or to permit GrapheneOS and other secure options alongside doing it. A growing number of apps are choosing to stop banning using GrapheneOS due to pressure from our expanding userbase.
Waydroid uses namespaces and a compatibility layer to run an outdated fork of LineageOS. It's far from providing full functionality and compatibility with apps and nowhere close to the compatibility provided by GrapheneOS. More importantly from our perspective, Waydroid disables most of Android's standard privacy and security model through not supporting SELinux and other core parts of the security model. Android doesn't simply use SELinux as an additional layer of security with targeted policies but rather it's deeply integrated into the OS. It uses very strong whole system policies to implement the app sandbox, drastically reduced kernel attack surface and a lot more. Namespaces for the overall userspace environment are not a replacement for the app sandbox, kernel protections, verified boot and the rest of the security model.
1. Android has existing apps.
2. A subset of existing apps will refuse to run on various shades of non-stock/unofficial system.
I pointed out that 1. the existing apps largely do run on other Linux systems via waydroid, and that 2. apps refusing to run on non-stock systems are likely to refuse GOS as well.
If I cut down your page of text to the relevant points, I believe it amounts to:
1. GOS has better app compatibility than waydroid.
2. GOS is supported by some apps that would refuse other non-stock systems.
3. GOS is more secure/private. (This is unrelated and should at most have been a reply to the root comment.)
On 1. compatibility, yes you're probably ahead, though I have to question how much since waydroid is also 90% AOSP. Somewhat similarly on 2. yes GOS has gotten some buy-in, but if 90% is good enough, then again you shouldn't be holding up compatibility as your advantage over waydroid. 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. Point 3. is irrelevant to the conversation, and you probably don't want to start an argument about general features since GOS is missing vitally important features compared to other Android ROMs let alone "normal" Linux systems (how long has GOS been without full backup functionality now?).
> We've also had to actively convince apps to stop banning non-Google-certified operating systems or to permit GrapheneOS and other secure options alongside doing it.
What other secure options are those?
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.
> 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.
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.
> 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.
> 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.
> yes you're probably ahead
GrapheneOS provides drastically better compatibility.
> 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.
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.
> 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.
> compatibility as your advantage
It has an immense compatibility advantage along with far better privacy, security, usability and battery life.
> 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.
> 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.
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.
> 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.
> 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.
Unfortunately, the EU is currently developing their age-verification-app, and it mandates hardware attestation[1], and it seems that their reference implement those requirements using Play Integrity[2].
[1]: https://news.ycombinator.com/item?id=49148128 [2]: https://github.com/eu-digital-identity-wallet/av-doc-technic...
Regulators should force Google to stop further closing up Android and to permit alternate operating systems to pass the Play Integrity API device and strong integrity levels. It should not require certification by Google and complying with their arbitrary requirements based around their business model. There should be another path to obtaining certification without Google's involvement where Google has to respect it and permit those devices and operating systems to pass. Most important is stopping them from closing things down more against the original terms they provided Android and gained market share with it. Next most important is a reasonable path to alternatives passing the Play Integrity API based on security standards which do not block updates while waiting for certification.
We don't think it's realistic to stop apps adopting attestation but people should try regardless. A single country with a large market banning would make a huge difference.
https://grapheneos.org/articles/attestation-compatibility-gu... is our guide for app developers on permitting GrapheneOS via hardware attestation. Other operating systems can publish signed keys in a similar way to enable easily supporting them once this is implemented. An organization certifying operating systems could collect these and sign an overall list. It would also be possible to support a broader hardware ecosystem with alternate roots of trust by providing a signed list of those too. This is not the future we want but it is the future we believe we can obtain through a lot of pressure. We would greatly prefer apps not making an allowlist of operating systems. People should be able to make their own GrapheneOS build and use the same apps.
It's not a very good guide, frankly. It's basically a wall of text without clear instructions on what to do, besides "look at the examples Google gave". And even looking at Google's examples, there are no examples or explanations that tell me how to download the list of allowed signatures, and what should I do with the Json schema.
> 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.
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.
You've given me hope for the future!
What security problems does waydroid have that a VM wouldn't?
Waydroid uses an outdated fork of LineageOS running with namespaces and a compatibility layer on top of a much less private and secure base OS without similar kernel or userspace security protections. Running up-to-date AOSP in a virtual machine would at least be able to preserve the internal Android privacy and security model for apps to protect apps from each other and the OS from apps. It would also contain the overall OS within it too. Using the much less private and secure OS as the host OS with full access is quite backwards from a privacy and security perspective but would be a huge improvement.
AOSP is much more private and secure than traditional desktop Linux distributions. Moving to that software stack is inherently going to be moving much further away from competing with the privacy and security of iOS. The direction taken by GrapheneOS is to start from AOSP and greatly improve the privacy and security it provides to compete with and exceed the industry standard privacy and security provided by iPhones. That requires more than only software. Hardware and firmware security are very important too. Software security also increasingly depends on hardware-based security features such as hardware memory tagging, hardware control flow integrity protections, hardware-based virtualization and much more.
Keeping user data safe from access via encryption also depends on hardware security features for the vast majority of users not using a very strong passphrase. People take it for granted that they're going to have secure data via disk encryption with a random 6 digit PIN but that's not the case without a good secure element and OS integration with it. The approach used by desktop operating systems with TPMs is awful and makes security worse in a lot of ways rather than better. It's not at all the same thing, similarly to how what the desktop world calls secure boot is not a serious or complete implementation of it and doesn't provide nearly any useful security properties to end users unlike iOS or AOSP.
Interesting. Could you elaborate? I always thought that Secure Boot is reasonably secure (provided you can set it up in the first place).
Secure boot was widely used as a term prior to the UEFI usage of the term including many much more meaningful implementations. The term verified boot refers to the same concept but avoids it being confused with solely verifying a late stage bootloader and OS kernel from UEFI firmware.
Soon, there won't even be an alternative flow. There are a lot of places where there already isn't.
However at that point you'll likely pay for the privilege.
Its app is really nice and native, though. That, along with a decent interest rate, is why I use it.
That would be inconvenient if this was 1985.
The "security module" they require you to install on your computer. In the past, when browsers had plugins, this was a browser plugin; nowadays, it's an always-on service (running as root) which exposes a local HTTP server which the bank site connects to to validate your computer. For an example from a major bank in this country (the same "security module" is used by several banks in this country), https://seg.bb.com.br/home.html is the diagnostic page for that "security module" (the FAQ page there has links to the installers).
The relevant regulations are Commission Delegated Regulation (EU) 2018/389 and the earlier Directive (EU) 2015/2366.
While these laws are deliberately vague when it comes to specific technologies, they do require at least two independent factors from different categories, such as knowledge (password) and possession (phone).
That, in and of itself, wouldn't be a problem. The way most banks implement it, however, is by giving you two choices:
1. You use their mobile app (which likely requires device attestation and Google Play Services, so won't work on a plain LineageOS install)
2. You use their CardTAN device, which is extremely inconvenient to always carry around.
Sure, we nerds might argue they should just let us use our Yubikeys or regular old TOTP, but pretty much no bank implements that. (Why? Your guess is as good as mine.)
Personally, I had to buy a second stock Samsung phone just for banking apps. And yes, there are still alternatives (only very very few though), but no, none of them are convenient, for various unrelated reasons.
I wouldn't be surprised if this continues to spread to the US too, under the sneaky disguise of "security".
In reality, most of time it's just a matter of choosing the right bank wherever you are. I'm writing this on a GNU/Linux phone that does my banking just fine. I'm from the EU.
crying in EU :(
This is a social issue - not a technical one.
Source: my bank which recently 'upgraded' a browser version to a glorified SPA which even renders as a vertical oriented app on a landscape 4K monitor.
For eg. There's no browser based alternative to make UPI payments that i know of.
It's not just for clients with no smart phones. It's also clients who activate developer mode on their smartphone etc... clients who use VPN. Clients who run AdBlocker. Clients who use Firefox.
There needs to be a severe push back against this.
Things have gotten so crazy that the homeless here are walking around with QR codes printed out when begging for money. I'm guessing they're a network of people who share the same smartphone/payment method..
Or in other words: of course you can have mobile bankid without a smartphone, just use a tablet computer ;)
Well, I can buy a train ticket without it, so I could still leave.
I wonder why there would be such a difference in policy between countries, not only in government but across the private sector? This doesn't make any sense to me. If anything, I'd expect Sweden to have a more sensible, left wing attitude than Oz.
A pure linux non-android phone would be great however you wouldn't have access to properly working apps and would not be able to participate in modern society.
Anyone getting BMW digital keys to work on Graphine OS?
Almost none support strong dedicated HW authenticators or second factors. Not even as an option to those who care.
Anyway it's always possible to just reverse their web api and use it directly. 2FA that consists of copying some code from SMS is no barrier, especially not on the Linux phone that you fully control.
I should make a chip called Super Security Sauce Silicon, and make cards with them, and market them to phone vendors so their customers won't need the card, and market them to banks so their customers will be secure. It performs Dual_EC_DRBG with my keys.
That said, I think wasi containers support for a mobile OS would be a game changer.
(^ Here's a startup idea if you're looking out for one. I for one throw out all my devices from the balcony to get this)
I haven't figured out how to make them talk with each other though. I imagine that's the place where I'd notice this lack of support.
It seems not all of them, and that things will only get worse if recent news comes true.
If any of the Motorola devices have GOS as a pre-installed option, now the companies don't have the excuse that the device is modified.
I'm guessing the companies will continue to be difficult, but it'll be amusing to watch, at least.
They surely must have gotten feedback from me and others because the next update it worked again. But I and probably others where already a lost customer.
Why can't the prescription be sent to email or collected on a website? I don't see why an "app," especially one signed by Google is necessary for something like this. It wouldn't surprise me if the app requested location or sensor access in order to provide a "personalized experience."
Linux crowd can not even agree on compositor, and if systemd or sudo is a good idea.
This is actually a feature.
I think "linux smartphone" would end up looking very similar -- some UI on top of a kernel with a very non-LSB userspace; therefore the concept is really not all that compelling
But take that far enough and you get Stallman'd into a corner where someone points out that's great, but no phone for you.
Especially in this political climate it’s insane to recommend people switch to a phone OS that can be pwned via hardware or software means in virtually zero time versus something like GOS + a Pixel or an iPhone.
The hardware and software security of Android/iOS/iPadOS/GOS devices are leagues ahead of Linux servers in all aspects and it’s not even close (but they also serve different purposes so to some extent I’m not sure how 1:1 this comparison is). However, this discussion focuses on desktop style Linux distros which is what these phones are running which have inadequate security. Desktop Linux is inferior security-wise to a server environment where each process/app is running as it’s own user etc. Desktop-style Linux phones also have virtually zero hardware security versus the alternatives.
It doesn’t matter if a user knows what they are doing. For example installing so-called “trusted” apps means they’re only trustworthy at that moment in time and not forward-looking. All it takes is one supply chain or runtime security exploit. Software security is also extremely poor with a lack of comprehensive sandboxing and so on, I would just read the grapheneos accounts replies on here since they’re writing entire novels on this.
I mean even GrapheneOS shows how relevant this is with Samuel Tunick, on the front page today. If he’d had a desktop Linux phone that was seized from him while in AFU, sure it would be “private” but there would be virtually nothing stopping officials from running through his entire phone since so many of these desktop Linux distros rely on poor security elements if any on top of FDE with LUKS so your entire device is basically exposed and unencrypted after the first unlock.
This whole comment was borderline stream of consciousness so I apologize if anything is unclear here.
Leaving phones behind on old incompatible OS versions 2 times in 3 years and switching app frameworks 3 times in 4 years does not a good app developer experience make.
Piled on top of that, Google became actively hostile to 3rd party developers building support for YouTube (and Gmail and Gmaps, but those had workarounds / alternatives).
The advantage being, we can manage packages using a regular Linux distro
Drivers doesn't just mean the kernel. It's the user space binary blobs and services that need to talk to the kernel to enable the hardware.
Other than that there's waydroid, alien dalvik etc.. that run another Android instance in a container.
The thing is a lot of Android applications use safety net/other methods to make sure they only run on. "Approved"/stock hardware.
> The advantage being, we can manage packages using a regular Linux distro
It's much easier, more plausible, and more logical to sandbox a regular Linux package-managed distro inside of Android, which numerous solutions exist for.
Google thought about this, don't worry. They learned their lesson after CyanogenMod tried to compete by offering an alternative. Non-Google Android are now dead except in China.
In principle I agree about a Linux phone, but the gaps are much greater. I am also sympathetic to the GOS team's arguments that sandboxing on Android is better, and important on a device that allows control of essentially my whole life (2FA apps etc.)
We provided a much more detailed reply at https://news.ycombinator.com/item?id=49364220.
There is still a philosophical reason for supporting a version of Linux for mobile devices that is not dependent on Google, but is community-driven, for users with different priorities.
That is not really relevant to the GOS project though, and the fact that GOS is probably the easiest way to get a Play Services-free mobile device kind of drags it into discussions that it doesn't necessarily belong in.
Again, thanks for your work, and I appreciate your team's focus on your goal of the best security possible.
in China - there's no google apps available on their 'android' versions.
their platforms are already performant and fluid - so people should build on that.
Also if we use atomic distros with flatpaks and whatnot that mimic Android security the end user basically ends up having to essentially use Termux (but busybox or something similar) on their Linux phone as well
GrapheneOS makes our own major improvements to the permission model, but we cannot enforce apps adopting it and need to design it all to be backwards compatible. We do that for Contact Scopes, Storage Scopes, our Sensors toggle and other features but not everything can be done that way. For our exploit protections, we have toggles to work around apps with memory corruption bugs or bad practices such as dynamic code loading. Android can enforce apps improving in a way we can't do. We're starting from a platform with a mandatory app sandbox and relatively modern exploit protections though. Android also does support using hardware memory tagging or HWASan to test apps even though many developers aren't using those to clean up their memory corruption bugs.
You could be dividing up your projects into highly sandboxed environments on Android too. It has support for running multiple hardware accelerated virtual machines running desktop Linux and it wouldn't be that hard to support creating those with NixOS and other distributions instead of only the standard the Debian images provided by Android. That will happen as it gets more mature.
See the explanation at https://news.ycombinator.com/item?id=49364220 for why desktop Linux is nowhere close to AOSP for privacy and security. If you want more details, there's a lot of deeper coverage.
That is fine but obviously we are talking about threat model in comparison to each other.
>Google Play Services, which are needed
They are "needed" if you want to use other closed source apps that rely on play service feature. If you don't want/use closed source apps there is no reason to use Google play services at all, that's why they are optional.
>running with full access to all my data
GrapheneOS sandboxes play services specifically to run with user permission instead of system and can be used in a completely different isolated profile for your other private user data.
NixOS by itself does nothing to increase security outside of the supply chain. There is for example no default application sandboxing, Mandatory access control or hardened memory allocation (software or hardware). Just to name the most basic security feature.
GrapheneOS’ security model makes that of desktop Linux look like a joke.
This is an objective analysis based on x86 security, GrapheneOS hardening (including isolation and hardened mem allocator), Pixel hardware security.
It has much better adoption of modern exploit protections and far better testing with sanitizers for both the kernel and userspace. It enables us to do even better because most of the memory corruption bugs caught by MTE are resolved. We do still need to resolve more, but it would be far more impractical for us to do it on the desktop.
Android uses SELinux for both whole system MAC and MLS policies with deep OS integration. It uses it for a massive amount of kernel attack surface reduction with allowlists for socket protocols, devices, ioctl commands and other functionality. It's far different from the traditional targeted approach used by desktops or even rare use of whole system SELinux for desktops/servers. It's nearly a completely different thing in practice. The OS has it deeply integrated in userspace for enforcement beyond in the kernel and it's developed around it. It's the main basis for the app sandbox and a lot of other isolation in the OS. OS processes are specifically split up and have IPC set up in a way that they can be contained well with it.
The mandatory app sandbox with yearly backwards incompatible privacy and security improvements as part of new target SDK versions is the most important difference. It's the basis for GrapheneOS being able to do much better. Having the infrastructure it already has available means we can add our features such as Contact Scopes, Storage Scopes and our Sensors toggle on top. We plan to add a lot more, but there are also the yearly improvements we get in the baseline such as how Camera, Microphone and Location have supported one-time grants for years, can only be used while apps are in use once granted (with Location have an extra layer of background opt-in) and precise vs. coarse location.
People will tell you that chromium is "more up to date" as if Google wasn't the one setting the standards, making it impossible for anyone else to be similarly complete. Seems like we have a very similar problem here...
The existence of such a framework would make the various tradeoffs with going web-only sting less and make that the advantageous route, not just the cost-cutting route that it’s seen as now (and why those bad browser wrappers continue to proliferate).
It's almost like Android has put millions of expert dev hours into making it the most used OS in the world. Like GNU+linux on laptops only works the way it does because of android-upstreamed battery saver kernel features.
But a mobile is also people's most used devices with all of their data, bank accounts etc there - it has to be safe. And GNU+linux has not even a single thought about security, while android just has it worked out (every app runs as its own user, so it's even built on standard UNIX security).
A mobile OS also has to race to suspend and for that it needs cooperation from "apps" -- desktop apps just run, they don't care about anything besides SIGKILL. That's not a workable model on a mobile and android solves it.
And I say all that as someone who runs linux everywhere I can and I absolutely love it. It's imo the best kernel out there -- but the userspace is not where it should be and if anything, the correct question would be what can we take from Android and add to GNU+Linux. (And nix is fantastic, but it's a packaging solution, I don't really see how it comes into question here. I can run nix on my android phone just fine by the way)
As to your other userspace concerns... these are all solveable. Perhaps with some elbow grease, but devices like the Steam Deck prove that mobile linux isnt as much of a problem re: userspace as you claim.
Ed.: I'd also like to add that the fuss around security is _mostly_ Google propaganda. Android is not meaningfully more secure, _without application level changes_ than Linux.
> but devices like the Steam Deck prove that mobile linux isnt as much of a problem re: userspace as you claim.
SteamOS, very similarly to Android, entirely depends on a corporate benefactor leveraging a parallel user space that happily bypasses the "normal" community-supported parts of a typical Linux desktop distro wherever they present an obstacle. It proves that a company with deep pockets could indeed create a new mobile Linux distro (by writing lots of checks and cutting out large chunks of desktop Linux in favor of custom implementations entirely under their control).
Moving to a far less private and secure desktop software stack is going in the opposite direction from GrapheneOS. GrapheneOS doesn't exist to simply provide an alternative to mainstream operating systems but rather to offer much better privacy and security. We wouldn't be doing that if we were forking a desktop Linux environment and doing similar work for it. It would be nowhere close to the privacy and security of simply using an iPhone. That's a major part of why GrapheneOS is based on AOSP rather than it solely being about compatibility.
Desktop distributions are incredibly far behind on privacy/security and lack any clear path to achieving the same things. Every year, Android makes backwards incompatible privacy and security improvements as part of a new target SDK version. Android retains compatibility with legacy apps, but apps distributed through the Play Store (and other app stores to an extent) are required to move to the new target API level within around a year. This results in apps being forced to conform to a gradually improving privacy and security model. There's no such thing for desktop Linux apps but rather apps choose how much they want to participate in nascent sandboxing efforts.
GrapheneOS has near perfect compatibility apps from the Play Store via our sandboxed Google Play compatibility layer with the exception of banking and government apps. 90% of banking apps currently work on GrapheneOS because it greatly succeeds all of their security requirements and is only wrongly banned by a subset of those apps. These apps are gradually adding more anti-tampering and attestation checks for the hardware and OS, so maintaining compatibility has required us to gradually add more functionality working around it. We've also had to actively convince apps to stop banning non-Google-certified operating systems or to permit GrapheneOS and other secure options alongside doing it. A growing number of apps are choosing to stop banning using GrapheneOS due to pressure from our expanding userbase.
Android is a large Linux operating system family. It's the mainstream form of Linux on personal computers. Android users are Linux users. For privacy and security, using a monolithic kernel written in C is definitely not a good thing. Doing much better than we are today partly requires moving away from so heavily depending on the Linux kernel for security. Android does a lot of Linux kernel hardening with attack surface reduction and exploit protections which are improved by GrapheneOS, but it's not enough. The massive torrent of severe vulnerabilities being discovered in the Linux kernel is going to get worse before it gets better and will remain a problem. Adopting hardware-based virtualization for isolation of apps and OS components including drivers is an important part of our roadmap.
You mean, a browser?
It's almost like the free market only works when we have well-defined and regulated markets. This has been known by Adam Smith and quite logical, yet people expect Google and Apple giga-corporations with monopolies to somehow abide by the laws of selling grains on the market.
No. This is the end state of any semblance of laissez-faire economics. Full stop. Massive accumulation at the top, power to those with capital, rags for the poorest.
Not in the mobile world no, it's not a free market by any means
(which doesn't mean there's not a lot farther from here).
Because there is no such thing as "mainstream Linux" when it comes to anything related to user-facing consumer software. Not on desktops, not on tablets, not on phones.
I mean you invoked "mainstream Linux" and "Nix" in the same paragraph. That alone should clue you into why this, absolutely, does not work.
See here is the problem:
https://wiki.pine64.org/wiki/PinePhone_Software_Releases
"Linux enthusiests" would rather muck around with rewriting the same software over and over and over again because they dislike using GTK or whatever, and put monumental amount of efforts making new package managers, then, say, getting the ability to take simple photographs using a phone camera.
I mean... In that page there is no less then 25 different "Linux Phone OSes" listed.
None of them actually work.
They are all going to be slow, they are all going to burn through battery life. There is no meaningful security to speak of.
If I handed a unlocked "Linux phone" to somebody and said "take a photograph of me"... The chances of that actually working is slim to none.
Meanwhile we have Android OS that is proven to work. It is open source. It is used by, literally, billions of people. The security model is as good as it gets. It has better application support then Windows.
Taking something that works and then making it more secure and more open and more privacy focused is infinitely more productive and meaningful then trying over from scratch because you want a phone based around Nix packages or whatever.
Even if Google decided to close source Android from now on and be actively hostile to any open source kernel modules... Forking the Android that exists today and trying to make it work is exponentially more likely to yield positive results then, say, starting on a Debian-based "Linux phone OS".
And Android can still use nix-pkgs if you really wanted to.
If by "mainstream" Linux you mean something like postmarketOS, I'd suggest you look up reviews or give it a try yourself. A few months ago, people were reporting a hard time placing a call, taking a photo, etc.
Out of nowhere, it received (along with other older phones) updates up to Android 16.
I wouldn't be surprised if the "sudden" update was just a side effect of Motorola preparing for Graphene to be released on these older phones.
https://www.androidauthority.com/lenovo-thinkphone-hands-on-...
Anyway I ended up buying a really good smartphone.. just not a graphene supported haha :(
Also this is really great collab from moto & graphene as more vendors will officially recognize Graphene as legit OS (legel/OEM is different concept). I heard month ago Volkswagen banned graphene, hopefully we we will see moving things in opposite direction...
Which still makes you wonder why Volkswagen is so keen on alienating what little is left of their customer base with completely stupid security theater.
The whole idea of buying something is giving people money for their (assumed correct) judgement, which then leads to desired artifacts downstream.
Why would anyone want a car app? Is being tracked by the car's telematics unit (cellular modem) not enough?
> Fairphones lack the updates and hardware-based security features expected by GrapheneOS.
Banking apps (e.g. Revolut) block GrapheneOS actively and many other apps too.
But it will be interesting times once they are out!
You've misunderstood something here. Revolut doesn't "block GrapheneOS actively". I'm running Revolut and most of my banking apps on GrapheneOS right now.
In my experience, there are two major categories of incompatibility:
- High levels of Google Play Integrity checks: app only works on releases of Android that have been allowlisted by Google. The only app that does this for me so far is McDonalds.
- Commercial root detection APIs: some of GrapheneOS' security features like "Secure App Spawning" trip root detection heuristics. This is the kind of incompatibility I usually run into for banking apps. You can disable individual features on a per-app basis these days to get around this.
It's not happening for everyone but unfortunately:
When Google acquired motorola, I was excited at the possibilities. When they sold Motorola off, I thought it a deeply unfortunate move.
With this announcement though, I am now seeing it in a very positive light. Given Google's current position, if they still owned Motorola I can't see this sort of collaboration with grapheneos ever happening.
Major kudos to the graphenos team! This is a huge milestone, a huge accomplishment, and a real world validation of the incredible work that you are doing. Thank you so much for everything you have done
This is not the way.
Lest you forget that modern computing exists because ATT built unix and then threw it out to the public, at speed, as they drove away from it as fast as possible. (Something about being an actual monopoly...).
There is at least one thing, on that list that I can almost assure you will be coming back (in concept and spirt) in the next 5 years. Likely open source, because google tossed it...
Meanwhile it has other very public and open winners: Golang, Kubernetes being two stellar examples of them not dropping something like a hot potato.
Google is already failing to provide the Pixel kernel drivers in the preferred form for modification. Their kernel build system uses Git commands but yet they aren't providing the Git repositories it expects to be there. They had to provide a repo metadata file as a workaround but it's not the same since the revisions of the code aren't set properly in the resulting build.
Google is arguably already violating the GPL. They're deliberately making it inconvenient and are adding deliberate delays through requiring manual handling of the requests.
> I just want to get rid of forms. Like, I never want to fill out a form again.
The opening line from this interview with Sameer Samat on the Google for Developers YouTube channel in June.
Ugh.
Also I can't believe it's been 10 years since they shut down Google Code.
What is the context for this? It's not clear from the linked social media post.
The Android kernel source code is in git: https://android.googlesource.com/kernel/common/
Plus there's a lot of other Android source hosted on Google's git servers: https://android.googlesource.com/
That's the mainline kernel. Actual devices use various LTS kernels, for instance the pixel 9a uses kernel 6.1[1], which was hasn't been updated in a year[2]
[1] https://wiki.lineageos.org/devices/tegu/
[2] https://android.googlesource.com/device/google/tegu-kernels/...
I'm not sure which one the latest update for the Pixel 9a is using, I have an older Pixel 8. When I look at the Settings -> Android Version I can see it's using a build from January 2026 (also 6.1).
This is how a multibillion company that benefited infinitely from open source pays back.
Person B: Well, it didn't go away, they just changed the access method to Google Drive.
Saved us that conversation here, Thanks. No matter what mental gymnastics we may do, it is pretty clear where this is heading.
On a different note, the source download form requires you to accept Google's privacy policy for the information you submit.
Is it ok to tack on accepting additional policies as requirements to access what is allowed under OSS licenses.
Technically this is because a lot of apps thumb their nose at the requirement to have safe areas around swipeable elements in their app, but as a user, that is not my problem to fix. It's Google's.
The workaround is so ridiculously easy too: only allow backswipes to count in the lowest 15% of the bottom left of the screen. Yet despite having hundreds of engineers earning ±350.000 per year work on this problem for years, they haven't been able to either implement or even think of it.
The real fix would be to deprecate the three button layout in Android 18 and remove it in Android 19. Force apps to comply.
Also, I have 6GB of RAM in my phone - switching from a browser to youtube, or vice-versa, should not cause the other to clear and start back again from a freshly-loaded state.
350,000 a year and people can't even get basic things to operate properly. Google needs broken up and their engineers need to go back to the 90s and learn some real programming skill.
I use an Android tablet and I only backswipe at the upper left.
edit: they have X but didn't post it there https://x.com/GrapheneOS
They have official chatrooms on Matrix and Discord and a forum on their website. They have unofficial (but run by them) chatrooms on SimpleX and Telegram and maybe other platforms idk.
They are not about avoiding big tech specifically, they make practical choices to improve privacy and security of their users.
Here's a statement with some ethos.
I would legitimately change my phone (+watch +headphones) for a vertical foldable (like razr) phone running graphene OS. I don't think Apple is releasing a vertical foldable or even a modern smaller phone. One can only hope.
Ente Photos
NotesNook
Signal (I use Molly but it's only on Android)
Bitwarden
Proton
90% of banking apps do already work on GrapheneOS:
https://privsec.dev/posts/android/banking-applications-compa...
A growing number of the apps banning using GrapheneOS are choosing to start permitting it. A small number of apps are permitting it by relaxing their Play Integrity API checks but most aren't willing to do that. A growing number of apps are implementing support for standard Android hardware attestation and permitting the GrapheneOS verified boot keys with it. We provide a page guide explain how to do that:
https://grapheneos.org/articles/attestation-compatibility-gu...
Our partnership will Motorola will help get the apps banning GrapheneOS to start permitting it through GrapheneOS becoming more mainstream and eventually being considered the stock OS on certain device variants.
Revolut for example works but many other banking apps rely also on high level of play integrity, as you describe.
I wish ppl behind this fantastic os strong nerves, you fight our freedom. Its appreciated.
My two requirements for a device are:
* Being able to pay for stuff
* My blood glucose sensors work (Librelink)
If they worked on a dumbphone, I'd have a dumbphone.
90% of banking apps do already work on GrapheneOS:
https://privsec.dev/posts/android/banking-applications-compa...
> If they worked on a dumbphone, I'd have a dumbphone.
A dumb phone won't provide any form of secure calls or texts. People should migrate away from carrier-based calls to the extent possible rather than towards it. A dumb phone is also entirely reliant on cellular instead of being able to use Wi-Fi instead.
"The initial devices with GrapheneOS support should be available in 2027. The initial devices will be flagships so they'll be higher end hardware than Pixels at a higher price. Lower end devices will take more time to meet our requirements since the updates and security features aren't as good. It's mostly due to how Qualcomm handles it. The latest Snapdragon flagships have the best security features. We'll also need Motorola to start paying them for longer updates below flagships."I'm not selecting which phone I buy on whether the stock OS comes with lockscreen shortcuts. At best, a software requirement someone might use as a deciding factor is OS support and bootloader unlock. The real differences are in hardware: size, battery life, chipset speed, RAM or other local model enablers, picture quality (this part also depends on good software to be fair), included accessories, satellite connectivity hardware, headphone jack, gimmicks like UWB or FM radio support, whether it's a flip/fold phone, storage space / sdcard support... all hardware differences
If only this were true. Samsung makes arguably the best hardware, but I refuse to buy a phone with Facebook pre-loaded and unremovable, a second (worse) app store preloaded and unremovable, and a bunch of redundant samsung-branded copies of the google apps. The best android images are as close to vanilla AOSP android as possible -- this used to mean Sony or Google branded phones, except Sony doesn't really market phones in the United States anymore and the Pixel phones are diverging from AOSP
Not to defend Samsung specifically, just that most phones' software is fine after a bit of setup whereas you can't download more RAM (don't believe the scams that are out there! :P). Even on Huawei I remember there were some things better than on stock but forgot what specifically (the only thing that comes to mind was a lockscreen menu that you could open with a gesture and I used all the time)
Apropos Sony, that was the only brand where I kept having issues because my mom, who had the phone, constantly had questions about what to do with some notification that the OS was pushing and we couldn't get rid of. Basically product ads, iirc to try this-or-that app or function
I do get what you mean about bloatware, just that it's more of a tie-breaker (saving you an hour of debloating, assuming you stay on stock) as compared to the permanent differences in hardware capabilities
They could make more parts of Android closed source, even critical ones without which you cannot realistically build an Android phone. It could, however, trigger anti-trust lawsuits, but my guess is they're willing to risk that. I mean, worst-case they only have to rollback to what they already had and maybe pay a fine.
Sure would be nice to have phones that can be rooted, or OS replaced. I've been hopeful this would perhaps enable that, but I fret my excitement may be premature.
Besides, GrapheneOS would probably don't want to get into a situation where their keys are burnt into hardware non-modifiable. They had to revoke such a key once in order to protect their users (against an attempt to hijack the project).
I seem to remember that I have read mentions of GrapheneOS for years now, but does this news mean it has been practically vaporware the whole time? Google making Android a walled garden just as bad as iOS shows how important projects like this and its siblings are. I'm impatiently waiting for more Jolla phones to become available, but something like GrapheneOS might be a viable alternative.
Thanks to everyone who worked so hard to get here.
Are there European countries that actually force, cf. coerce, banking customers to purchase mobile phones and run corporate mobile operating systems
https://en.wikipedia.org/wiki/List_of_countries_by_mobile_ba...
https://sqmagazine.co.uk/mobile-banking-statistics/
One approach is to use one phone (A) for banking and other commercial transactions and use another phone (B) for everything else, e.g., personal communication with friends, family, etc.
Phone A can run corporate mobile OS
Phone B can run alternative OS
Arguably, the data collection, surveillance and advertising exposure when using phone A is tolerable if that phone is only used for banking and commerce
The problem arises when someone tries to use a single phone for every general computing purpose
If that phone is running a corporate mobile OS, then that may expose the owner to an excessive amount of data collection, surveillance and, potentially, ads
Our hardware requirements are listed here, but our features also need to be ported to the hardware such as getting hardware memory tagging working for the whole kernel and userspace:
right now if you have it with you graphene just needlessly raises suspicions, its unjustified but thats what it is
On Pixels, GrapheneOS isn't the stock OS and therefore the devices show a notice each boot with the fingerprint of the non-stock verified boot key. This is a standard security feature on the hardware and something we require to be implemented. Verified boot itself is extremely useful for protecting against both physical attacks such as data extraction and also persistence for remote attacks. The verified boot notice provides a way to verify GrapheneOS is genuine without trusting the computer used to install it. The verified boot key is stored in the secure element along with the OS version for downgrade protection. It's enforced automatically so it's not as if people need to manually check the fingerprint each boot, but it does have value in protecting against tampering despite this. It's a feature we want to have on our own hardware too, although GrapheneOS can eventually be considered the stock OS without the verified boot notice.
GrapheneOS is also clearly installed on the SSD. Every block of the data partition is encrypted on storage but the firmware and OS images are public knowledge and verified through verified boot rather than being encrypted. Putting another boot stage before the OS in order to encrypt the publicly available OS images wouldn't achieve anything since that would identify it as being GrapheneOS itself. The only way to hide the OS would be if the hardware itself had a firmware-based passphrase prompt and the first boot stage of the installed OS was encrypted along with the verified boot key in the secure element being wiped when unlocking. It would be possible to provide, but that would be specialized hardware and therefore it could be identified based on the hardware instead of the software.
The stock Pixel OS isn't designed to be able to be installed alongside other operating systems. It assumes it's the only OS and handles updating both the firmware and itself via the A/B slots. It would be entirely possible to have a main OS in those A/B slots responsible for updating the SoC firmware and acting as a bootloader for other operating systems. That would clearly be there on the SSD if that's looked at and would show the verified boot notice every boot.
Having looked at some low-end Motorolas recently, this is accurate (albeit an understatement!)
This somewhat indicates to me it will be available when the Motorolas release which should be on their regular release patterns. That's been May for the 2025 and 2026 Razrs.
https://www.motorola.com/us/en/p/phones/razr/razr-ultra-2026... is the Razr Ultra 2026.
Maybe this will lighten the price on the Pixel 10's though...
Snapdragon 8 Elite Gen 5 is the first Qualcomm SoC with hardware memory tagging (MTE). MTE isn't even available on the slightly lower end Snapdragon 8 Gen 5. A lot of the SoC security features are segmented based on price and only the flagship SoC platform has everything we need. Snapdragon's upcoming next generation SoC is the first truly providing everything we need. There's still a lot of work to do since providing the features on paper is different from having those fully integrated to match what we have on Pixels.