GrapheneOS has been ported to Android 17
discuss.grapheneos.org
discuss.grapheneos.org
So I jumped straight to GrapheneOS, which was way easier and less extreme than I had been warned. So beautifully minimal, with no crap. Now my phone feels like a simple Linux (Void/Arch) PC. So wonderful.
Be careful, apps can still communicate with other apps, e.g. revoking the network permission doesn't stop apps from fetching and displaying ads over the network. I don't know enough about Android internals to understand the mechanisms behind it, but clearly there are ways for apps to exfiltrate data.
> Trying to use Network as a complete data exfiltration toggle isn't the intended purpose, and you should always consider apps within the profile being able to communicate for ALL data and access including permissions. It is not something only relevant to Network.
https://discuss.grapheneos.org/d/4024-in-what-extent-can-app...
There has been talk of developing 'IPC scopes', similar to how there are contact scopes.
Another example relating to tracking ad targets, also known as "users":
"Around September 2024, Meta developed a creative solution to evade Androids sandboxing restrictions. (Id. 4849, 52.) Devices have localhost ports, which simulate a communications channel by allowing applications or services running on the device to communicate with each other... without those communications leaving the device. (Id. 53.) Meta modified its Pixel code (the Modified Pixel) so that it would send the _fbp cookies contents to a designated localhost port. (Id. 55.) In turn, Meta modified its Facebook and Instagram apps to listen to that localhost port for incoming data. (Id.) The Facebook and Instagram apps combined any incoming localhost data with personal information and identifiers, and subsequently shipped that combined data from the users Android device to its own servers. (Id.) As a result, even though Meta would typically have a harder time identifying Android users, Meta was now able to perfectly deanonymize Android users browsing activity if they used its apps. (Id.)
Meta's conduct was unknown until a group of internet security researchers disclosed it on June 3, 2025. (Id. 4; Dkt. No. 104-3.)
Shortly after the researchers public disclosure, Meta announced that it decided to pause use of this tracking method. (Id. 69; Dkt. No. 104-4 at 5.)
In this consolidated action, Plaintiffs assert nine claims against Meta: ... (3) violation of the Wiretap Act, 18 U.S.C. 2511(1); (4) violation of the California Invasion of Privacy Acts (CIPA) wiretapping provisions, Cal. Penal Code 631; (5) violation of CIPAs eavesdropping provisions, Cal. Penal Code 632; (6) violation of CIPAs eavesdropping device provisions, Cal. Penal Code 635; ... Plaintiffs assert an additional two claims against Google: negligence and negligent misrepresentation.
Plaintiffs CIPA pen register, unjust enrichment, and negligent misrepresentation claims are DISMISSED. Dismissal is with LEAVE TO AMEND because the Court cannot conclude on the current record that amendment would be futile. All other claims survive dismissal."
The above is an excerpt from In re Meta Android Privacy Litigation (3:25-cv-04674, N.D. Cal., June 3, 2025)
https://dn711508.ca.archive.org/0/items/gov.uscourts.cand.45...
https://dn711508.ca.archive.org/0/items/gov.uscourts.cand.45...
Of course Meta will eventually settle, like Google did in Brown v Google, in Google's case on the eve of trial. The wiretapping claims would be catastrophic for these companies
But the Court's observations are interesting
"At this early stage in the case, and given the undeniably significant portion of mobile phones using Apples iOS, it is reasonable to infer an industry custom of placing tight controls on communications between apps based on Apples restrictions."
I mainly use native camera (good in most cases, can be brought up immediately with double power button press, from locked), Google camera (rarely), BlackMagic for when I need control over videos and ProShot when I need control over images (the last one might be hard to install - it's a paid app (I'm a paid user, this is how I got it), but not long time ago the moron of the developer made the app "incompatible" with devices without Google surveillance buttplug claiming it will prevent people pirating it form opening support cases....???).
So you can have multiple camera apps. Thankfully Google is not Samsung or Sony, and all the apps have full access to the cameras.
You bought a phone from an advertising company?
Some of them have ridiculous secur... compliance rules.
Other banks that I use are there. Almost perfect...
Most banking apps work, but Google Pay/NFC payments won't work.
Its just a matter of time before this cesspool will leak into the rest of the OS, AppStore shows us the temptation is too big for Apple. When my iPhone 12 mini dies it’s /e/OS or GrapheneOS for me. My devices should serve me and my thoughts are my own.
I don’t think it will leak. After the U2 debacle, Apple might have learned not to push too hard on this front.
But nevertheless I'm looking forward to their Motorola offer that should come any minute now?
I was sad that I had to go through the OOBE setup on the stock image to unlock the bootloader. At least it doesn't force an internet connection and login, unlike Windows.
I'm not looking to fully de-Google but I want Google as apps and not my OS.
Biggest caveats that I've encountered: tap to pay via Google Wallet is a no go, Android Auto can be flaky, MDM managed work profiles don't work at the moment, and some apps that use the Google Play integrity API fail to validate and refuse to work (I've only encountered one app that fails, and plenty others that work.)
In general, I'm moving towards a de-Googled life and GrapheneOS is a great entrypoint towards that.
Edit: Apparently that's Europe only? I'm in Europe so yeah. I didn't know that.
I had a very weird (bad) experience with Curve support so I couldn't recommend it.
NFC payments work, it's only Google who claims a phone not patched for 8 years is safe and secure, but phone with working hardware attestation and patched 6 months ahead of everyone else is insecure.
I'm hopeful that an OEM Motorola device will get certified for Google Pay.
So I get to use contactless payment at maybe 50% of the stores, which is annoying, because it's sometimes hard tot tell ahead of time.
Do you mean actual employer-spyware MDM work profiles? I suppose I never expected those to work.
Or do you mean things like Shelter, which uses work profiles and which I use to quarantine certain less-trusted apps?
Its all fun and games until the company gets hit with a lawsuit and discovery hits your phone and ALL your accounts, corporate and personal.
Ive been through a corporate discovery when oracle sued a company I worked at. Im fucking glad that my work devices were purely owned by the company.
NEVER FUCKING LET WORK AND NONWORK STREAMS CROSS.
Google Wallet bans using anything other than an unmodified Google Mobile Services stock OS but there are alternatives in certain regions. In Europe, there are a lot of banking apps with tap-to-pay compatible with GrapheneOS and also Curve Pay. PayPal also has a limited tap-to-pay launch in Germany.
This is entirely possible as other posters have explained. But I think it kind of defeats the point of Graphene, at least somewhat. Google is already profiling every aspect of your life by reading your emails, files, calendar, location, etc? In that case, OS access becomes moot.
I think that GrapheneOS makes most sense as part of a broader move towards privacy-respecting alternatives. I see the sandboxed Play Services as something useful perhaps in a secondary user profile, for the odd commercial app required and only available from the Play Store.
I actually find that it blows Google Maps out of the water for cycling (which is why/how I discovered it). I haven't really used it for driving much because my own car has a builtin nav, so can't really comment on that.
YMMV of course.
Left from Maps.me to OM because of drama and intrusive features, do I need to leave OM for CM?
edit: seems CM shouldnt have that annoying gift icon
edit 2: CoMaps doesn't display (colored) hiking trails, so completely useless compared to Organic Maps, also can't even display tram lines after tapping on tram stop in Prague
I personally also need hiking trails on my map, but I know people who don't and happily use CoMaps.
and let's not get into making fork of a niche map app of a fork of a niche map app, already Maps.me was very niche app, Organic Maps even more and they make another fork because of their feelings about something?
https://www.here.com/products/wego
Maybe for cars Google is better but I don't use those. But even there I see really detailed stats.
OSMAnd is a really great full featured mapping app. A real tool that you can configure in detail. And Organic maps is more simple and quick like Google maps.
There's just two things I still need Google for: most businesses don't bother keeping their opening hours etc updated on other mapping services, and in my city they have live data on the public transport network. This should really be mandated to be offered to open street map too.
LOL Bruh... this has a 1.7 rating on Android based on 42k reviews
https://play.google.com/store/apps/details?id=com.generalmag...
Not really.
1. A non-Google OS can shut off background running access to Google apps, as well as supply Google apps with mock location data and other data
2. Google does other things to the OS that drive me nuts. Like allowing apps to restrict screenshots. I own the phone. If I want a screenshot, it should screenshot. This is not something for apps or Google to determine, and if the OS listens to me (not the app) it should allow screenshotting the display 100% of the time regardless of what the app cries about.
PREACH!
I hate this.
The Owner profile itself doesn't run Google Play Services, so when that Private Space is locked and dormant it's effectively a degoogled stack.
Some will invariably argue that an old pocket-sized Linux PC with a cellular modem is a superior experience, and for some specific things it may well be, but GrapheneOS is the only viable option for someone looking for a user-respecting modern phone with very few limitations.
You can install nonprivileged google stuff on the main account.
Alternatively you can setup a private space (accessible to the main user but mostly separate from the main system) with a few clicks in the settings.
If you prefer more friction / isolation you can setup a separate user where you can install the google stuff.
*It doesn't actually wipe your data; it just destroys the symmetric key, making the data permanently unreadable.
so it's kinda pointless to wipe data prior wiping them again during the bootloader unlocking process
My understanding is that it is impossible to unlock the bootloader on a new recent (Android 7+ at least; possiblt earlier) Android phone until it has connected to the Internet. After that, the ability to unlock the bootloader is permanent.
Any other manufacturer may alter the deal any time. In case you have such a phone, dear reader, consider getting your code if you still can even if you won't use them yet.
On the Nexus 5, you could just `fastboot oem unlock` right out of the box, install TWRP (custom "recovery") and install CyanogenMod/LienageOS, without ever booting the stock ROM.
On my Moto G4 Play and Moto X4, you had to get an unlock code from the Motorola website (based on the phone serial number I think) and waive some warranty terms, but once retrieved at least the phone didn't need to be online to unlock the bootloader.
The process on the newer Pixels is disappointingly intrusive, like basically everything Google has done for the last decade.
However, some apps that I need for work, like Microsoft Authenticator, no longer work under GrapheneOS.
https://www.theregister.com/on-prem/2026/03/10/microsoft-tig...
They "secure" this behind password which you entered to trigger the SMS push in the first place.
Offering an "out" to a more secure flow means your secure flow may as well not exist.
Additionally, phishing a pushed OTP is not really much harder since you can trigger the push and then just have the user finish off the flow for you, provided they don't read the IP or whatever you display them (they won't, they think they're signing in), effectively the same as a TOTP.
You want me to have email and teams/slack on my phone? Sorry, I won't install the spyware. Want to pay for me to have a second phone with it? Okay. No? Well then, I just won't have email on my phone.
It needs to be made illegal imo. The company should provide you a device if you need one for the job.
What do you think is invasive in an MDM profile? It's just a channel to push data to your phone. Your information outside the work container stays private. Even inside the work container nobody can actually fetch any data from those apps.
I do agree with you though - a company must provide phones to their employees, not force them to enroll into their MDM services. The latter should be only for exceptional cases, e.g., gain temporarily access to corporate VPN, WiFi, etc., on your private device.
Scenario: Your account gets compromised somehow. It's signed in to your personal phone. Company data gets leaked or ransomed.
Your phone and its contents are now evidence.
Compliance =!= Security
Is this an antithesis to Don't Be Evil?
My understanding is that even with pseudo-D2D (device-to-device) transfers Seedvault doesn't backup everything[1].
Are there more-functional, non-root, local (non-cloud) alternatives?
[1]: https://github.com/seedvault-app/seedvault/wiki/FAQ#why-do-s...
Ever since seedvault implemented local D2D API for app data availability and changed their repository format (inspired by restic's hashing) I've grown to trust seedvault enough that it's my sole phone backup.
Seems to schedule/backup/restore just fine, even cross-device. Gets all the apps and files I care about. Incremental runs are slow but efficient (<1MB transferred).
I have some UX gripes and would prefer if key and snapshot management was more flexible but the sentiment I see seems to be rooted in the earlier days when seedvault was more naive.
Look forward to a GOS-native solution all the same.
Again, this isn't about me. I'm fine giving up some convenience, but I know other people aren't. The average person is just going to simply install the app. Part of me asking this questions is gauging average user experience.
The vast vast majority of apps (99%+) are compatible and those that are broken is due to bugs in the apps which GOS catches, but these exploit protections can be disabled, and apps that use the monopolistic play integrity api.
The only apps that are permanently broken are those using the strongest play integrity api which is security theatre.
Here's a community created list of banking applications and their current status on GOS.
https://privsec.dev/posts/android/banking-applications-compa...
If you live in the EU then you can use curve pay which can tap to pay.
Why is no tap to pay significant enough to stop you from switching to a phone that is private and secure? You can just carry a card and tap—they're tiny.
There are alternatives for payments (scroll the thread, maybe look up on GOS discussion site).
GrapheneOS is often better for testing apps due to it being trivial to test with and without google services, most of the hardening options can be used for debugging and provide a crash log to determine what failed, and there is an easily accessible log viewer available in app info.
Small point of critique: it would be nice if it was a little bit easier to switch between personas, for example by simply scrolling to a different workspace. Because now the feature is mostly unused on my phone.
Authenticators should work normally, as far as I know (unless Google Authenticator does anything special). Can’t say anything about Google Wallet. There might be more lists/forums where people share which setups are (not) working well for them.
In general, I had these concerns as well until a few months ago. But I am much more optimistic these days that things will just work well out of the box (have read many positive sentiments in blog posts and here on Hacker News).
This is how users learn to not update anything.
I understand this is part of the reason only Pixel phones are supported - the ability to unlock, and then relock bootloader after install is seen as essential by their team, among other features and properties that only present together in the Pixel phones.
Still boggles my mind the fact Google doesn't sell their phones worldwide. Obtaining a Pixel has proven to be quite difficult for me.
What other phone would you pick?
I’m not an expert, but all the listed points there sound reasonable. If indeed only the Pixels support them, well, it’s too bad there’s not other, similarly secure hardware out there.
If you want Graphene level security you need to have the hardware for it.
Motorola has stepped up to meet the baseline requirements for GrapheneOS support, and we should get Motorola devices with official GrapheneOS support next year.
might as well list all features of pixel phones
Other OEMs can make devices that meet the requirements, and Motorola is doing just that. We should get Motorola devices with official GrapheneOS support next year.
There is nothing crazy about doing something properly.
Which is not to say that's not enough for most people, but why highlight them? It doesn't seem comparable to the laser-focus GrapheneOS has on security
https://www.amazon.ae/Android-Smartphone-Storage-Octa-Core-M...
(If you don't believe it from the identical specs and design, you can look at the committers in their kernel trees and it is basically maintained by Daria people.)
Their new Plinius model is just the Gigaset GS6 with a 250 Euro markup:
https://www.gigaset.com/gigaset-gs6/
At least this is made by a German company, though Gigset is Chinese-owned now.
At any rate, these are just rebadged phones and IIRC, but don't hold me to it, in both cases the original phones also support bootloader unlocking.
https://github.com/Gigaset-dev
I am not sure about the Daria Bond, but in Ubuntu Touch (which seems one of the very few Linux systems that supports the Daria Bond, ahem, Quintus), most of it seems to be the work of LineageOS developers (probably for generic Mediatek support, since it's a run-off-the-mill Mediatek phone), with some changes from Daria people on top of it.
So, I think you are giving credit to Volla that should go to the upstream ODMs and Lineage.
Or just go to the Volla about page:
https://volla.online/en/about/
It's just sales, marketing, and customer support people.
Snark aside, desktop Linux userspace (or gnu Linux, call it how you want) is nowhere near production ready. And even for the more general point, giving out root willy-nilly is not more freedom. It's more like letting your child play on the 5th floor of a half-constructed building that's about to be exploded. Your kid can enjoy their time just as much in the safe forest trail.
Like even `rm` added a flag to not do that without explicitly asking.
Also, there are plenty of immutable OSs now among Linux distros, are they also limiting your freedom?
By definition they very much can. For example SteamOS wipes all non system application (except flatpaks) on updates unless you disable read only mode.
I use and enjoy GrapheneOS but there is no question that the security comes with the trade off of freedom.
It's up to the user to decide if they prioritize one over the other for there use cases. I take GrapheneOS for mobile because of it's security and GNU/Linux on desktop for its freedom.
Good security is about allowing everything you might want to do, but limiting what you don't want happening. Of course it's easier to just put up our hands and don't care about it, but I think we should strive for better security as we are no longer running 3 hand-started processes in a terminal, but 10s of thousands of unknown ones. Even if the processes themselves are trusted, they can easily have vulnerabilities that paired with malicious data can cause real harm. We are just lucky that desktop linux is not a popular target.
Also, I don't think a dead man’s switch on a lawn mower has reasonably limited anyone’s freedom, but it probably saved a few arms and legs.
You still have sudo don't you? So still less secure but also more freedom than GOS.
>We are just lucky that desktop linux is not a popular target.
Its not only that. The fact that software is expected to be mostly installed and updated from trusted, vetted and signed repositories instead of google or root not being used willy nilly by all applications. Both of these basic usage differences are the reason why for all its security features windows will still be much less secure for the average user than even the most basic linux distro. 90% of security is low hanging fruit.
>I don't think a dead man’s switch on a lawn mower has reasonably limited anyone’s freedom
I'm very sure there have been not a small number of cases where such switches did limit freedom, even if you think they do more good than bad they are still there to limit something. The switch could prevent usage when faulty or otherwise prevent unofficial uses or just repairability.
Well, don't be overly sure about how trustworthy these repositories are. Maintainers can't read all the 100s of millions of lines of code, and as mentioned, faulty programs can be just as bad when combined with non-trustworthy data.
Also, people often run random shell scripts (curl | sh), or npm install stuff -- this is arbitrary code execution with the users's full rights.
> 90% of security is low hanging fruit.
I agree here, but unfortunately still nothing is being done, with the exception of flatpak perhaps? And as for windows, among desktop OSs osx is in the best place in terms of security and even that is pretty behind compared to mobile OSs.
I take it you don't use desktop OSes anymore of any kind and call child support whenever you see a parent letting their kid use one? Better protect them from themselves in case they can't handle sudo / UAC prompts and give access (xkcd.com/1200) to the wrong process
This sort of logic really boggles my mind to see on hacker news
Grapheneos is fully open source and comes with 0 Google services.
>so called "security"
Grapheneos is widely recognized as one of the most secure operating systems.
Are you serious? Have you even seen the state of modern operating systems compared to the operating systems of the 80s and 90s? I've had way more fun and learnt lot more about computers messing around with OSes that let you did whatever the hell you wanted to. Modern OSes have sacrificed a lot in that name of security.
As for privacy, that's a completely separate topic. You can have privacy on a OS which offers freedom, depends on what "privacy" you're taking about.
Without all of those details, your statement is meaningless.
Security is the former: actively denying someone or something the ability to look in a situation where they are trying. GrapheneOS does that by encouraging a locked bootloader (preventing physical attacks) and letting you deny sensor access (preventing malicious apps from accessing unnecessary info), for example. I think we agree so far?
But you can also have privacy by just not installing apps that violate your privacy. Such a device could be as open as any Linux laptop where you log in with root:root. It lets you do whatever you want and access whatever you want. It's yours through and through. That's freedom without security, which may or may not have privacy depending on who you let look: if you leave it unattended at a hacker conference or have sshd with password login enabled, yeah that won't stay private for very long. But that's your choice right? You can just not invite anyone in or, in this example, bring it to someone who would do something malicious
An official GrapheneOS release has a lot of features baked in against actively malicious actors (be it apps or people at border checks), but users need to work within the boundaries and limitations of the sandpit that's provided to them. They're not granted much freedom, and that limits what privacy measures you can enact. Making a backup of /data, modifying firewall or traffic routing rules, signature spoofing to substitute an untrusted app with a trusted implementation, intercepting and faking Android API responses... a lot of things are off-limits: you don't have the freedom to shape the environment to suit your needs, for example to create privacy or security
The axes (privacy, freedom, security) all influence each other, but they are still separate enough that you can have one or two without the other. I can see what you mean if you say that your threat actors are skilled exploit developers and you can't have privacy without also thwarting these constant attempts. (Paranoid as that may sound, I'm sure it's true for some people.) Most people would gain more privacy from doing something about the pervasive adtech than about exploit developers they're not likely to run into. For them, LineageOS could be more private and provide more freedom while being less secure in some ways (e.g. they need to watch out which processes they grant access, for example something claiming to be backup software that turns out to be ransomware) and more secure in others (e.g. data availability by getting to make backups)
And calls the open source microG a threat while encouraging people to install google mobile services, conveniently provided from their preinstalled app store, which most people will need for at least some of the apps they need in daily life, so everyone ends up with GMS installed in their main profile. A real bastion of freedom and choice.
Sandboxed google play does not grant google code any kind of privileged access. It is confined to the same app sandbox and permission model as all other apps and can be installed and uninstalled like any other app.
Note that apps with google libraries grant google the same, unprivileged access google services gets on GrapheneOS. MicroG fails to meet the privacy, security, and usability requirements GrapheneOS has in place when it comes to google play compatibility.
So, you can pick MicroG, which is bundled, privileged, poorly made, has poor compatibility, and trusts an additional party...
Or, you can pick sandboxed google play, which is not bundled, optional, unprivileged, fully sandboxed, and does not trust additional parties. Oh, and you can uninstall and reinstall whenever.
It is evident which option gives the user freedom, and a choice.
Yes, I knew it's in a sandbox at the time of writing my comment above; no, that doesn't make it a privacy paradise compared to microG.
The sandbox still needs internet access for a lot of GMS' functions and lots of apps send information into it. For example, Signal will actively reach out for notification bundling, so Google gets to know who runs Signal, what IP address they're on, with who else they share that address as they go to school and work, build a social graph... So while the sandbox is definitely very useful and I'm glad it exists as open source software that other Android distributions can be inspired by, it doesn't definitively solve fundamental problems with running unwanted software on your device
Do you know what privileged context means? As in, what access this grants concretely? I tried to look it up once, ended up in Android source code trees, and left more confused than I went in. It looked like it gets no extra file access at all, which is strange right? What does privileged mean if not that? I tried su'ing to the user ID of GMS and this confirmed that the GMS user can't access other apps' data folders. So I'm no longer sure what to even make of this wording. Is it maybe about syscall hardening that isn't applied to privileged apps or so, so like exploit protection rather than normal permissions? The benefit of that would be protecting from exploits that Google could send. Do we think they'd legit do that, short of receiving an NSL that compels them?
Rather than running the unwanted proprietary (but necessary) software wholesale and attempt to sandbox it, I'd much rather substitute as much as possible with open code (where we know what it does) and have a much smaller set of proprietary components that need to be kept around in a sandbox and active only when necessary. For example, microG will replace Gmaps with Mapbox, reducing how much data is sent out about you to Google (they don't get to see which city you are probably in while using the map in Too Good To Go, for example).
It seems fairly obvious to me that less data sharing plus less proprietary code (that needs to be sandboxed) is better than letting Google go wild and installing their apps as-is with self-updating functionality (in said sandbox). What threat would sandboxed microG pose that sandboxed GMS doesn't? Is there any logic to GrapheneOS not wanting to build upon microG to get the remaining proprietary parts properly sandboxed, rather than starting over from scratch?
> su'ing to the user ID of [another app]
Look, I have root, so you can hack me! And my bootloader is wide open, too! In your words:
> > Root access and an unlocked bootloader are insecure, even for low threat models. These devices are vulnerable and should not be used for any sensitive data.
I'm serious that anyone should feel free to prove the point by sending me a responsible disclosure notice about having found a way in, but the threat clearly isn't serious enough for that to actually be concretely possible. Which is not to say that it's never relevant, but "such a device shouldn't be used" is not valid as a blanket statement
> "Thanks, but there's no way..."
Its reposted because the information is accurate, and misinformation regarding it is very prevalent.
> "Yes, I knew it's in a sandbox..."
Relative to MicroG, sandboxed google play is much more private, secure, and usable. I would not describe it as a privacy paradise, but MicroG does not improve upon this, and instead makes these aspects worse.
> "The sandbox still needs internet access..."
Most google libraries operate independently of google services and do not depend on them to function. FCM is an exception due to how push notifications are optimized (by using one app for the connection). MicroG does not avoid this.
> "For example, Signal will actively reach..."
You do not need to provide an identity to google. This can also be avoided with a VPN, and is not specific to google. There is the concern of metadata but Signal sends empty notifications without any identifying info. They are only used to wake the app up to fetch its own notifications.
> "So while the sandbox is definitely very useful..."
It confines google services to the same rules and restrictions as all other apps. MicroG does not. MicroG also does not avoid running unwanted software, referring to the google libraries in apps and the google code MicroG downloads.
> "Do you know what privileged context means..."
MicroG violates the security model by necessitating signature spoofing, which puts it in a position to receive data it was not intended to receive, there is also attack surface exposed by having access forbidden by the app sandbox. Sandboxed google play is bound by the same app sandbox as all other apps, and would not be any more or less capable of exploiting the device than any other app. The idea that google would try to exploit the device is nonsensical though. But granting both google and a 3rd party privileged access is still unacceptable.
> "Rather than running the unwanted proprietary (but necessary) software..."
Google play services runs in the android user app sandbox. It is not an "attempt", it is successful at doing this. MicroG being open source does not matter in regards to privacy or security. It did not change how MicroG has leaked location to apps without location permissions, it does not change how it downloads and runs google code both privileged and outside of its own APK, and it does not change how other apps are running google libraries anyway. Note that the proprietary code it downloads is not confined to the app sandbox.
> "For example, microG will replace Gmaps..."
Im unsure if you are referring to the app Google Maps, or google maps integration. GrapheneOS reroutes googlefusedlocation requests to the OS, rather than google services. You can use an app other than google maps, and apps with google map integration can simply send your location to google directly, independent of google services or MicroG.
> "It seems fairly obvious to me that less data sharing..."
Googles access to data is not limited by using MicroG, relative to sandboxed google play. And the size of proprietary code is irrelevant, that code can be anything. It can be malicious with 2 lines, or benign with 2 million. Access is what is vital, not size. Google is not permitted to "run wild", and is granted no additional access compared to any other app. Im unsure what you mean by self updating functionality, but for apps from the playstore, nearly all of them are signed with a key that google holds, and MicroG can do nothing about this. GrapheneOSs App Store is responsible for updating google play and google services, it cannot update itself.
> "What threat would sandboxed microG pose that sandboxed GMS doesn't?..."
Using MicroG necessitates GrapheneOS violate the android security model, trust a 3rd party unnecessarily, cripple 99% perfect compatibility, use code that is not near as battletested as play services, run google code as privileged, and run a software that has had serious privacy violations in the past. Not only is the base insufficient, but any finished product based on it still would not compare to GMSCompat. The logic is that GrapheneOS wants the best compatibility, the least changes to the android app sandbox, 0 privileged google components, no violations to the android security model, and no need to maintain a reimplementation when google services and store are already maintained by a huge organization.
Root nowadays gets you very little: software like wavemon that worked great on Android 4.4 no longer runs because selinux or whatever restrictions block nearly everything from working that isn't going through the Android API channels. Accessing external storage from Linux Deploy (running your favorite distro in userspace with root) no longer works; thankfully it does from Termux so I have some way of manipulating the files with standard Linux tools, but then that keeps getting killed and you need to restart sshd a few times per day if you want to actually use that as a remote access method for your photos.
The Linux processes are being shot at left and right, it's go android or go bust on android. Perhaps that sounded redundant but it used to be that you could install Xorg, Virtualbox and other GUI software, and knock yourself out. No more
The policies and applications running on top of or in the linux kernel do not change its distro classification. Lacking root access is a massive step forward for privacy and security. Root access is insecure and a hacky shortcut to proper functionality.
This should have gone in my spreadsheet before I chose a new device xD. Ah well, next time
They are kind of the opposite of GrapheneOS. Ancient kernel trees, ancient firmware bundles, etc. And since downstreams like /e/OS just take their kernels/firmware, they are ancient as well. Using Volla phones opens you up to a lot of known vulnerabilities.
Besides that, Volla is basically a marketing company (with some external contractors) that does Eurowashing. E.g. one of their phones (Quintus) is a phone designed by an Emirates company, produced by a Chinese ODM, marked up by 500 Euro by Volla (they probably turn some screws and flash the firmware to be able to call it 'from Germany'. You can get the same 719 Euro phone here for ~160 Euro:
https://www.amazon.ae/Android-Smartphone-Storage-Octa-Core-M...
I don't understand why people do free promotion for Volla, given that they are mostly snake oil salesmen.
For the curious: https://marbit.substack.com/p/worse-on-purpose
The main things I miss are (1) when I'm entering text I can't swipe left and right on the space bar to scroll the cursor left and right, and (2) the texting app doesn't just attach reaction emojis to a message -- it quotes the whole message and prefixes it with something like "Marty like blahblahblah". When there is a whole family text chain it isn't uncommon to see the same message 7 times as various people react to the original message.
Anyway, I looked at Google's Android 17 blog and yikes:
"With deep integration between hardware, software and AI, we’re transforming Android from an operating system to an intelligence system. It's about delivering new helpful experiences that anticipate user needs, and it brings more opportunities for engagement with your apps."
https://android-developers.googleblog.com/2026/06/Android-17...
Open source with limitations on commercial use.
Maybe you can try installing another SMS app for problem (2)? Much like the stock keyboard, the stock Messaging app is just the AOSP app. Honestly it works fine for me so I don't have a recommendation.
GrapheneOS is compatible with the vast, vast majority of Android apps, so you can use GBoard or FUTO keyboard (which I recently switched to from GBoard), to get the ideal experience.
FUTO recently revamped their swipe to type model and it's now more accurate than GBoard in their testing. I am a huge swipe type person, so this is what held me in GBoard's clutches, but now I'm free.
The dataset is open source and anyone can add to it if you're on a mobile device here: https://swipe.futo.org
And you can learn about it here: https://swipe.futo.tech
> the texting app doesn't just attach reaction emojis to a message -- it quotes the whole message and prefixes it with something like "Marty like blahblahblah". When there is a whole family text chain it isn't uncommon to see the same message 7 times as various people react to the original message.
Google messages, the experience you get on PixelOS, is also compatible with GrapheneOS, but you will have to afford network access to sandboxed google play, among other things. I couldn't tell you specifically, but it will work out of the box before you restrict anything. Many people choose to use this setup because it opportunistically adds e2ee for chats between iPhones and other Androids using Google messages.
There's also other SMS apps, but I focused on switching people to Signal so I barely ever use SMS.
Once I replaced the default apps, GrapheneOS became a premium phone experience.
The voice recognition is built on Whisper, and is amazing. You can speak conversationally for a long time and it gets everything right, with smart decisions based on context.
My stupid thumbs text no more.
I've found graphene's keyboard far more error-prone than the stock android keyboard, but I also don't care to learn swipe to type.
The feature I'm missing is simply that rubbing my finger left or right on the spacebar in text mode causes the cursor insertion point to move left or right on in the text I'm entering. It makes it sooo much easier to correct typos.
Graphene's keyboard is the stock AOSP keyboard. Most Android systems ship with their own one instead of it, but that's the one that is built into the system by default.
So I still use gboard but block its internet access.
The point is, I'd like to be able to set up services, configuration, and run tasks on my phone this way too, ideally offline. If this system integration is what gives me programmatic control of my most personal computer and the ability to finally set up decent automated tasks and workflows then so be it.
Why would we expect the same company to exhibit a completely opposite philosophy as they add LLM features?
RCS is different, which you can sometimes get working by installing Google Messages¹, which is essentially the only app that supports RCS any more. Google runs essentially all the servers too.
---
1: There are no third-party RCS apps² because, unlike SMS which has an API and a shared database on the device, RCS is extremely locked down and it's literally impossible to create one in stock Android. This is also why it's only "sometimes" on GOS, the details are very complicated and rather enraging.
2: Samsung had one, but they're shutting it down in favor of Google Messages. A tiny number of other devices / telecoms have their own too, but they're rapidly shutting down as well. RCS is very nearly fully controlled and implemented by Google now, except for iMessage as a client only, for now, and there's no encryption between iMessage<->Google Messages last I checked (but there apparently is between Google Messages... but no normal person can really verify that because it's Just Google Everywhere).
I had installed graphene os on a pixel but after a couple months and a couple loops between lineage, stock, and graphene, I eventually settled on stock android. I have group messages with family and some of the family are on apple, some on android, and RCS only works with google messages and google services installed.
It's infuriating that I can't send RCS messages unless google allows me to. I want to go back to email or MMS. Supposedly after a month (!!) RCS group chats will fall back to MMS, but that was not my experience. Also, if you turn RCS on/off you may get kicked out of group messages [0].
[0] https://support.google.com/messages/answer/7189714?hl=en
Initially there were some promising details planned, but much of it hasn't panned out, and plus now it's Just Google™. Like, roughly everyone has heard that RCS brings E2EE privacy, right? Would it surprise you to learn that it was only added to the spec around a year ago, and nobody has it implemented yet? Google has their own thing between Google users, Apple has their own iMessage-only thing, and they both drop crypto when you cross the streams because it isn't in the spec. And neither is practically auditable (allowing auditing is part of the spec btw - have you seen that UI?).
And that's before even touching on the utterly massive amount of the spec that's clearly designed for businesses only, to send you highly customizable interactive UI. Which you can't use as a person. Or build your own app for. https://developers.google.com/business-communications/rcs-bu... / https://rcsforbusiness.google/
It just does not smell good. It's not in our best interests to let it win.
Unfortunately Google revived it but it's a very poor standard for interoperability. Not only because the lack of true E2EE in the open spec but also because you need to be a blessed party to run an RCS server and communicate with others. You can't run your own or choose a party you trust. It's either your carrier if they bother to run one, or Google.
It's just another power grab. Don't fall for its 'open' guise. They want you to use it so they can make you dependent and lock you in again. There's nothing open about it. If you want privacy, use signal. If you also want an open and federated network, use matrix or xmpp with OMEMO.
I strongly disagree with this negative characterization. RCS was a replacement protocol for the extremely outdated SMS and MMS protocols. Apple only supported SMS/MMS chat with Android users in iMessage, which meant that cross-platform chats were strongly limited in many ways (e.g. the mentioned emoji reacts), which caused many US American kids to be socially punished for having an Android phone, which is likely part of the reason why Apple is so dominant in the US now, especially among younger users. (Other countries mostly don't use iMessage/SMS, but something like WhatsApp, so they never had this problem.)
RCS was the solution to these iMessage/SMS/MMS incompatibilities. It took years for Google to convince Apple to adopt it, and Apple only announced doing so after EU regulations were on the horizon. There were even internal emails which revealed that Apple used their iMessage dominance and the poor Android compatibility via SMS/MMS to boost their market share in the US.
In summary, RCS is great because it is both a modern chat protocol, unlike SMS and MMS, and an open standard, unlike the closed iMessage and WhatsApp protocols, and available cross platform, unlike iMessage.
And the social problems are not a technology problem, it's more a result of the harsh competitive American society. Without blue bubbles there'll be something else that kids will be bullied for. Only when the whole concept of "everyone except the #1 winner is a loser" is dropped this will disappear.
And Google didn't try to convince Apple to do this out of the goodness of their heart. Like I said most of the protocol (except the E2EE) is open but the implementation is not. It gives google even more control. You also won't be able to use it on a PC without a google account which is a big dealbreaker compared to Whatsapp and Signal. iMessage isn't a thing here in Europe anyway (neither is SMS/MMS).
At least in the countries I deal with in Europe (Netherlands, Spain, France, Ireland). Perhaps in UK the adoption is higher because they have more money and thus iOS usage is higher. But everyone I know is on either WhatsApp or Telegram (and sometimes but very rarely Signal). Also we are much more socially disconnected from the UK since brexit.
As a bit of added info, the reason SMS is so hated here is because providers offered paid SMS services. You could sign up for e.g. daily weather reports and you got billed for it on your phone bill. It could be up to 1-2 euro per SMS. Some countries even up to 5 as far as I remember. This service was abused a LOT by scammers who just signed people up without consent and refused to remove them. The carriers did almost nothing against this because they were raking in the euros. This caused people to be very wary of SMS. Most people I know never use it anymore. They get worried when they receive something because they are afraid they'll get charged. Which can really add up if they do it from the start of your billing cycle. So its use as iMessage fallback is also pretty nonexistent.
So this is also why I am so wary of RCS and the carriers. They have played a deplorable role in the 2000s/early 2010s. Really cashing in hard with small bundles and insane out-of-bundle charges for SMS, the pay service scams etc. It was really their cash cow. So my trust in them is forever lost, I will never trust them to provide more than just transporting neutral bits from A to B.
It's also why I will never sign a contract with telcos and always use prepay. That way they can never take more of my money than I have in credit.
False. RCS is a replacement for SMS and MMS, and it is far more modern than those. RCS is the most modern game in town.
> As others have mentioned it's not even available with interoperation.
Others might have "mentioned" this, but it is false. RCS is interoperabile. It is supported both in Android and iOS by different applications. That covers the two mobile operating systems that constitute nearly the entire mobile market.
> And it was really invented by carriers for exactly that purpose: To regain SMS/MMS revenue.
I don't think that's true since they didn't charge for RCS. But even if it's true: that doesn't mean RCS is bad. RCS is like HTTP+HTML, but for messaging. Saying that RCS is bad is like demanding that all browsers should be proprietary without supporting anything resembling a web standard. Which would be crazy.
> But at this point here in Europe SMS usage between people had vanished anyway
That's irrelevant because RCS is still important in the US.
> And the social problems are not a technology problem,
They absolutely are (also) a technology problem. If people can't properly interact with each other in group chat because one side falls back to MMS and all pictures are ultra low resolution, then that's annoying for everyone. Of course people would say the problem is with Android rather than with iMessage refusing for many years to adopt RCS, which hugely boosted Apple's market share among young people in the US.
> Without blue bubbles there'll be something else that kids will be bullied for.
False. They weren't bullied for blue bubbles. They were "bullied" because green bubble people had bad compatibility problems. Why? Because of lack of RCS.
> And Google didn't try to convince Apple to do this out of the goodness of their heart.
That's an absurd statement. Google was obviously not happy that Apple was (as they even confirmed in internal emails) actively using incompatibility to increase their US market share. Apple was basically acting like Internet Explorer vs Netscape.
> Like I said most of the protocol (except the E2EE) is open but the implementation is not.
It's still an open protocol. Not everything must be open source. Proprietary apps like WhatsApp use neither an open protocol nor are they open source.
> It gives google even more control.
Even more? Proprietary protocols like iMessage or WhatsApp have far more control.
> You also won't be able to use it on a PC without a google account which is a big dealbreaker compared to Whatsapp and Signal.
That's an absurd comparison because you can't use WhatsApp or Signal without an WhatsApp or Signal account either. Not even on phones.
> iMessage isn't a thing here in Europe anyway
That's irrelevant. Open standards are good even if non-open things dominate in some area.
> (neither is SMS/MMS).
Also irrelevant. RCS is an open protocol that is vastly superior to SMS and MMS and not a closed and proprietary system like WhatsApp or iMessage. This makes it a great system, similar to HTTP and HTML.
But that would mean that the entire protocol would have to be made open including E2EE, and that other parties besides Google and the telcos would be allowed to run servers. Those things are very unlikely to happen.
the RCS v3 page: https://www.gsma.com/solutions-and-impact/technologies/netwo...
^ which links to the E2EE v1 spec: https://www.gsma.com/solutions-and-impact/technologies/netwo... ("download" is a direct link to a pdf file)
and https://media.gsma.com/assets/2026/rcs/RCC.16+v3.0.pdf is v3.0, which appears possibly detailed enough at a glance, and there seems to be a v4 and I can't download v2 due to a broken page. but I have no idea what's currently supported anywhere in practice, if any.
I have to look up on this again as the last time I looked at it was during late corona (2022? 2023?) when there was a local talk to adopt RCS (which failed)
But the problem remains that they simply won't talk to you if you set up your own server. You have to be in a select club to be able to run one.
It's very unlikely I'll ever switch it on because I don't use any google account on my Android and I don't trust them nor the carriers for reasons I've clarified in the other posts in this thread.
they have, however, been touting the security improvements that RCS brings ever since work first started on it. which is so misleading that it's outright malicious imo.
Google Messages and iMessage AFAIK send RCS messages to each other just fine, but it's not encrypted. yet. ever, IMO, until the moment it's rolled out.
And AFAIK they have only been desiring to build their own RCS app, and researching it, but have no concrete plans. It'll probably be extremely hard to do, given how much interaction it requires with individual telecoms, and how large the specs are and how much they change - it'll be signing up for significant dedicated eng/business/etc effort that will never decrease. Though I would very much like it if it does happen.
Personally: it worked for about a year for me, then stopped for several months, then worked for two, then I disabled it. All on the same phone, same OS install, same carrier and phone plan, and same location. No issues at all on stock Android with everything else identical which my wife uses. You can find tons of cases like this with Graphene users, RCS just doesn't work/activate/??? as well for some reason.
I'll definitely be curious about the source code when that happens, and if it'd be reasonable to get it into a SMS-provider-like shape eventually. Particularly since Android's original PoC did that, but it was abandoned for some reason.
My single (minor) issue with GrapheneOS is the adaptive screen brightness. On the stock Android OS on a Pixel I'd mess around with the sliders for a week or two on a new phone and then it learned what I liked. Now it has a few set values, one of which is always too dim for me in darker conditions so I have to mess with the slider each and every time. I don't believe there's a way of fixing that.
Other than that I'm glad I switched, especially when I read about new "features" they add that I know I'd hate.
Now I use Heliboard with the swiping library added. It's not perfect, but has improved, and at least it can give more than three correction options (long–press centre suggestion with ellipsis below).
I really miss Keymonk — two–finger swiping, accurate, and no crap.
Also never have that feeling anymore that my phone is spying on me.
I'm using NextDNS for DNS level ad blocking as well as iOS built in tools, and I get ads for women's hygiene products (I'm male), travel, dining, server parts, cars, and everything in between.
The main difference between Android and iOS is (or used to be?) that Android typically phones home with everything, frequently visited locations, calendar appointments, voice commands. On iOS most of that runs on-device. Siri voice to text/text to voice runs on device, various "ai" things in photos runs on-device, frequently visited locations are device local.
GrapheneOS has zero ads in the OS and main services.
I've got almost everything working the way I want. There were a few non-essential banking apps that won't install. The most annoying problem I had is when I tried to install Strava, which I cannot get working. The app installs, but it will not let me sign in. I guess I need a replacement, because I use that app a lot.
There's also been some discussion of spoofing MEETS_DEVICE_INTEGRITY, since before Android 13 it didn't rely on a TPM, and many apps don't want to lock out older devices, but it's been decided against it [0].
[0] https://github.com/GrapheneOS/os-issue-tracker/issues/1986
My bootloader is locked, because I re-locked it after installing GrapheneOS. The app runs, but refuses to let me log in. I even tried (temporarily) using a browser to login, and let the browser switch to the app in the process. Nada.
It's ridiculous that Google bills their "DEVICE INTEGRITY" initiative as a security feature, when GrapheneOS, which is a more secure platform, cannot use it.
[0] https://developer.android.com/google/play/integrity/verdicts
For example, McDonald's has a long running campaign, 99¢ for coffee. Any size, iced or hot.
I suspect this is an attempt to prevent folks from spinning up many new accounts to get these deals.
https://news.ycombinator.com/item?id=48571526Of course many apps work fine with turning of more permissions that GrapheneOS allows.
Sounds like spyware, to be honest.
I can also recommend Gadgetbridge for BLE smartwatch integration.
> Attention required!
> Sorry, you have been blocked
> The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.
Thanks cloudflare *handshake* garmin. I suppose I'll stay with chip and pin for now
Commercially, this makes sense.
I am surprised that most nations of the whole world are fine with every citizen relying on one of two american companies for their lifestyle interactions though. I would have thought more nations would legislate their banks must support other options for sheer sovereign resilience.
Does it though? The people in this thread are like "just use a card". Well I've done that for years and had my card skimmed, lost, and stolen over the years. The cost wasn't trivial either. The credit card company knocked it off my balance but also lost on sales when I didn't have my card while they issued me a new one. It cost the credit card company actual money in both lost sales and in dealing with the fraudulent transactions.
Now if I was allowed to use my rooted Android phone during those years? It would have been locked down tighter than the vast majority of Windows boxes.
People forget that one of the value-adds of credit cards in the first place is that suddenly you didn't have to walk around with a big wad of cash. Credit cards gave you that extra level of security. Even if someone stole it, it's useless to them as soon as you make a phone call to the CC company. We can verify a transaction with a yubikey-like secret store on your device that never shares the private key with the operating system and which generates a virtual credit card on the fly. That's literally how Apple Pay and Google Pay already work. So whether a device is rooted or whatever literally doesn't matter.
You'd struggle to find a POS terminal that even has a reader for them in the UK. I've only ever had to enable them in the US or Japan.
however grapheneos isn't rooted anyway
Curve demand a "video selfie" and I've never been comfortable with sending companies such biometric data.
https://help.curve.com/en_gb/your-curve-account-verification...
https://www.entrust.com/products/identity-verification?edc_r...
As the second URL suggests, Entrust used to be called Onfido.
https://uk.trustpilot.com/review/onfido.com
Oh dear...
I definitely use one of those wallets. They're quite convenient too.
I don't really see the appeal of contactless payment, pulling a card out really doesn't take much time.
+ my country already has a mobile driver's license app
And most places take card (or nfc via google/apple pay)
https://news.ycombinator.com/item?id=48571526Support expires? Upgrade to custom ROM Ads? Upgrade to custom ROM Want to use it as server? Upgrade to custom ROM.
If I would use Apple iPhone, these old phones would be trash very soon.
For context, that would put it at the same release as Pixel 3 or Pixel 4. Those devices stopped receiving updates in 2022-2023.
Asking as an A11 user who will probably soon need to switch to a new device. I haven't noticed anything on other people's phones that isn't available on mine, including on my work phone that runs an up-to-date GrapheneOS (but I don't need to do much more than calling and 2FA, so I might just not be seeing it). Anything you guys are excited for, or any protips of things to check out that were released recently?
This should have the full list; it's not a ton of changes, which speaks to how perfected Android has become.
https://android-developers.googleblog.com/2026/06/Android-17...
https://android-developers.googleblog.com/2026/06/Android-17...
I'm not sure though if GrapheneOS gets mainline modules at all (most likely not).
Edit: not discontinued but 'merge with Android' https://en.wikipedia.org/wiki/ChromeOS
I've used mine daily since it came out, and it's a great experience. I'd recommend picking it up for anyone who wants GOS on a larger screen. An iPad it isn't, but my iPad Pros have sat almost totally dormant since I got it years ago.
It lacks horsepower compared to the latest Pixel Pros, but that hasn't been a practical concern in anything I've done with it so far.
Pity. Genuine pity. Guess I'll continue using my 5 year-old out-of-support device until someone decides to make a decent GrapheneOS-compatible tablet with stylus pen support. If it breaks, I'll just go back to notebooks.
The Pixel tablet is a mere 3 years old, and still supported, for whatever that's worth. I don't use a stylus but I believe it supports USI2. I'll rock mine as long as I possibly can.
There's a shot of GrapheneOS on a tablet just past the three-minute mark in this video. I suspect that's a Pixel tablet (of which thee are several), though I'm not certain and the video doesn't specify:
<https://redirect.invidious.io/watch?v=aNgupWEV13M&t=188>]
Google Pixel tablet: <https://store.google.com/us/product/pixel_tablet?hl=en-US>
Discussion on Reddit says Google Pixel and Pixel Fold are both supported (tablets): <https://old.reddit.com/r/GrapheneOS/comments/16bp6e9/anyone_...>.
If you'd like to donate to the project, you can do so here: https://grapheneos.org/donate
<https://redirect.invidious.io/watch?v=aNgupWEV13M>
Visually, it generally looks much like stock Android in terms of capabilities, though a stock install generally has far fewer apps installed.
1) What's a reasonable Pixel phone to buy to try out GrapheneOS? Is a 128GB Pixel 7 "good enough" or will I get a significantly better experience with a newer phone and/or more storage?
2) Is there a Graphene alternative that would let me de-google an Samsung A12? Back in the day I had some Galaxy S3 and S4 phones that I installed Lineage on, I have no idea if that's compatible to Graphene and/or still a going thing?
Checking which phones are supported by Lineage and Graphene can be done by everyone in a matter of minutes.
And trust me you'll like it ;)
it ships with Memory Tagging Extensions (armv9 security feature) and two more years of support than previous generations; pixel 7 might be eol in oct 2027 https://grapheneos.org/faq#device-lifetime
official recommendation page: https://grapheneos.org/faq#recommended-devices
2) there is no real graphene alternative for other devices. I would say DivestOS at least made sane compromises to support less secure devices, but it's unfortunately defunct now. Yes lineage is still around and still the go-to clean 'ROM' but far from security focused. just avoid stuff like /e/ os
Besides doing many other shady things, like putting a proxy between their App Louge and F-Droid (cleanapk.org), while simultaneously not wanting to reveal who owns/controls that proxy? Remember that Android relies on trust on first use. Or running Google proprietary DroidGuard blobs in a privileged process for Play Integrity/SafetyNet? Or giving certain Google Apps elevated privileges when you install them?
I could go on for a while.
(I made the mistake of installing /e/OS on a phone once and then started poking around and it really has many security issues, questionable choices, etc.)
Well I am genuinely interested so I am all for continuing that discussions in details. I am happy to finally meet someone who had a real look and isn't just repeating things read online. So if you have time to share the result of your investigation I'm super interested. But here is not the good place I imagine, where can we continue that discussion?
My only issue with it has been a few apps not working correctly, and not the ones I expected. I did my research before hand and knew that my banking apps would work, thinking those would be the main challenge.
Turns out the bike-sharing system in my city, Madrid, won't work. I ended up installing Google Play services (that run sandboxed in Graphene, but still wanted to avoid), and it works sometimes, but mostly doesn't. I use these bikes a few times a week, so this is a major hassle, and I end up carrying my ancient iPhone with me sometimes just for this.
This and Trade Republic have been my only two problems. Happy otherwise, but do your research before switching, and don't assume only the apps you expect to be problematic will be.
There are some apps I can't do without like ReThink DNS, NewPipe and other open source apps which I use regularly. All would get blocked under Googles new regime.
https://play.google.com/store/apps/details?id=com.celzero.br...
Occasionally, these play store versions of apps are heavily watered down. Termux is an example. Always get that from F-Droid, not the play store version.
And they accept XMR donations, so instant credibility boost.
GrapheneOS has some hardening in this phase, which as I understand, essentially has to rebuild all apps without cache.
And as I have a ton of apps, I was parked for 30 minutes waiting my phone to boot up.
And because of this app optimization thing, I always delayed OS update finalizations, which probably isn't the best thing.
Unfortunately, GrapheneOS recommendation to this was to have fewer apps. Had to let it go after that.
Sounds reasonable. People tend to install way too many apps on their phones and than blame the phone about short battery life or too many notifications.
Android also takes permissions away from apps after they haven't been used in a while anyway.
So most of the battery consumption will be from the apps that you actively need and use. Android's battery usage screen backs this up.
The metro app I installed when I was on a trip in Istanbul is still on my phone, but it's dormant. Yes, I should definitely uninstall it, but I really can't be bothered to do this all the time. On stock Android, phone takes care of this for me. On GrapheneOS, either I take that responsibility or face the consequences - which I don't really want.
I've seen payments being another problem - but Garmin watch handles it for me. And paying with a watch becomes a conversation starter with merchants for some reason.
However Wallet didn't like this setup. Tokens expired at varying delays, sometimes a day, sometimes a week or payment failed without reasons.
Nowadays, I just use my bank's app which work fine on GOS.
I was actually very surprised Garmin supported the country I'm in. They don't even support the language script, I get squiggles, but payments - better than Google Wallet.
GOS has much better battery than stock pixel ui because of less services and telemetry.
> ... Android 17 expands the capabilities of AppFunctions, a platform API with a corresponding Jetpack library. It allows you to contribute your app's unique capabilities as orchestratable "tools" for Android MCP, the on-device equivalent of the Model Context Protocol. AI agents and assistants (like Google Gemini) can discover and execute AppFunctions to perform workflows on behalf of the user with direct access to the app's local state.
Is that implemented in GOS? How is that done securely - giving LLMs power to control some apps?
> With deep integration between hardware, software and AI, we’re transforming Android from an operating system to an intelligence system.
I didn't see any comments on the "ai" features. Are they coming along to GOS or AOSP or staying out and how does that affect Graphene in particular?
That change doesn't negatively affect your privacy it's simply a feature that apps can take advantage of in order to have ai be useful. Similar to the share feature where you can send links or files to other apps.
Of course on many operating systems it's not optional because they add ai as system apps, but gos does not do that.
e/OS is clearly a step up from default Android
It doesn't matter what your marketing says, what's important is what your devices do, and /e/ is much less secure or private than iOS.
Attacking GrapheneOS which makes real progress at privsec.
Thinking that badness enumeration is effective for improving privacy while ignoring real solutions like improving the app sandbox and adding more permissions.
Adding Google services and giving them extra privileges. GrapheneOS ships with zero Google services by default.
It has many default enabled highly privileged Google services including downloading Google Play executables such as droidguard and running those with similar privileged access as they have on a Google Mobile Services OS anyway.
Fairphone quickly stops providing Linux kernel updates and has months of delay for Android userspace backports along with driver/firmware backports. The delay for yearly updates typically starts at a year and gets longer as devices get older and they've always skipped the quarterly updates.
Using a modern SoC, properly configuring it, using proper signing keys (Fairphone has repeatedly used publicly available sample private keys) and providing proper updates is most of what's needed to meet the requirements. That's entirely doable by the few OEMs designing their devices in-house such as Motorola Mobility. Samsung and Google along with many of the ODMs making devices for Nothing, Fairphone, etc.
https://discuss.grapheneos.org/d/24134-devices-lacking-stand...
I know you're already aware of this because it's been provided to you before, but for the folks reading at home, here are the device requirements: https://grapheneos.org/faq#future-devices
> No, them supporting e/OS corroborates the claim that their goal is not privacy or security.
and I asked how they could be convinced about Fairphone's intentions given that the company is tiny and can't develop Pixel-level hardware.
You can't simultaneously claim (incorrectly) that they're incapable of shipping secure hardware while claiming that they intend to ship a secure and private device. (Maybe Fairphone 7 will be the one.) Even if that is is their intention, they're doing a good job keeping it a secret, as their site's main traffic drivers talk solely about environmental ethics and the climate.
Several companies are shipping devices with worthwhile hardware security, and the standards are fairly well enumerated at the link I provided. If Fairphone's intention is to ship reasonably secure hardware then they're failing miserably at it. Same goes for their choice of OS.
Again, that link wasn't for you. You've been told all this stuff for many years. It's for anyone who trips over the thread without already knowing the sheer tonnage of misleading and often downright factually false statements you continually dump in these threads.
Fairphone has a very clear goal of sustainability, which doesn't contradict cutting-edge security per se, but given how tiny the company is, makes it practically impossible. This doesn't mean they wouldn't add the security features if they could. You also like to falsely accuse all vendors producing alternative hardware to Google Pixels, like this one or, earlier, Librem 5 (which btw has the same problem with the small company and big goals).
I'm comfortable with others taking in everything and drawing their own conclusions. That's my only motivation for engaging at this point.
For example, Fairphone has something approaching 200 employees. They're punching well below their weight on the security side, both in terms of hardware and software. Defend them all you want but their approach to security is objectively poor. Repairability and sustainability are good concepts, but not if the device fails at being a decently secure device, which it does. If there's a good reason they can't spec out a better device to be made for them and properly support it, I haven't seen them state it. I wish they would because they've made some pretty neat devices over the years. But a neat device with poor hardware security is an absurd build target to burn finite dev hours on. Something which has been explained to you many times.
Purism, on the other hand, likely can't produce a phone that has security remotely approaching any one of a number of contemporary phone options (beyond just Apple/Google). As you say, they're too small and probably spread too thin. They could stand to dial back their claims to match their reality. They still haven't made a dent on significant issues they themselves flagged more than a half decade ago. Its modem runs on a bus so untrustworthy you probably run a disposable sys-usb Qube on your computer. But that's OK, because you only run trusted software, etc. To each their own.
It doesn't matter how bad a comment looks in your opinion - you have no right for an unsubstantiated personal attack, ever. I though this was common sense, but it turns out, for some people, it's important to remind that.
I never complain about the length of comments but about how much substance they have relative to their length. For example, in this comment, you have expressed your opinion reasonably well* only after two paragraphs of unrelated venting. I have the impression that you consider any opinion that differs from yours as an attack on GrapheneOS and yourself.
Look, I am not against GrapheneOS and I don't care about you. I recommend GrapheneOS to my friends when they want maximal security (yes, really!). I upvote posts like this for visibility. I do not consider GOS an enemy of GNU/Linux phones. I don't like some of GOS decisions, but this is fine, it is just not for me. I don't claim that Librem 5 is more secure or more private. This depends on the user goals and threat model. There are people like me who value different things than GOS developers, and to such people I recommend to consider GNU/Linux phones. I do not post comments saying that GOS has "atrocious freedom" or anything like that. It has more freedom than the default. It's really good at what it does. But it can't cover all preferences and use cases. Whenever people ask for something that GOS doesn't want to provide, I suggest an alternative. I don't understand why you start a fight every time this happens. These are not the target audience of GrapheneOS, let it go.
*I disagree, but I don't expect to convince you. Let us just agree to disagree here.
Supporting all hardware required by fsflover is not feasible for a small project.
https://community.e.foundation/t/voice-to-text-feature-using...
https://codeberg.org/divested-mobile/divestos-website/raw/co...
https://discuss.grapheneos.org/d/24134-devices-lacking-stand...
/e/ and Murena have repeatedly claimed providing strong privacy and security mainly benefits criminals and claim devices doing it are mainly used by criminals. Here's one example of many:
https://grapheneos.social/deck/@GrapheneOS/11635397373214317...
An iPhone is a hardened device with drastically better privacy and security than an /e/ device. It would fall under the claims from /e/ and Murena about hardened devices.
https://discuss.grapheneos.org/d/24134-devices-lacking-stand...
No love for 9 or 9a? I guess it's still coming eventually.
- A 9a owner running GrapheneOS
>Those are just the devices we initially tested it on which mainly has to do with which devices were available to the people working on the port.
>To clarify the 2nd paragraph, we've ported GrapheneOS to Android 17 for all of the supported devices. That's a list of the devices we already built and tested it. Our initial public release will be available for all the supported devices and we'll have tested it on each by then.
As an iPhone user, I really like what Oppo is doing with their ColorOS: https://www.oppo.com/nz/coloros16/
You can change any apps to different apps meaning the keyboard, homescreen/launcher, messaging app. The launcher is a primary UI thing which is different from iOS and is totally customizable by just installing a new app.
So you can change the look of anything that depends on an app, but stuff like the control center, lock screen, volume sliders, connectivity icons, notifications afaict can't be changed.
https://niagaralauncher.com is a cool looking launcher that I used to use.
It's a little confusing but I'll say there's nothing ugly like the stock GOS apps that can't be changed and tha unchangeably UI elements match the Pixel UI.
Here's a comparison which will show both the unchangable stuff like control center, but also the Pixel launcher, which you can swap out.
https://www.youtube.com/watch?v=lwNicPJk4lY
I switched from iPhone and once I installed good looking apps I really prefer the look to iOS because it's a lot faster and smoother.
So far I've yet to encounter any that have passkeys that could speed up the login process, and by using the website you've now fallen back to thier most involved login. You will have to login, then usually answer some security questions or complete a capture, then get the SMS code they sent you. Every time. For async notifications, some banks support emailing or texting you, but it tends to be poor. Hopefully you don't have one of the credit cards like Citi or Amex, which require you to verify flagged purchases via thier app. Otherwise it's a 10+ minute process to do it via phone call, and you have to guess that's why the transaction didn't go thru, call them yourself, get it approved, and try again. Instead of just clicking "yes, that's me" in the app when they prompt you about fraud. And if you click it fast enough, the original transaction might not even get rejected.
So no, the banking websites are not at all good substitute. And it's especially bad for certain banks.
Since they switched to QPRs and Pixel drops, major releases have become less important because feature roll out throughout the year. It's just that nobody outside GrapheneOS and Samsung (to my knowledge) rolls out QPR2, so for non-Pixel/Samsung, the major releases are... major.
I think another major source of work for GrapheneOS is when Google releases QPR1 and QPR3, because GrapheneOS had to rebase the driver/firmware changes on top of QPR0/QPR2.
They've ported the patches to work on top of the latest release.
The apps also need to be updated to the Android 17 target API level but that can happen over several months following the OS itself being ported to it. The app aspect is something all Android developers need to deal with due to new target API levels bringing backwards incompatible improvements.
If I try Graphene what do I lose? Similar to how if you use something like icefox or icewolf one of those very secure browser, lots of normie websites like banking just straight up don't work. What would I lose by moving away from samsung's default to this more private OS?
Fairphone cant be supported because it does not keep up with Android updates and in particular Linux kernel updates. Currently supported Fairphone’s have EOL (outdated, not supported) Linux kernel version. They are bad in terms of other aspects like lack of MTE, lack of USB port(s) control from software level on hardware level (Pixel 6 and newer have that), etc. You cant have privacy without security
But in 2027 this may change due to Motorola and GrapheneOS partnership
It's not one of the main issues with their devices but Fairphone has had a lot of issues with verified boot including using publicly available sample private keys for signing firmware and OS images across multiple device generations. It's not a strength of their devices.
Because somehow this is also a privacy issue. They're really taking this a step too far with making life-saving decisions on behalf of the user: if you call 911/112, you HAVE a reason to do so. If you somehow need to NOT share your location, it could let you OPT OUT.
If you wish so you can gain root privileges on your own in your own build or with modifying GrapheneOS existing builds. It wont be compatible with GrapheneOS provided updates because of signature mismatch
That device, and the Debian derivative it runs, are not private or secure.
Freedom of computing on Librem 5 doesn't end with the root account. It also allows to natively run any desktop software and develop it in any language, without reliance on Google's decision on how one must use the phone, how your OS must evolve and when you may get your updates. Or install a completely different OS from different developers, because there is no reliance on anything proprietary at all.
How you can call a device with a ton of opaque binary blobs more private and secure without mentioning this fact is beyond me. I do not call Librem 5 more secure. But its security depends on what I choose to run on it. And I only run trusted software, so it can be secure.
The protection is achieved through security. The major goal of something like GrapheneOS is privacy, which needs solid security as a prerequisite.
The blobs, while proprietary, are not opaque. They are able to be examined and they are.
The security of a device should not be dependent on what you choose to run on it. You should trust and be able to verify that the platform on which you are running the software prevents something malicious from accessing data which doesn't belong to it or otherwise violates the rules set by the platform (OS).
In this respect, the Librem 5 would do a horrible job compared to even stock AOSP. Thinking that you are secure because you only run "trusted" software on an insecure platform is cope.
So you're conflating privacy with security, as I expected. These are separate matters, although I agree that privacy can't exist without security. And security can be achieved by different means, e.g., by choosing what to run. You can't force your threat model and security approach on everyone and claim that everybody who disagrees with you is insecure let alone has no privacy without good evidence.
> The security of a device should not be dependent on what you choose to run on it.
Why not? What's wrong with it? This is more or less how most desktops work.
> You should trust and be able to verify that the platform on which you are running the software prevents something malicious from accessing data which doesn't belong to it or otherwise violates the rules set by the platform (OS).
This is a big ask, and I doubt that many OSes can provide you such guarantee reliably. I would only trust Qubes OS with that, since it relies on strong, hardware-assisted virtualization and not purely on code correctness (my daily driver on desktop). I guess, regular CVEs confirm my opinion. On Qubes, the VM escape doesn't really happen.
> Thinking that you are secure because you only run "trusted" software on an insecure platform is cope.
This is exactly how security in a typical Linux server works, isn't? This is also similar to security through compartmentalization, when you isolate untrusted software from trusted environments.
I would even go as far as suggesting you to follow my approach at least partially, since installing and using any untrusted app on you GrapheneOS can destroy your privacy as long as the app has the internet access and can send tracking information about you to anyone.
That's a totally defective reading of their comment.
> These are separate matters, although I agree that privacy can't exist without security.
He didn't conflate them, he stated something very similar to your formulation above.
> not purely on code correctness
This assumes a lot that isn't the case about platforms you regularly misunderstand.
> He didn't conflate them, he stated something very similar to your formulation above.
My formulation is not equivalent to "Librem 5 has no privacy", at all.
My comment, which you accuse of not advancing the conversation, was that your comment was internally incoherent. Like some (not all) of your comments, it sets discourse back significantly and the discussion would be much better off without such things.
You admit to holding a preconceived notion that he thinks security and privacy are the same things, which might have something to do with why you consistently fail to interpret some of even the simplest comments. You'd already reached your conclusion about him and didn't truly read his comment, but responded to your preconceived notion of it as soon as you saw the slightest opening. You do that a lot. It doesn't advance discussion.
You're in the second half of your first decade doing exactly the same thing here year after year with an absolute litany of people, including multiple elite developers who are doing incredibly difficult and important work, highly qualified people whose opinions you completely disregard repeatedly. Searching this site for your old threads shows a certain imperviousness of thought. You already have your talking points and you're not budging from them.
Which is fine, some people are just like that, and I'll continue to weigh in on high-traffic threads to make sure you don't harm important projects with your usual comments, but engaging directly with you is as tedious as it is pointless and I won't be doing that much.
I'm not sure what your motives are, but either way there's no upside to doing anything beyond making sure casual readers of high-traffic discussions won't see your more defective comments go mostly unchallenged (as many others have already wisely moved on from engaging with you).
The biggest hurdles for me were - should I use separate profiles and how to get apps. Initially, I started with a separate profile for google stuff (like play store/services and apps downloaded from there, like Viber), but eventually I moved everything to the owner profile (and took a bit of a privacy and battery hit in the matter of convenience). Still, being able to control many app permissions, gives me a good state of mind that apps are not doing more then I expect.
Just looked at what android 17 brings to the table and I'm mildly excited - especially improving performance and adding more permissions (like ACCESS_LOCAL_NETWORK)
In the USA, I think most people can easily afford a Pixel 9a at $56/year of device support starting from today. Calculator checks yearly cost based on device support: (https://ibb.co/xq82YQCw)
Sources for device lifetime from calculator: (https://grapheneos.org/faq#device-lifetime)
I used a New+Unlocked+Pixel+X on eBay to find a rough price of the phone.
Most people get scammed by their carrier and pay $25-45 per month just for their wireless subscription, and many more get caught up in the device bundles which gets you the "latest and greatest", at a huge price. So people are paying, per month, what you can pay, per year for a Pixel.
Pixels provide strong hardware and firmware security. Pixels have made multiple significant hardware and firmware level improvements based on recommendations by GrapheneOS. GrapheneOS now has a hardware partnership with Motorola Mobility which includes working with Qualcomm. It isn't only a software project.
Regularly leaked data on the capabilities of Cellebrite show they have the least success with GrapheneOS by far despite specifically hiring for it based on their job postings.
That’s why I have two phones. One runs GrapheneOS and is my daily driver; the other (considerably less private and secure) stays at home connected to my server so I can always scrcpy into it.
Few questions if you dont mind answering: - do you have to keep the phone screen switched on? - Do you access via VNC? - Can you access it from another phone? is it usable?
Thanks!
If you've confirmed your banking app won't work on GOS, have you considered accessing your bank's website through your phone's browser instead?
Reqs: https://grapheneos.org/faq#future-devices
Currently that means modern pixels and the next generation Motorola flagships once they come out.
Requirements: https://grapheneos.org/faq#future-devices
Pixels were headed towards all of the device support code for the OS being open source along with open sourcing large portions of the firmware including for the TEE (Trusty OS) and secure element (OpenTitan). It was ended after the launch of Android 16. It's a major factor in why GrapheneOS is going to be focused on future Motorola Mobility devices. You can still see a large portion of the Pixel userspace driver libraries and services in the AOSP source tree but they stopped pushing new releases for a lot of it.
You ask the same questions again of the same audience, year after year after year, either misunderstanding or totally disregarding the numerous simple, clear and direct answers you receive.
What's going on?
When I do recommend GOS, I want to know what I recommend precisely. Have you got an article about GOS similar to this one? https://pine64.org/2020/01/24/setting-the-record-straight-pi...
also, there's ZERO mentions of drivers or binary blobs on that link!
Many apps that work on microG don't work in GrapheneOS without installing Google services anyway. I'm by no means across the full privacy implications, but my feeling is microG balances privacy and usability better for me.
I've since switched back to LineageOS+microG and am happy with it. Just my experience.
lineageos has built-in firewall for years now. no need for afwall.
Contrary to popular belief, exploitation of vulnerable devices is a lot more common, and a lot easier than people pretend it is. You dont need to be targeted either, mass exploitation can, has, and will occur.
LineageOS does not have privacy, security, or usability comparable to GrapheneOS. LineageOS is missing many important features and falls behind android updates. GrapheneOS will be the far better choice in all 3 of these categories.
The features GrapheneOS provides, such as the network permission, cannot be replicated with a firewall app. The network permission properly covers all forms of network access for an app, where firewall apps do not have the ability to prevent all network communication. They are leaky.
The AGNSS servers and proxies are very, very tiny aspects of what GrapheneOS provides. You would be losing out on many more high impact privacy, security, and usability features.
Root access and an unlocked bootloader are insecure, even for low threat models. These devices are vulnerable and should not be used for any sensitive data.
LineageOS is not the better choice for any privacy, security, or usability usecases relative to GrapheneOS.
Extraordinary claims require extraordinary evidence. Got any?
The rest of the comment consists of even vaguer statements about how it's better in every way and then (circularly) drawing the conclusion that it's always the right choice because it's better in every way. I have no idea how to respond to these opinions than either writing a book that goes into every subtopic you're touching on, or just concluding "ok that's your opinion". Maybe consider that others may disagree by having different values and priorities than you, and so it's not strictly always the best option
Every month, vulnerabilities are published and publicly accessible. The more out of date a device becomes, the more vulnerabilities are available. This is made worse when the integrity of the operating system cannot be verified and root access is exposed. Avoiding this is not a high level threat model, that is the bare minimum.
not sure about downloads specifically, but app installs are slow because grapheneos forces AOT compilation (JIT is disabled), presumably for security reasons.
Buying a used Pixel is economical, environmental, and likely doesn't support Google. Pixels are the only secure and open android devices that could work for the project and meet the extensive requirements[2]. This is because GrapheneOS takes real steps to protect user privacy and security, not features that degrade security and don't increase privacy. You are going to be doing much more against Google by using GrapheneOS because it comes with 0 google services by default and takes advanced steps to protect you from all apps and services you install.
If you are still not willing or able to purchase a Pixel, GrapheneOS has a partnership with Motorola to help them create compatible devices which will be available soon[3].
[1] Privacy and security on computing devices need to become far stronger to protect people from pervasive violations of their rights. https://xcancel.com/GrapheneOS/status/2044440381803069778#m
[2] https://grapheneos.org/faq#future-devices
[3] https://xcancel.com/GrapheneOS/status/2028448871374803007#m
That said, Google's hardware is behind their competitors and they've had a lot of problems in the past few years. The Pixel 8 Pro has hardware WiFi problems, the 9 and 10 are both minor updates with prices that are far too high, the 10 is eSIM only, etc.
The prime difference between P8 pro and P9 pro is that the newer one is nearly a usable size (just about fits in a pocket now). The battery also got substantially better in two ways: on mobile data (when you're on someone's WiFi, odds are you're also near a charger) you get 33% longer use time on all variants of the P9 and 55% on the P10 and P10p (9 to 12 and 14 hours, respectively), and hours of use per 30 minutes of charging went up from 4.6 for the P8 to 6.3 for the P9(p) and 6.2 or 7 for the P10 and P10p, respectively
The rest is indeed relatively minor but it's not an unwelcome upgrade. Prices didn't change much when buying second-hand 1.5 years after release, when the newest devices are out and nobody cares about the generation-before-last despite >5 years of updates remaining (plus however long you think it's fine without updates)
It's true that the SoCs are not that great for an expensive flagship phone, but the trick is buying a Pixel halfway the cycle, when the prices go to mid-range. For instance, currently in my country:
- Pixel 10 is 350 Euro off (currently 549 Euro).
- Pixel 10 Pro is 360 Euro off (currently 739 Euro).
- Pixel 10 Pro XL is 360 Euro off (currently 939 Euro).
- The Pixel A series are less interesting currently, because it's still early in the cycle, but the 9a is 200 Euro off (349) and the 10a is 120 Euro off (428). It's a shame that they switched to last-gen SoCs and modems now on the A-series now.
I know that the Pixel 100 is coming soon-ish, but the 10 series have floated around those price points since 5-6 months after the release.
the 10 is eSIM only
Looking at my P10P with physical SIM. I guess you are in the US?
Interesting. What do you think are reasons for google to run Pixel then?
Not being sarcastic here, but what links you shared (thank you) say imply there are almost no benefits for Google to run Pixels and as we all know, Google is not a company doing charities.
Get millions of users using their services. The average person who buys a Pixel will likely go all in with the Google ecosystem giving Google every word they type, every message to a loved one, every search. It's a data gold mine.
I doubt they sell Pixels at a loss, but even if they did they could make up for it like how Amazon does with kindles.
https://www.forbes.com/sites/zakdoffman/2026/04/28/price-of-...
I think they also use pixels for testing android and such which is why they keep it secure and open.
I still don't want a pixel, so I went with a used ebay phone and installed lineageos.
Everything else is meh, bad, or atrocious.
Next year we'll have Motorola flagship(s) to choose from. Can't wait.
See https://grapheneos.org/faq#recommended-devices for the device recommendations. There are going to be Motorola devices with GrapheneOS support within a year too.