I've been running GrapheneOS for 7 months now and I'm not going back. When I bought my Pixel 10 last year, I wasn't actually planning on trying Graphene for a while....until I noticed Google had force bundled a 'Wicked For Good' movie promo theme with the latest security update.
Ha! Me too! Exact same. Bought a Pixel 10. Intended to do the default Android for a while. But it was filled with ads for “Wicked” which had me looking at my phone with a sneer on my face I couldn't erase - as if someone had smeared feces all over it and threw it on my bed.
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.
Eye opener. Thanks for the warning! GrapheneOS sandboxes all apps including GSF as far as I understand. It would be nice if full capabilities could be exposed or at least shown in the app settings. There is the "All permissions" view which has a "have full network access" item with the following details: `Allows the app to create network sockets and use custom network protocols. The browser and other applications provide means to send data to the internet, so this permission is not required to send data to the internet.`
Does this mean the app has this permission and even without it can fully access the internet? If so the primary "network" permission is very misleading. I wish for a smartphone-like device which installs apps with `cap_drop: ALL` by default. I wish for a government which would support such a standpoint and "assist" companies not able to provide a service which require intrusive data gathering. Either that or we're all just one big happy family with no secrets and no jealousy and no drama. sigh
Every Android app can do IPC with Android apps in the same profile. So an app without Network Access could cooperate with an app with Network Access to communicate with the outside world. Of course, most notably, a lot of apps communicate with Play Services and people generally leave on network access for Play Services to avoid breaking to much stuff.
There has been talk of developing 'IPC scopes', similar to how there are contact scopes.
To my knowledge, any app can just instruct the installed browser (Google Chrome, Vanadium, Firefox...) to open http[s]://tracker.evil-ad-network.example/?installedId=012345.
"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."
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)
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."
That sounds like the answer is actually yes: we're not talking about the lack of a camera app, but the lack of a camera app that knows the details of the usually-proprietary camera firmware
Problem with stock Google camera app is that it made horrible HDRlike images even with HDR turned off. You cannot adjust amount of reduced highlights and increased shadows which makes images unrealistic with lack of depth.
I mean...... Google Camera has slightly different approach to low light photos and much better panorama mode, which means you can just install it and use with network access denied.
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.
What you are describing is not Google’s alturism but keeping competition in check. If Google didn’t “allow” GrapheneOS it opens up a new market segment for other smartphone manufacturers. Apple really cashed in on privacy for a few years so it’s not unfathomable that Xiaomi or someone else goes all in on “privacy focused android” in absence of pixel+graphene combo.
I don't think any Chinese company can pull the privacy card. They're bound by their government to spy on their customers just like American ones are.
Otherwise Huawei would have already jumped into that gap. They have their own Google-independent OS now so they could have marketed it to privacy enthusiasts where the lack of Google services would have been a positive not a negative.
> Apple really cashed in on privacy for a few years
Apple didn't "cash in", their marketing dept made sure privacy/security engineering got just enough budget to pull off miracles & then spend even more to successfully make the public forget about the very nasty Celebgate.
TBF if Google locked down the devices like that it would be a GPL violation. Not their first or whatever but still, there's a reason for them not to do that beside "being nice"
It's also because so many Linux developers are on the payroll of big tech. Look at all the submissions. 95% are just big tech. And look at the key people in the Linux Foundation. All a bunch of business suits with compromised motives. Serving their company above the community. There's only a few unencumbered people in there now.
Linux is no longer the community-driven choice. It's big business with billions hanging on the line. The grassroots origins are long over.
And how many options are there exactly? How many of them are capable of at least making and receiving a phone call without any issues 99% of the time?
While I agree with your general sentiment, I feel necessary to acknowledge that it's just not there (yet?). GrapheneOS is a great option if you want to have a fully working and secure device.
Years ago I looked into GrapheneOS, and I ultimately didn't go with it because, at least at the time, they only supported pixel phones (specifically pixel phones that Google actively had security updates for). I realized that if I got that OS, I would be at the mercy of Google supporting the device in order to continue using GrapheneOS.
In the end I just opted out of the android ecosystem altogether and went with a flip phone that I used as a hotspot for an iPod touch (we only used over VPN with locked down DNS and nothing google related).
My privacy lasted about two weeks, because unfortunately Spotify was able to fingerprint that device to Facebook.
I would highly recommend LineageOS. Supports non-Pixel phones, some of them many years old (although now that I double check, the Galaxy S3 and OnePlus One aren't on the devices list anymore, I guess they do stop supporting old stuff eventually...). The OnePlus 5 is still supported and was released in 2017. For anything older than that, I guess I'd recommend looking into postmarketOS.
I thought the PinePhone community had succeeded in making custom firmware for the modem in the PinePhone, though I'm not sure of the legality of actually using it. Plus both PinePhone and Librem 5 had a killswitch to disconnect the modem at least.
Your point is valid and yeah, it's a never-ending fight just to keep the control we have. Things like the Play Protect API and loads of Android apps being coupled to Play Services is it's own big challenge we're stuck with just to stay within the Android ecosystem
Big list, unfortunately one of my banks is not there (BCGE, Switzerland), most probably meaning I can't even login into ebanking in any other way since they have their properietary authentication app (CrontoSign, also not listed). Its rather small regional/cantonal bank so I get it, even though that region is Geneva, mecca of (some types of) banking.
Other banks that I use are there. Almost perfect...
Being missing means they haven’t been tested, not that they don’t work. Generally they probably only don’t work if they require the google play verification thingy
My banking apps were missing in list too, it doesn't mean that they are not working. You can test and report on that issue tracker about your banking app if it works :)
If your bank doesn't have its own payment app, but PayPal Card is available in your country, I got this setup to work on Graphene by installing PayPal into the Secure Folder, install the sandboxed Play Services there (required) and setup the mobile payments in the app. It's not a great solution, but for I keep it around for emergencies.
My banks app complains will block me and tell me to disable developer mode, but if I turn it right back on after launching the app it won't complain for maybe another week. The post that really annoys me, though, is that if you don't set up biometric unlock they will not allow you to use the extended login cookie, so you need to put in your password every time, most don't work with password managers either (whether intentionally or not).
iOS is also going into this direction, just open the AppStore, it’s all the cheapest most horrible apps. Temu (shop like you don't give a s* about the planet), addictive AI Waifu’s (who needs human interaction anyway), clean your stuff but fake-time-wasting style (it's free dopamine!), search option’s first hit is often scammy (ie search for MS Authenticator). I feel that Steve ("If you want pr0n get an Android") would turn around in his grave from the sight of this.
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.
The AppStore has been like that for eons, but then again I don’t know a single person that uses it or checks the “content” posted there. It’s an utter waste of time.
I don’t think it will leak. After the U2 debacle, Apple might have learned not to push too hard on this front.
All factory operating systems come with ads and bloat and spyware, Apple/Samsung included. Google remains the lesser of all other evils because at least to date, they offer an open source OS, bootloader unlocking, and root. A community driven mobile OS is absolutely where we should go, but for now and the foreseeable future you can call a Lyft, deposit a check (in America), and do other mainstream tasks on AOSP flavors without Google/Apple/Samsung having to know anything about it. It's never been easier to make the user friendly choice too: https://grapheneos.org/install/web
Technically they already did a built in ad with Android KitKat. Mostly benign, but I do remember being at an Android event and KitKats samples being given out to everyone. As well as KitKat wrappers being branded with the Android logo for a while.
When I got a new phone last year, I purposely got a Pixel (open box 9a) to put GrapheneOS on it immediately. Been happy living the de-Googled Android life since.
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.
If it's any consolation, the wipe* requirement before unlocking the bootloader is generally a good thing, even if it's inconvenient. Someone who is targeting your personal data gets access to your encrypted phone, either by stealing it or in an evil maid situation. They unlock the bootloader and install privileged code that helps them recover the symmetric encryption key or intercept your PIN. Then they either have your data or wait for you to enter the PIN. In theory recovery shouldn't be possible (access to the key depends on a secure element that rate limits brute-force attacks), but security bugs do happen. Wiping* your data before removing the bootloader's signing requirement is an extra layer of protection.
*It doesn't actually wipe your data; it just destroys the symmetric key, making the data permanently unreadable.
While the OOBE of the stock image doesn't force an Internet connection, the ability to unlock the bootloader does - whether you can do it or not depends on the phone manufacturer's desire, and Android for some reason uses an Internet connection to check that.
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.
Yep, on older phones it was certainly possible without an Internet connection.
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.
it should be possible on Sony and OnePlus phones and maybe other brands, though it can require obtaining code from internet on other device, but the device being unlocked itself doesn't need to have internet connection
I think LG had a system for getting unlock codes as well, but they closed it a long time ago.
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.
...I feel a bit silly. When I said "Android 7+", I was thinking of my Pixel 7, which runs Android 13, so "Android 13+" is what I actually meant to say. Oops.
I run a litany of Google (and other corporate/business apps) apps in Private Space under the owner's profile, which is only unlocked when I need it for something. That space's connection can go out over a WireGuard tunnel if I need those apps to be on any specific networks, while the rest of the phone's traffic is unaffected. The file systems stay functionally separate (although that's not a major concern given how file encryption is handled, plus the dream that is Storage Scopes), and that space has its own camera app and such.
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.
Yes, you install the Google Play store via the GrapheneOS App Store. The OS comes with like 5 apps out of the box. The rest is up to you.
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.
Android Auto is fully supported and shouldn't be any more flaky than it is on the stock OS. It's often flaky due to a bad USB connection or problematic implementation in the car. That's just how it is everywhere.
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.
Yes, I mean MDM work profiles. I play an IT guy at work and am a Google Workspace admin. We have it running in BYOD mode and it's actually not intrusive at all. The most sensitive data you can see as an admin is what apps are installed in the work profile, the phone's make + model, and the version of Android. Nothing like location, charge level, or anything outside of the work profile. I'm fine with running it on my personal device (I actually really like the way it functions), but it's borked on current versions of GOS.
My end-run around Google's absurd unwillingness to certify GOS for Google Pay has been Garmin Pay, which has worked virtually everywhere I've ever tried it.
I'm hopeful that an OEM Motorola device will get certified for Google Pay.
Depends as bit on the country and bank. I also use Garmin Pay, but my bank only supports adding their credit card (not debit card) and a substantial portion of shops here only supports contactless payment through debit cards (credit cards have historically not been popular here).
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.
When using contactless payment with my card, about 10% of the time the payment terminal tells me to insert the card to the reader slot instead and enter my PIN. I assumed this is a general security feature, but I guess it depends on the issuing bank then. This in Europe.
Garmin Pay, Samsung pay if you have a compatible bank and card, PayPal in Germany and sometimes banks' own systems.
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 believe one of Graphene OS's main features is that they allow you to run google play services in a sandboxed environment, so you can run your standard google apps but without the standard android deal where google play services has unfetteted access to all your phone's location/data/etc info
Yes, those are all compatible and the only way to use them is as regular sandboxed apps without any special access. Sandboxed Google Play can be installed in the profiles of your choice. Installing it in the main Owner user is a valid choice and doesn't at all ruin what GrapheneOS provides but you can make a dedicated work profile or Private Space for it to keep it separate. Only apps in the same profile can see it and use it, so you can control which apps will use their functionality depending on it that way.
> I'm not looking to fully de-Google but I want Google as apps and not my OS.
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.
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.
> 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.
I agree and have moved mostly away from everything Google. But it's hard to replace maps. I know open street maps exists but it's hard to beat Google's data gathering.
I think OSM is way way better. It has every little path in the hills I walk. On Google Maps I'm just walking in a featureless green blob. OSM even has unofficial trails that are no more than a worn-down line in the brush.
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.
I use Google Maps on Graphene. It works perfectly. You still get the benefits of the rest of the phone being degoogled. Just allow it to access your location only when you're actively using the app. When it's closed, it's closed.
There are players in the OpenStreetMap ecosystem attempting to change that. I know the team behind Organic Maps are actively working to make their app as viable as possible by sourcing appropriate data for example.
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.
TIL there has been some drama about Organic Maps, what is the difference between OM and CoMaps?
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
what's the point of the fork if it's missing basic features of the original app? it can't even display tram lines when tapping on tram stop...
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?
I've been using HERE WeGo for almost a year. I had to install a text to speech engine in order to get voice directions. (I installed the GlaDOS one, now the evil computer tells me where to go.)
I use CoMaps in the owner profile with Android Auto. Only caveat is that even with Android Auto developer mode enabled, I still had to install CoMaps from Play Store to get it to show up in Android Auto.
It used to be really good, and then it went to a subscription model, with a lot of back-and-forth uncertainty about the change. I suspect the rating reflects that.
Using Sandboxed Google Play doesn't defeat the purpose of using GrapheneOS and neither does using Google apps. It does not exist specifically to avoid Google apps or services. It exists to provide a highly private and secure OS retaining high usability and app compatibility. Being able to use sandboxed Google Play is an important part of what it provides. Many GrapheneOS users don't use it and many who do use it are only using it in a dedicated profile for a small subset of apps but that's not at all required to heavily benefit from GrapheneOS. Moving to more private apps/services over time does make sense but it isn't mandatory and users can choose what kind of compromises they wan to make.
Seedvault is still woefully insufficient, but it sounds like there's work being done to replace it. I can't imagine the enterprise crowd will overlook that and I'm hoping the Motorola partnership enables faster development.
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.
For people with no other albums, Carplay was playing that U2 album automatically when they enter their car. So some people were forced to listen to it :-)
Yeah, I'm hanging on with GrapheneOS (on a Pixel) until their native-hardware (Motorola) phones come out, which hopefully will solve this. As I understand it, third-party (banks and so forth) app vendors have to accept their security attestation, which they don't right now, but (I hope) will with Motorola behind them.
Graphene is NOT a jailbroken/rooted OS, its a real secure unrooted, bootloader locked OS, and MS Authenticotor works just fine.
If anything does not work its related to dependency of the App maker on a certain attestation google play services grapheneos.org/articles/attestation-compatibility-guide
Root =/= insecure. You probably have administrator access on your home computer operating system, and can very likely do online banking via the web browser with no issues. A secure API is possible regardless of the host metal, operating system, or user permissions.
Do you refer to app-accessible root or user root access? The former is absolutely inherently insecure and compromises the security model of Android/GOS.
Root on computers is insecure. Malware can steal secrets from other applications. We're just used to it, but the Android security model is much better.
This does not play a role - even if you lock your bootloader Play Integrity Checks still fails, and that means you can't use certain apps, MDM and overall restricts your usage. Thank Google for that.
I hate how common it's become for companies to force you to install things on your personal phone. Even worse is some of them demand you install a MDM profile on your personal phone which feels 1000% over the line of reasonable.
I've just refused to install such things on my phone.
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.
Sure if you are in a strong stable position in life you can do that. The average person doesn’t want to rock the boat and cause troubles in their life so they install the invasive mdm profile.
It needs to be made illegal imo. The company should provide you a device if you need one for the job.
I think Google authenticator implements the standard OTP which lots of apps (including keepass) should support.
Microsoft uses their own propietary crap
You can try to add the standard OTP even for Microsoft crap. If it asks you to register for mfa and opens the screen that says something about downloading the Microsoft authenticator app there is a small link at the bottom, letting you use another app. Then you get a qr code that you can scan with any other auth app.
I use a basic OTP password instead of Microsoft's ironically less secure (see SMS as 2FA) with my work MS account. Perhaps your org disabled it but it is definitely something a Microsoft account can do.
Proper Microsoft authenticator setup is more secure than OTP because it's pushed based and doesn't allow users to copy paste their OTP codes into phishing sites. Google also prefer push based MFA for this reason.
Push based, sure. Allowing SMS, I still hold, undermines all of this.
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.
Happy GrapheneOS user here too since 2+ years now.
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.
How's the P10 camera on graphene? Literally 90% of the reason I'm on a pixel is because I love the low-light smarts that the camera software has, but I don't know if I'll lose that with Graphene.
Banking 90+% of apps work. Some apps officially support GrapheneOS.
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.
This is not really about me, but understanding if these apps have issues running under the OS. These type of apps typically have extra "security" features.
> Such as? If there is dependency on proprietary software, you can install it on GOS if you want and consider it more "safe".
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.
I want to run graphene but I make android apps and need to test on device with a somewhat standard setup… login with google, etc. is this reasonable to do with graphene?
Yes. GrapheneOS maintains 99% app compatibility, and the 1% that is lacking is due to apps using incredibly misguided and nonsensical "antiabuse" mechanisms.
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.
Yes you can install and use it (I hold my passes, tickets and loyalty cards in there), BUT payments won't work for now because Google says malware-ridden Oreo handset is safe and secure, but phone without ad delivery network running in the privileged mode isn't.
There are alternatives for payments (scroll the thread, maybe look up on GOS discussion site).
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.
What are you using for cell service? Been wanting to switch to GOS for years, but I've also been really uninterested in having to find a new service provider (currently using fi).
What's the status of banking apps, Google / Microsoft authenticator, and Google Wallet? Those were the things preventing me from abandoning stock Android.
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).
Same, I've got a Pixel 9 and GrapheneOS works perfectly on it. I really love having full control over the OS on my phone and being able to decide what actually runs on it.
Yep, I've used both. Desktop mode isn't exactly there yet, but hopefully with the general availability it will get with Android 17, it'll smoothen out. As for the Linux terminal I ended up sticking with a fork which provides a few extra features (https://github.com/outlawsanzhang/koiTerminal)
That Motorola phone that lets you install Graphene can not come soon enough. Pixel phones are not sold worldwide so it feels like they're gatekeeping security. I know that's not the case really, but there's very few ways to successfully degoogle otherwise.
Not only obtaining but if you ever need warranty you're done. Just last week I went to a Samsung center and had my fold 6 fixed in 30 minutes, and these centers are everywhere around the world. Same thing with Apple, yet a 4.5 trillion dollar company can't ship and maintain a phone globally. It's so unserious.
And that's the unserious part, they really don't want anything to do with consumers despite making consumer products (gmail, Android, etc.) so you're always at the mercy of their automatic systems.
But when there was a battery/overheat issue with pixel 6a, I must say Google handled the fix / compensation surprisingly well. My sample size just being me, but very smooth process and compensation processed rapidly.
Yeah. Could be difficult even if one is willing to forgo the warranty. My city has local repair services, they easily repaired my old Samsung phone. Servicing Pixels could be difficult even for them.
The inner screen built-in protector was peeling in the middle. It was out of warranty, but Samsung charged me 15$ which is very reasonable. The inner screen looks brand-new now, and I guess that's the benefit of these soft foldable screens - you can refresh the entire thing very easily.
GrapheneOS does not depend on all of the features of pixel phones. The baseline requirements GrapheneOS has are generic, they are not built upon or tied to what pixel phones provide. Pixels actually exceed the baseline rather than barely meeting them.
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.
Phone hardware is a hellscape it doesn’t surprise me at all that they need to keep the number of supported devices small in order to deliver a decent product.
Despite Google's other failings, it was the OG supporter of data portability, and that spirit extends to its phones. No other phone manufacturer with wide distribution comes close. It's unfortunate that the people who design the hardware do such a poor job with the resources at their disposal.
Is it still the case that Android backups leave much to be desired when compared to iphone? Pretty much the only reason I use Apple is that I can switch to a replacement phone and it’s exactly the same state as the last backup.
GrapheneOS is not going to compromise on hardware security for the sake of spiting one specific company. GrapheneOS supports all viable platforms, and right now that is the pixel lineup. Additional device support requires OEMs step up their game, and so far, only Motorola is up to the task, and we should get Motorola devices with official GrapheneOS support next year.
There is nothing crazy about doing something properly.
How do you reconcile that position with what Graphene OS lists as requirements for support, as linked by another commenter? https://grapheneos.org/faq#future-devices
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.
It is not ridiculous at all. GrapheneOS is not going to compromise the privacy and security of their users for the sake of spite for one specific company. It would be immature and irresponsible to make important choices based on spite rather than objectivity.
Motorola has stepped up to meet the baseline requirements for GrapheneOS support, and we should get Motorola devices with official GrapheneOS support next year.
They could also just sell the phones with GrapheneOS already, as the final state of a GrapheneOS instalation has a locked bootloader.
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.
I just moved away from GrapheneOS to Motorola because I decided I needed an audio jack again. There's definitely some annoying things about leaving, but at least now I can use again the three apps that didn't work for me on GrapheneOS...
Which phone and is it android then? Maybe I'm out of the loop on Motorola. I just bought a pixel, thinking of trying graphene. I was a bit miffed about the lack of jack until my partner pointed out I hadn't used the one on my old phone for over a year. I'd like to in the future though.
Posting about Volla in a GrapheneOS thread is... I guess courageous?
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:
I don't see anything they offer for security that's not also in AOSP/LineageOS/eOS/stock/etc.
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
Not GP, but Volla phones are cool in that they officially support running proper Linux[1], so you could just use Linux instead of Android if that's enough for your needs. And you can still boot into their de-Googled Android if you need to run Android apps.
(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:
It takes more than an unlocked bootloader to make Linux boot on random phones and work properly (and ensuring all the radios, camera, audio, phone calls etc work), and Volla have achieved that with their phones. I could be wrong, but I don't think it was possible to get a fully functional Linux distro going on any of these rebadged phones before Volla got to them.
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.
Ubuntu Touch is drastically less private and secure than AOSP let alone GrapheneOS. Volla's devices don't come anywhere close to meeting the update and security requirements for GrapheneOS. GrapheneOS is a Linux distribution much closely following along with the Linux kernel LTS releases, unlike those devices. It also regularly moves to new Linux kernel LTS branches. Pixels are in the process of moving to the 6.12 LTS branch with Android 17 QPR2. 6.18 is currently in the early stage of stabilization.
Ubuntu Touch (or any Linux distro for that matter) offers drastically more freedom than GrapheneOS or any other Android distribution. Some people care more about freedom than so called "security", and I don't know about you, but I'll take freedom any day.
Freedom to get a stroke from an incomplete toy OS?
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.
Not everything needs to be "production ready". And giving out root willy-nilly is freedom. It's my device, I should get to decide how I want to use it and not have artificial restrictions put on my be by someone else. If I want to rm -rf /, I should be able to do just that.
>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.
> 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.
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.
> 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
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.
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.
MicroG requires privileged access. It also downloads and runs proprietary google code within this privileged context. MicroG additionally has very poor app compatibility and has had severe privacy issues in the past.
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.
Thanks, but there's no way anybody here hasn't already heard all of that. GrapheneOS' statements are inevitably reposted to every thread and subthread that touches on the topic.
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?
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
For context, GMSCompat is Google Mobile Services Compatibility. GrapheneOS installed the google play store and services as normal apps, and worked backwards to make it behave. There is no google specific sandbox, rather it uses the standard android user app sandbox. This means google is bound by the same rules, as special casing anything creates more maintenance burden and attack surface. GMSCompat is fully open source.
> "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.
> How can you be free when you're not private or secure?
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.
Privacy is when nobody is looking, whether that's because they cannot look or because there's nobody that looks.
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)
That is a vague, meaningless statement. What sort of privacy are we taking about? What sort of security? What's the target? What's the attack vector? What's the environment? What's your threat model?
Without all of those details, your statement is meaningless.
Oh, one vendor supporting multiple OSes! I hadn't clicked through (https://volla.online/en/operating-systems/), that is neat indeed and quite a unique selling point among mobile vendors
This should have gone in my spreadsheet before I chose a new device xD. Ah well, next time
Android similarly supports, and in fact uses, "proper" Linux. Android and its forks are Linux distributions. You can use a mainline kernel in Android just fine.
Nah, Android is not a really a proper Linux system that 'supports' Linux software within any reasonable definition of the word; not anymore at least
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
Most of this is not related to the claim and is more tangential discussion about things you like that run on the linux kernel, now, there is nothing wrong with that, but I must emphasise that none of what you describe is a part of the criteria for what constitutes a linux distro. A linux distro is an operating system using the linux kernel. Android fits that criteria.
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.
Sure, we can have different opinions on what makes a useful Linux distribution. Either way, you can't install Ubuntu Touch on just any phone. That Volla supports that alongside their AOSP derivative gives you more options on how to use the device; it's worth pointing out to potential buyers as a bonus on top of running Android only
Those are much less private and secure than the Android Open Source Project on Pixels without the major privacy and security improvements of GrapheneOS. Those aren't privacy or security hardened devices.
I've been using Graphene on my Pixel 7a for about a year and I'm happy I made the switch. For sure it is a bit rougher than using Google's OS, but not enough to make me regret it.
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."
> 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,
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
> 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.
Yes! FUTO keyboard, then go into VOICE INPUT → MODELS → Explore Voice Input Models → English-244: “Best for the most accurate results, but more demanding.”
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.
I just did. I had been using FUTO voice, but I see that FUTO keyboard also supports voice input, so I'm not sure if I should delete FUTO voice as being redundant now.
I don't believe it's necessary, it's move of an "if you want a dedicated voice keyboard, the UX is a little better" option. I don't have both installed though, as anecdotal evidence.
Thanks for your thoughts. I use FUTO voice usually, but there are situations where typing out a short message is better -- eg, in a restaurant or doctor's office or someplace where voice input might bother other people.
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.
> 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.
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.
FUTO and GBoard has the feature you're describing and I use it all the time. Pretty much anything you miss from Pixel UI can be attained by simply installing Google's app from the playstore.
The problem I still have with the futo one is that it can't swipe type in multiple languages without switching every time. Gboard can do that. I use 3 languages intertwined constantly so I need that.
So I still use gboard but block its internet access.
Problem (1) is a keyboard problem, not a GrapheneOS problem. Graphene comes with the stock AOSP keyboard which is very basic, but you can absolutely replace it. Personally I'm using the FUTO Keyboard and it does have that feature, as well as swiping, speech to text and much more.
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.
Regarding 2: that is literally how SMS reactions work. Apps that recognize it just interpret it as "put that emoji on that message". It is unfortunate that it doesn't do that tho.
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).
There have been consistent problems with activating RCS, for many years. But it does work for some/many, yes.
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.
It's always good to be wrong about good news, then :)
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.
I agree with this post and add one anecdotal data point.
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].
Yeah, it's pretty awful tbh. I generally recommend disabling RCS, after learning a lot more about it - it feels like a hostile grab at global messaging at this point, heavily entrenched by telecom agreements. Use Signal or something instead.
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?).
Yeah RCS always has been an embrace extend extinguish thing. The carriers were super pissed to lose their SMS revenue to WhatsApp and iMessage so they came up with this shit to be an active partner in the loop again, and they can bill for it again. Consumers didn't fall for that and it died off.
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.
> Yeah RCS always has been an embrace extend extinguish thing. The carriers were super pissed to lose their SMS revenue to WhatsApp and iMessage so they came up with this shit to be an active partner in the loop again, and they can bill for it again. Consumers didn't fall for that and it died off.
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.
RCS is not modern. E2EE is only an addon and it's not open. As others have mentioned it's not even available with interoperation. And it was really invented by carriers for exactly that purpose: To regain SMS/MMS revenue. But at this point here in Europe SMS usage between people had vanished anyway (except for spam and poor 2FA implementations)
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).
No not really. It's technically available but nobody uses it. Everyone is on WhatsApp. Even companies. I never get messages from contacts on SMS either (so it's not going through fallback). I think it's because iOS just isn't really that widely used here. Not used enough to have critical mass for an iOS-only messaging service.
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.
This is an extremely strange rewriting of history in which Google is some kind of altruist, moved by the plight of suffering school-children in a brief period where the rich bullying the poor (something truly shocking and unprecedented) over the color of their messages simply couldn't be tolerated any further.
Yeah what would really get me onboard with RCS if it were actually open, if I could choose which RCS provider I wanted to use. Like a privacy-driven foundation similar to Signal. Someone I could actually trust.
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.
I wouldn't be particularly surprised if they're hiding the spec / charging pointless $$$ to reduce access, but I was under the impression that it would be available, like RCS's spec itself. e.g.:
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.
Ah when I last checked the E2EE was only in practice implemented by Google and invented by them. It looks like this might have been opened up, unless this is an earlier version somehow? And interconnect traffic to e.g. iMessage was not E2EE.
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.
yea, from my understanding Google has had E2EE when messaging itself for a couple years or so now, mirroring how iMessage encrypts messages to itself. iMessage is even very similar (maybe identical) to MLS, and Google Messages might be as well but I don't know the details. but neither encrypts when sending to the other, nor any other client/server/etc, because there is no agreed-and-implemented spec last I looked (a few months ago).
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.
I used to do this but I found it downloads needed language files in the background. So every time it updated, I would clear all the app data, open it again on something innocuous, like a text file, toggle each language I used. Not knowing how long it would take, I'd wait until each seemed to be behaving, then disable network permission. I still don't trust that it doesn't send data off via Play Services.
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.
I do usually this, but recently on older phone (using it temporarily while I buy new) I had to reinstall it and found out, it didn't provide any word suggestions for ant language other than English and even gesture input for other languages didn't work, so at least during initial setup it must have (now?) internet connection most likely to download dictionaries (I thought they used to be included in past, never noticed this before), after allowing the connection, setting up and then disabling the connection, it works fine
Other people have noted that you can switch out the keyboard and SMS app (which I did).
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.
I used to dread the promised deep system integration of AI, but honestly after setting Claude up on a server box and having it do sysadmin stuff for me that I've been putting off for ages I see the vision. I don't really want to mess with the details of working through system orchestration tasks, I want to say "spin up this service" and start using it, "change my config so X happens" and it does, and knows what needs restarting to pick up changes and all the fiddly knobs and configs that need syncing and their bespoke formats. I think Nix tried to unify this for people, but it arrived too close to LLMs so a lot of value (in this dimension) has been delivered by other means.
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.
The vendors are never going to give you control over your computer no matter what vision they try to sell you on. The whole point, from their perspective, is to use their control of your computer to gain more control over you, which they hope to then exploit for profit.
Idk I feel like Ansible and RHEL aim to give you that control in a way that’s not typically corporate icky in the way you describe but ymmv. Granted both are products based on FOSS; so in the broader sense that pattern may hold
The thing is they don't setup their "intelligence system" for the type of task you wanna do. They are integrating it for tasks like "buy me a plane ticket for my next holidays", "order diner for me, the usual"...
I took the plunge into GrapheneOS a week ago. I picked up a new Pixel10 Pro and never even tried the stock OS (except to unlock the boot loader).
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.
The most hilarious is McDonald's app - it refuses to work without Play Integrity check. I wonder what braindamaged reasoning is behind this. Do they want to position themselves as a bank or something?
I recall a year or so ago, there's been a story about someone hacking McDonalds loyalty program, with that app doing something stupid like storing your balance on the client or something. It seems instead of firing whatever offshore sweatshop that made that, they just doubled down on "mitigations".
Huh, it works just fine in the UK. Wonder if they have different builds (or completely different apps) for different regions. Or maybe it's the GrapheneOS compatibility layer that makes it work? Not sure.
Play Integrity has several levels. GrapheneOS MEETS_BASIC_INTEGRITY, which I believe only requires a locked bootloader and no superuser.
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].
I saw on the GrapheneOS forums that some people had managed to get it working, but I was unable to do so.
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.
I don’t know about the company’s ethics*, but the app is fine and it’s genuinely useful. For one thing, it has a map with the most popular running routes around you. And if you want to be part of an exercise community in the US or Europe (at least UK), it’s the only game in town.
*Strava is one of the worst apps I’ve seen in terms of aggressively upselling you to a subscription. Genuinely infuriating.
There should be a way, but I have not yet found it, and I've spent some time on this. I've installed/uninstalled Strava about a dozen times, rebooted each time, tried various permissions, but stood my ground on some of the permissions. Should I give Strava access to my photos and my microphone? I'll never go that far.
Regarding the photos, the "storage scope" feature on Graphene should make that a non-issue. Microphone would be rough, but at least you would see a "microphone icon" show up on the top of the phone if an app was actually listening.
I run Strava on my Pixel 10 Pro Fold running GrapheneOS. IIRC you need to have Google Play Store installed (with zero permissions, preferably) to make Strava work.
You have to give it more permissions. You shouldn't blame GrapheneOS for an app not working when Grapheneos simply gives you more control than stock and you are taking advantage of it.
Of course many apps work fine with turning of more permissions that GrapheneOS allows.
I did this half a year ago and it was fine for me.
One of the benefits is of course privacy. For instance, I noticed that ads get completely out of touch which proved to me that I'm being tracked less.
Also never have that feeling anymore that my phone is spying on me.
Any iPhone user with a measure of privacy knowledge will experience the same.
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.
Apple still pushes ads to you. I can't recall how many times I saw ads in the App Store, and how many times they tried to push me into subscribing to whatever nonsense their executives' KPIs demanded (Apple Arcade+? News+? Music+?). No matter how many times I told Apple "No," they just kept pushing it. And now ads are coming to Apple Maps as well.
GrapheneOS has zero ads in the OS and main services.
What are North American people doing for replacing contactless payment? Last time I checked, the solution was to use Curve but it only works for Europe.
It's infuriating that they won't do this for non Google Android. It's in the best interest of both the bank and the card owner. Credential theft risk goes down to basically zero when backed by a fingerprint authenticated virtual card.
I'm sure contrats between Google and banks provide the financial guarantees that not open-source project would be able to. Unless governments mandate there's zero interest from banks to put extra effort into building for unpopular solutions
Stealing the numbers. Could've been someone taking a photo of the card out of sight. I honestly don't track my card that well when I'm out cause it's easy to have a transaction voided if it's legit not me. Then again cameras are everywhere now.
Banks don't want the headache of supporting multiple weird phone OSes and it's understandable. As long as they don't require running an apple/google-certified device and OS I don't care.
> Banks don't want the headache of supporting multiple weird phone OSes and it's understandable.
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.
Does skimming still happen a lot? At least in Europe we have switched from magnetic strip to chip-based cards, which are protected against replay attacks.
We have chips but magnetic strips are still on most credit cards and payments are still accepted that way in many older payments gateways. From what I read on the topic the cost of lost business if this was disabled is greater than eating the cost of skimmer attacks. There is a several year plan to phase it out entirely. It's mostly because initially when chips came out a lot of business owners were angry that they had to buy new payment machines and good luck explaining this to a none tech person.
The US first got magnetic strip readers in 1970 so we just have a ton of infrastructure using them. Since most people drive pickpocketing and things of that nature are much less of an issue for us. Typical use has someone using the card for everything then paying it off at the end of the month so if there's a random extra charge the credit card company will typically let it go to maintain the active user.
We're talking about just in time tokens that disappear after use. There's nothing you can do to defeat that on a rooted device. That's the whole point of the entire tech. That's why yubikeys are even a thing.
I have these cards I keep in my (RFID-blocking) wallet, one for each credit account. Then I just pull them out and tap to pay. It's super convenient - no app required!
People can't steal your card info via proximity to your wallet over NFC even without an RF blocking wallet. This is tinfoil hat security cargo culting, like putting tape over your webcam while leaving the laptop's microphone connected (audio from your room is much more useful than 2834823428 frames of your greasy face).
No but they can steal up to the pin-free amount of money your card allows. They can just hold a sumup to your pocket. Here in Europe most people use debit cards with non-reversible transactions and that limit is often 70-100€ which is quite a lot of money where I live. And they can steal a lot more if they follow you and shouldersurf your pincode.
I definitely use one of those wallets. They're quite convenient too.
The person mentioned it like it's a feature for them, but I haven't heard of it being anything other than a marketing gimmick, so I was curious for their perspective.
It's even available in my country! Never heard of it, would have assumed it's not being sold here. Let's see what that costs when I click the "shop now" button that's front and center
> 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
Use a solvent to dissolve the plastic from the card then epoxy the extracted antenna and chip innards to the back of your phone case. Problem solved. (I'm only 50% joking, you can actually do this but maybe epoxy isn't the best option.)
I can say the same. Been using LineageOS and GrapheneOS for most of my life. Some things are not super convenient (I generally dont install non-free-software applications and don't have Google Play services enabled), but the rest of the experience is great. No crashes, no bugs, no unexpected behavior. Currently I'm using the Pixel 9 Pro XL.
I can also recommend Gadgetbridge for BLE smartwatch integration.
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.
It's valid question for people unfamiliar with the project, but it is the AOSP in terms of looks, GrapheneOS does not customize the UI in any way beyond what their own features require as additions. Note that Pixel OS is not AOSP. The default home app of course also influences the experience quite the bit unless you replace it, which is what I'd personally recommend everyone to do as it's so incredibly barebones. Lawnchair is already a big step up as an open source alternative.
It looks very plain (black background, monochrome icons, very few apps included). You can customize all that if you want. I personally quite like the default appearance, but I am also the kind of person who uses the default GNOME or KDE theme on Linux and does not bother with custom themes or anything beyond daily Bing wallpapers.
The post doesn't say - what's new? Anything to look forward to besides the security patches for A17 being available for longer than they will be for A16?
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?
Ah, right I forgot they are discontinuing ChromeOS. Makes sense that current Android releases are focused on getting the Android laptop experience on par
Does GrapheneOS run on tablets? I don't see a whole chat app (shown in the example) fitting on my phone screen alongside something like a web browser, and the screenshot is from a square screen
GrapheneOS runs on an extremely limited set of hardware, mostly Google's own Pixel phones.
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:
It's complicated. The Tensor G2 Pixel tablet was a solid device, and you can still buy it new from Google (with no choice on color or size in my country), but production has been discontinued and the two direct generational successors were canceled, in sequence. First it was skipping a generation, then it was canceling it entirely. The rumored "Pro" version also appears to have been axed.
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.
> production has been discontinued and the two direct generational successors were canceled, in sequence. First it was skipping a generation, then it was canceling it entirely. The rumored "Pro" version also appears to have been axed.
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.
It runs on tablets and folding devices. There hasn't been a recent tablet meeting the requires but the Pixel 9 Pro Fold and Pixel 10 Pro Fold are supported. Both of those are phones folding out into a close to square tablet. There will be more standalone tablets supported again.
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?
1) any currently-supported device is good, but i'd say go for minimum pixel 8a if you can
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
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
Because why would you trust an operating system of which the companies CEO says that security hardening is only for criminals and spies?
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?
1) I'm typing this in a pixel 7 pro running grapheneos. I'd say these are plenty good enough. Device support is pretty solid compared to cyanogenmod of previous times. App installation is a bit slow using sandboxed play store. Not sure why that is.
For security reasons, GrapheneOS uses ahead-of-time compilation for apps. The stock OS compiles the heavily used parts of the code dynamically in-memory and then does partial ahead-of-time compilation later in the background. The install-time compilation will become more asynchronous in the future so the app can be used right away.
We Have been successfully using graphene on a pixel 4 plus, 5 plus and a 6pro.
They all work. Very well.
They were cheap to buy.
Super easy to install graphene (remember they have a very easy stepu by step process, takes about 10 minutes)
It's a good way to test and see if you like it.
Truly amazing operating system.
Simple and beautiful control of your apps and their behaviors.
If you want to try it out, you can easily buy an 8a for like 250 euros used. 128GB is certainly good enough, unless you plan on migrating your mp3 library to it or you take a lot of videos. My only qualms is the lack of SD card, for the aforementioned mp3s.
Any phone that is good enough with stock Android for your case is good enough with Graphene. If you really just want to try it out, it's the cheapest old Pixel *a you can find.
Checking which phones are supported by Lineage and Graphene can be done by everyone in a matter of minutes.
No, the Ai features come from Google apps and services that you can manually install. Grapheneos doesn't ship with any Google services.
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.
Jumped to GrapheneOS a few months ago. Works great. The keyboard was bad but you should install FUTO, as some other comments recommend.
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.
Why don't you connect with the makers of Madrid and see what they can do about it? That is sometimes the best way to fix these types of incompatibilities.
With Google making side loading extremely difficult soon, there's never been a better time to switch to a more secure OS for your phone.
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.
Its there. Before rethink I used DNS66 which is similar. Only available on F-Droid.
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.
I was using GrapheneOS for years, until the battery died while I was on an important call, trying to get someplace. Plugged it in, but little did I remember that I had installed OS update that was pending app optimization phase that happens during next boot.
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.
Oh, then the biggest pain point I've had is now resolved. I should give it another go.
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.
I'm not sure how Garmin works, but for instance with Google Wallet-compatible watches, you need a phone where wallet can run. I've had this setup for a year where I loaded the cards from another phone and used a watch to pay.
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.
You only need a phone to add the card to the watch. After that it works without a phone.
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.
> GrapheneOS recommendation to this was to have fewer apps
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.
Having many apps will not affect battery life on Android in any meaningful way. Actively using them will. Apps can't just sit there and run in background, unless you explicitly gave them that permission.
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.
Fairphones are far from meeting the security requirements to run GrapheneOS and have chosen an incompatible path. It won't be available for their devices.
/e/ is the direct opposite of a privacy or security focused OS. It doesn't provide bare minimum standard privacy and security patches while setting an inaccurate Android security patch level. It lags many months behind on patches even on devices where they're the least behind. It's typically years behind on kernel, driver, firmware and major OS updates. It doesn't keep the standard privacy and security protections intact and lagging behind on OS updates means not having the current ones. It sends user data to OpenAI and other third parties without consent.
/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:
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.
/e/ has drastically worse privacy and security from the Android Open Source Project or especially and iPhone. It's not a step up from standard AOSP. It lags many months behind on many High/Critical severity patches, years behind on overall patches and rolls back the privacy/security in a bunch of ways. It includes many invasive services.
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.
Insinuating that real privacy /security is for pedophiles and criminals is primarily what supports my conclusion.
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.
Fairphone doesn't design or make their smartphones. The devices are designed and made by a large ODM. It's entirely feasible to use a modern SoC with current generation security features and provide proper updates. Their ODM isn't doing it to cut costs.
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.
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
> ... 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?
Been toying with the idea for a long time, but I'm concerned about US financial institution apps and multiple countries specific apps (local transport, finance, medical and governmental), whose apks do no exist, as well as (crucial for me, as a heavy international traveler) google voice. For a lot such I now need to use a combo of Google playstore, for US account tied apps, and Aurora for non US apps.
You will find that a lot of banks and other companies have old fashioned websites that open work better (and more privately) than apps. Even Google Voice should be usable through its website. However what is usually recommended by the Graphene community is to call or text via Signal instead.
>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.
I've been thinking it might be worthwhile to showcase that you can make GrapheneOS look beautiful or the same as stock Pixel UI. When I was considering switching from iPhone I had this misconception that it would look ugly or wouldn't look the same as Pixel UI, which is not the case at all. When I asked about it I wasn't given this clearcut answer that you can make GrapheneOS UI look the same or better than Pixel UI.
Wow that looks nice. I don't think you can get that.
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.
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.
Thanks! I've been contemplating trying out Graphene, but I really enjoy the user experience of iOS. But I feel like I should at least get acquainted with Graphene as the inevitable enshittification of iOS will occur.
It means they rebased all their changes on top of the new version. This is usually time-consuming because AOSP is not developed in the open, so you can't do this incrementally as things change -- you just get a massive drop sometime after release.
Android makes yearly releases. It is developed in cathedral-style. Google releases the source as a single big update. GrapheneOS is a fork. They need to port their customizations and extra software on top of the new release.
Every six months, not yearly. Google releases the major version and QPR2 as part of AOSP. QPR1 and QPR3 are Pixel-only.
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.
It's a fork of the Android Open Source Project (AOSP) with major privacy/security improvements and alternatives to Google apps/services. The massive set of changes needs to be ported to new major versions of AOSP.
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.
Only Google Pixel’s and Fairphone’s currently provide bare minimum for 3rd-party OS support: working verified boot with user-provided signing keys. None of the other phones doing that yet
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
There are a lot of devices with the ability to install another OS and lock the device with verified boot, but none with the required updates and security features other than Pixels. Fairphones are near the bottom for security among the available options.
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.
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?
It isn't only developed for Pixels. Pixels are currently the only devices permitting an alternate OS with the required updates and security features. GrapheneOS has a partnership with Motorola Mobility and there will be official GrapheneOS support for a subset of next generation Motorola devices.
GrapheneOS would be so much more interesting if there was an official supported way for rooting it. That's the only reason I haven't switched to it on my several devices (all rooted)
That completely goes against what they're working towards. I understand why you would want to root your own phone, but GOS is targeting highest security standards and root ain't one of them (for good reason).
But in that case why you would need to use GrapheneOS at all? Without security you cant have privacy and OS with security as priority cant just add hole in the system because it would allow to bypass all security features added on top of AOSP and AOSP features too. Most features people use root for can be achieved without root by modifying Android Framework itself with SystemUI/Settings app
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
If you value freedom to do what you want on your devices, then you may want to consider Librem 5 instead. It runs a desktop Debian derivative with full root access.
You have the ability to do what you want on your device. Root access in AOSP is just used as a hacky shortcut to achieving specific functionality. To do it properly while maintaining the security model would be to build it into the OS itself. The same concept applies to desktop platforms and the Librem 5. This isn't related to freedom.
That device, and the Debian derivative it runs, are not private or secure.
What do you mean when you say "not private"? Are you accusing the company of sending private data to their servers, as Google and Apple do?
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.
Maintaining one's data as private requires that it is protected as a baseline. Privacy violations do not solely exist as telemetry or data offered up by the platform to some other party.
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.
> Maintaining one's data as private requires that it is protected as a baseline.
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.
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)
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.
I've been running GrapheneOS for over an year now. Bought a Pixel 6a last year as a cheap way to test waters, but pretty soon I upgraded to discounted Pixel 9. It took a while to set the basics (coming from iPhone), and I'm still have a couple of stuff missing, but at this point don't intend to use anything else (for as long as possible).
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)
I started rebuilding my phone from factory tonight, and I opted for the private profile partition inside of the main profile for my play store apps. It's accomplishing everything I wanted a fully separate profile to do without the hard switch.
I made the same mistake after being burned by the PinePhone, buying a heavily discounted Pixel 6 to test various Android forks, which eventually included GrapheneOS. I quickly knew I'd found home upgraded to a 9 Pro XL.
Greatly improved privacy and security and end-user control of your phone and its data. In those areas, possibly the best option, though iPhones might be better in security (not necessarily the other two areas) - Apple has a slightly bigger budget and a few more engineers, and directly controls the hardware.
GrapheneOS exists to greatly improve the privacy and security of an existing open source OS project. Android Open Source Project has good privacy and security as a starting point.
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.
The ability to sandbox Google Play Services (if you need it, but realistically, you probably do) and to simply not assign it more permissions than it absolutely needs is awesome. I run it with very restricted permissions, where it by default requests every single permission it can. In stock Android, it has all those, and you can't limit it. Just that is worth it for me.
See https://privsec.dev/posts/android/banking-applications-compa... for banking apps. Anything that's not a banking or government app is extremely likely to work. Very few other apps ban using a non-Google-certified OS and that's the only significant reason for incompatibilities. GrapheneOS has a per-app exploit protection compatibility mode to work around memory corruption bugs caught by the features. It's in the process of overhauling the secure spawning feature to avoid tripping rare anti-tampering measures in certain banking apps. Play Integrity is increasingly the only compatibility issue. Some apps using Play Integrity have explicitly permitted GrapheneOS though.
In terms of apps, I fully believe it will only get worse from here: Google’s trajectory has been pretty hostile, and third‑party developers tend to follow it.
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.
I had the same idea in mind, would you mind sharing how you do it?
I also use 2 phones, GrapheneOS as my daily, another phone at home just with banking stuff and some other crappy apps.
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?
I refuse to ever use a banking app on my phone, so I don't even know if my bank's app would work. But every other app I've tried to use works just fine on GraphineOS.
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?
A pity that GrapheneOS works only on Pixel and those phones are trash for me (no microsd support). I have a 1.5 tb microsd card with all media/books and it is easy to move to another phone by just swapping the microsd card so this is one of the most important features for me.
permanent reminder that graphene and all other "alternatives to android" depend on extracted binary blobs. tons of them. which is the reason new (kernel) versions are such a chore/achievement.
The kernel drivers are fully open source and moving to new kernel branches is a standard part of the update process. Pixels are currently moving from 6.1 and 6.6 to 6.12 with Android 17 QPR2. This is part of the hardware requirements for GrapheneOS listed here:
No, but all of the kernel drivers are open source and always were. The closed source userspace libraries such as the Mali GPU library aren't a barrier to porting to a new kernel version which is what was said above. We could move to 6.12 ourselves but we choose to wait for them for much broader testing which is happening with Android 17 QPR2.
The kernel drivers are all published in the GrapheneOS kernel repositories. A subset of the libraries/services in the vendor partition used with those drivers are closed source.
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.
sigh. always this reply. go look at all the binary blobs in the source tree. you won't get modem, video out, touch, etc etc etc working without extracting eom drivers as binary.
also, there's ZERO mentions of drivers or binary blobs on that link!
I had been using LineageOS + microG for many years on my Pixel 3. I upgraded to a Pixel 8 and tried out GrapheneOS and the install experience was good, but I found some odd performance quirks - apps would be slow to install and run, downloads were slow, etc. Has anyone had similar issues?
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.
>but I found some odd performance quirks - apps would be slow to install and run, downloads were slow, etc. Has anyone had similar issues?
not sure about downloads specifically, but app installs are slow because grapheneos forces AOT compilation (JIT is disabled), presumably for security reasons.
A lot of developers are lured into building in a dependency on Google services, so yes you'll need microG or, as GrapheneOS prefers, the original Google code running on your device for those apps to function. Or patch the app, like Langis does for Signal (not necessary for it to function without Google in this case, but it removes its calling out to Google's apps and services for those who don't want that). If you're happy with that setup and don't need protect-from-the-government levels of security (street thugs aren't going to ransomware your device by abusing an unlocked bootloader or send exploit chains that work on anything but the hardened allocator), LineageOS is probably the better choice for you. GrapheneOS has some nice things like easily denying the network permission for an app (even if they could theoretically work around it with intents) and having a custom A-GNSS server, but you can do the same on LineageOS by using root and something like AFWall+ for the network and configuring Graphene's A-GNSS (SUPL) proxy in the system settings (don't forget to donate if you use it and are able)
GrapheneOS is designed for everyone, including average users. It does not require a high threat model, and the features it provides are not only useful to people with high threat models.
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.
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
You cant respond to any opinion because I have not provided any. Security is objective. What security someone may need can vary, yes, but that does not change how the security of a device works. You are downplaying serious issues and claiming features that nearly everyone benefits from are unnecessary.
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.
Since grapheneOS only supports latest Google pixel phones, I tried installing LineageOS on my Mi11. Sadly, if you own a Xiaomi, you can’t just install another os. You need to unlock the bootloader and Xiomi limits you with a global quota of daily unlocked phones, you basically need to enter at midnight and hope. This is a complete nonsense, we have zero governance on our devices after paying them so much.
GrapheneOS posts factual information debunking inaccurate claims from groups attacking it. Some of those groups react to their misleading claims being addressed with personal attacks. Threads about GrapheneOS on Hacker News usually have multiple posts with personal attacks towards our team from people influenced by those groups.
GrapheneOS is a privacy project highly focused on usability and compatibility. Privacy depends on security so it has to put a lot of work into security too and it has always been a major focus, but it's a misconception that it's all about security.
> This means they strongly advice against using other software many in their core audience are predisposed to like: Firefox, Signal, plugins for browsers, F-Droid, ect.
GrapheneOS doesn't recommend against Signal but rather it's the main recommendation for end-to-end encrypted chat from the project including via the Molly fork of Signal.
> The explanations are usually quite... blunt, and they're not exactly open for discussion (which makes sense, from a pure security perspective, those apps are indefensible).
This isn't true. GrapheneOS provides nuanced information with detailed explanations for these topics.
To get a sense of the project and its goals I recommend reading this post[1].
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].
> Buying a used Pixel is economical, environmental, and likely doesn't support Google
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.
> What do you think are reasons for google to run Pixel then?
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.
I don't see how it's relevant. I couldn't possibly have made it any more clear I would not buy a Google device, new or used, because I don't like Google.
Because AOSP is open source and can be built without Google Play running at the background unlike the other alternative: giving up privacy to yet another big tech Apple.
Graphene adds many privacy features on top of regular AOSP. But it only works on phones that has good security features that are not woefully outdated or completely closed-off. Google has complete control over Pixel supply chain and they can make their phones with all bells and whistles for their ends and they behave a bit benevolently and expose the interfaces to the user too.
Most Android phones use Qualcomm which doesn't give a flying fuck about giving control or privacy to the users.
Opensource or not if someone says they hate so much google they do not want to touch a google device with a 10ft pole even if they didn't gave money or personal data to google to access it, I don't see how that person can accept running code from them.
Because average people are not just zealot crazies. Compromises and spectrums exist.
AOSP is still the best Linux-based environment for consumer use case from many aspects. It handles hardware better than GNU-based desktops, it is more secure, it supports things like HiDPI screens better and it has a stable API to write applications against and many people and organizations did so (you can still use Android 4 apps).
AOSP has strong Google influence but it is possible to use it without feeding data to Google.
That's a value judgement, and it's a fair one. It does throw an additional constraint in the works though.
FWIW, I've been looking at the mobile / portable computing space fairly intensively for a month or so. I share your quite dim view of Google.
GrapheneOS does seem to be one of the most attractive Android alternatives.
There are also Lineage (based on CyanogenMod), AOSP, KaiOS (based on AOSP, via Firefox OS), LightOS (by Lightphone, AOSP), AphyOS (used by Punkt. mp03, also based on AOSP). These tend to be minimal, used on feature phones / dumbphones / minimalist phones. And there are /e/OS and iodéOS.
Among Linux-based non-Android options are Sailfish OS (Jolla), Ubuntu Touch (Ubuntu), PineOS (Pinephone), and PureOS (Purism), Tizen, Mobian (based on Debian), postMarketOS (based on Alpine Linux). These tend to be maximalist, offering a fuller experience than Android, with support for native Linux applications and configurations.
There are some non-Linux OSes, of which I'm aware of System 30+ (a/k/a S30+, Nokia), OpenHarmony (by Huawei), and ... something described as "realtime OS" or "RTOS" which actually had a name, for a Japanese flip phone, but which has slipped my mind (probably something reviewed by Jose Briones on his YouTube channel).
And of course there's iOS.
Briones by the way is an absolutely excellent resource: <https://josebriones.org/>. He's also one of the mods of /r/dumbphones at Reddit.
There are trade-offs, and what you choose depends on what you value, in the marketplace, in capabilities, in your own peace of mind.
If you want a full-featured device with wide acceptance, few limitations, and want nothing to do with Google, look at iOS devices.
If you want (nearly) full Android capabilities, but without Google's prying eyes and ears, GrapheneOS or LineageOS are probably your best bets. Whilst Graphene currently only works on Google Pixel devices, there's been a partnership announced with Motorola, there may be others in future (my speculation, with no other basis). And ironic as it seems, Graphene + Pixel actually does get you further from Google in many ways, though I still understand your position.
If you want full freedom / maximal privacy, and are prepared to make compromises on capabilities and battery life, look at one of the Linux-based, non-Android options. I've heard of quite a few bugs with these.
If you're looking for specific hardware capabilities (e-ink, folding / candybar, keyboard (T-9, qwerty, ...), small, large, tablet, headphone jack, etc., etc., or specific software capabilities, you're going to further refine your search. (Briones has a Dumbphone Finder at his website which does this pretty well.)
If you want modularity or repairability, there are devices such as Fairphone or Keyphone with (some) replaceable components.
If you want minimalism, look at an AOSP-based device, or perhaps S30+. These will give you feature phones capable of calls, texts, and a few apps, but not much else. For more complete computing you'll need either a desktop or a laptop.
There are more extreme options. I'm considering, for example, whether or not a roving SIP WiFi-only phone might be an option, and if so, what would be necessary to make that work. It would rely on a WiFi network provider (public or non-public network, or a cellular modem), and wouldn't function everywhere but should function in many locations sufficiently to be useful.
Most non-smartphone options I've looked at, and in particular the usual "dumbphone" suspects (Light Phone, Punkt.) tend to run an AOSP-based OS, with Nokia being the principle exception.
Briones FWIW uses the Light Phone III as his daily driver. That's somewhat spendy, and quite minimal, but he has his reasons, discussed at length at his blog and YT channel.
I'm leaning fairly strongly toward an option now, though my main hesitation is that KaiOS devices have very limited phone/SMS spam and/or traffic management. I'd prefer known-contacts-only could reach the device, that doesn't seem to be possible (KaiOS has only specific-caller blocking, and apparently a limited API for enabling more robust phone blocking). On the flipside, the device can be powered off, and/or battery removed.... I'm also looking at some VOIP/SIP options.
This probably falls under "capabilities", but another consideration worth strong consideration is mobile network support. With the past phase-outs of 2G/GSM, ongoing 3G phase out, converstion to LTE and VoLTE, and expansion of 5G networks, as well as differing network and frequency standards around the world, finding a device which will work with your preferred mobile provider(s) is a challenge.
This is one of my strikes against the Punkt mp02: it doesn't work with most of my carrier options. I was hoping that either that device's capabilities would be extended, or its replacement would follow a similar ethic and expand bandwidth / protocols, but neither occurred. Further reading on Punkt's offerings has further cooled my interest (bugs, fragile HW, spendy).
RCS and group chat support seems to be another sticker, though with a small-form-factor laptop or tablet you should be able to work around that.
The other sticker for me (mentioned in my original post) is voice/SMS/messaging filtering options. The increase in spam / unsolicited contacts across the comms spectrum is immensely frustrating, and few devices / OSs / apps really address the situation adequately and in a privacy-respecting manner. That's still giving me a lot of hesitency on what really ought not to be this complex a decision, though for now I'm thinking it's a good thing to spend the time.
If you want full freedom / maximal privacy, and are prepared to make compromises on capabilities and battery life, look at one of the Linux-based, non-Android options. I've heard of quite a few bugs with these.
Most of them also have really bad security, for various reasons, including:
- Since virtually no hardware vendor (outside Jolla) supports non-Android phones, they typically use phones that were made by their ODMs as Android phones and rely on kernel/firmware/device trees made available for those Android builds. Sadly, nobody outside Google (PixelOS) and Samsung really cares about giving their kernels and firmware timely updates. So usually the kernel and firmware are full of known holes (Qualcomm and others do monthly bulletins).
- For many reasons, Linux systems have never really focused on proper security isolation and sandboxing. So most of these phones have really poor isolation and you are only one browser/image parsing/... vulnerability away from full phone compromise.
- Unlocked bootloaders or otherwise compromised boot chain. So, it's easy for persistent malware to compromise a phone and there is no way to attest that the system runs unmodified binaries (as you can e.g. can with GrapheneOS' auditor or Android phones with fully verified boot and Strongbox).
Let's say, if I was a bank, I can understand why I would want to block such devices.
Obviously I want banks to support alternatives, but I can understand if they only want to support secure OSes. Some banks support GrapheneOS remote attestation besides Google Play Integrity at the strong level.
By your reasoning, 99.9% of people use awfully insecure OSes on desktop and servers. And yet, the world hasn't collapsed. My bank account is not hacked regularly, too (actually, not at all).
This is a personal anecdote and you are making up an absurd conclusion. No one said things would collapse. Security can be evaluated objectively, and the better the security, leads to fewer instances of exploitation. I'm certain the actual data around InfoSec would support that idea.
It makes sense that an open source project would focus on one series of phones since their time and resources are limited.
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 Pixel 9 had a vastly improved modem and the 10 switched to TSMC for their Tensor SoC, resulting in better performance and better battery life/less heat.
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?
> The Pixel 8 Pro has hardware WiFi problems, the 9 and 10 are both minor updates
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)
Only silver lining to this is they run a lot of discounts and promotions on them, and it's possible to buy them at a significant discount. Got my first Pixel 10 on a very cheap contract with trade-in promos on top, and got a second Pixel 10 at a 70% discount from the RRP.
It's not possible to buy them at all where I live, even if I wanted to funnel money to Google - which I do not. I have gone to great lengths to de-Google my life.
Absolutely, and it is irrational to refuse to buy hardware from Google (which, with Graphene, is under your control) when the alternative is to either run a Google OS on a third party phone (and give up control of the software), or Apple (equally bad), or some impractical and less secure alternative like a Linux phone incompatible with Android apps.
Agreed. I dislike most of Google's products, but their Pixels have secure hardware and are very open (compared to other modern smartphones). In short - a good product for people wanting to run free software on modern-ish smartphones. If a product is good, why not buy it?
I have tried ubuntu on mobile only once and never come back, because it had very bad and poor experience compared to native experience of that mobile. On which models this system works the best?
GrapheneOS is highly usable and compatible with nearly all Android apps. It has a similar experience to a mainstream Android OS if you choose to set it up that way such as using sandboxed Google Play in the main profile (which does not ruin what it provides at all, it's a perfectly valid setup). The purpose of GrapheneOS is to provide far better privacy and security than the Android Open Source Project (AOSP). AOSP is a lot more private and secure than a traditional desktop OS including one ported to mobile.
I've been running GrapheneOS for 7 months now and I'm not going back. When I bought my Pixel 10 last year, I wasn't actually planning on trying Graphene for a while....until I noticed Google had force bundled a 'Wicked For Good' movie promo theme with the latest security update.
Ha! Me too! Exact same. Bought a Pixel 10. Intended to do the default Android for a while. But it was filled with ads for “Wicked” which had me looking at my phone with a sneer on my face I couldn't erase - as if someone had smeared feces all over it and threw it on my bed.
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.
Does it affect the photo quality? It used to require letting go of the default photo app and thus a downgrade in photo processing.
No, if you install the Google camera there is no difference in quality and by revoking network you don't lose privacy.
> by revoking network you don't lose privacy
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...
https://github.com/GrapheneOS/os-issue-tracker/issues/2197
I don't have any Google or closed source apps with network permission, but thank you for sharing that quote I haven't seen that before.
Eye opener. Thanks for the warning! GrapheneOS sandboxes all apps including GSF as far as I understand. It would be nice if full capabilities could be exposed or at least shown in the app settings. There is the "All permissions" view which has a "have full network access" item with the following details: `Allows the app to create network sockets and use custom network protocols. The browser and other applications provide means to send data to the internet, so this permission is not required to send data to the internet.` Does this mean the app has this permission and even without it can fully access the internet? If so the primary "network" permission is very misleading. I wish for a smartphone-like device which installs apps with `cap_drop: ALL` by default. I wish for a government which would support such a standpoint and "assist" companies not able to provide a service which require intrusive data gathering. Either that or we're all just one big happy family with no secrets and no jealousy and no drama. sigh
Every Android app can do IPC with Android apps in the same profile. So an app without Network Access could cooperate with an app with Network Access to communicate with the outside world. Of course, most notably, a lot of apps communicate with Play Services and people generally leave on network access for Play Services to avoid breaking to much stuff.
There has been talk of developing 'IPC scopes', similar to how there are contact scopes.
IPC scopes would be a great solution!
To my knowledge, any app can just instruct the installed browser (Google Chrome, Vanadium, Firefox...) to open http[s]://tracker.evil-ad-network.example/?installedId=012345.
"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."
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."
Install a 3rd party GCam and then the answer is no https://www.celsoazevedo.com/files/android/google-camera/
That sounds like the answer is actually yes: we're not talking about the lack of a camera app, but the lack of a camera app that knows the details of the usually-proprietary camera firmware
You can install both the regular GCam as well as third party mods. Actual GCam feels worse to me.
Problem with stock Google camera app is that it made horrible HDRlike images even with HDR turned off. You cannot adjust amount of reduced highlights and increased shadows which makes images unrealistic with lack of depth.
I mean...... Google Camera has slightly different approach to low light photos and much better panorama mode, which means you can just install it and use with network access denied.
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.
That really pissed me off when I found the only app that can access the full output of the sensor on Samsung is their own shitty app. WTF.
We took control, we're keeping control
[flagged]
What you are describing is not Google’s alturism but keeping competition in check. If Google didn’t “allow” GrapheneOS it opens up a new market segment for other smartphone manufacturers. Apple really cashed in on privacy for a few years so it’s not unfathomable that Xiaomi or someone else goes all in on “privacy focused android” in absence of pixel+graphene combo.
Edit: Apparently Motorola is doing just that.
I don't think any Chinese company can pull the privacy card. They're bound by their government to spy on their customers just like American ones are.
Otherwise Huawei would have already jumped into that gap. They have their own Google-independent OS now so they could have marketed it to privacy enthusiasts where the lack of Google services would have been a positive not a negative.
> Xiaomi or someone else goes all in on “privacy focused android” in absence of pixel+graphene combo
Xiaomi? Privacy?
> Apple really cashed in on privacy for a few years
Apple didn't "cash in", their marketing dept made sure privacy/security engineering got just enough budget to pull off miracles & then spend even more to successfully make the public forget about the very nasty Celebgate.
> Celebgate
That was a phishing campaign, not a breach.
My point isn't about engineering.
TBF if Google locked down the devices like that it would be a GPL violation. Not their first or whatever but still, there's a reason for them not to do that beside "being nice"
Would it? IANAL, but AIUI the only GPL component is Linux on GPLv2 which requires providing code but not giving the ability to install it
Yes. GPLv2 specifically contains a clause that you must provide "scripts to control compilation and installation"
Source you can't compile or install onto the device wouldn't be very useful.
Not really. Tivo did that eons ago. Whether you view this as a "flaw" or "feature" of GPLv2 it's ultimately why GPLv3 now exists.
The Linux kernel developers see what Tivo did as a "feature" rather than a "flaw" and refuse GPLv3.
It's also because so many Linux developers are on the payroll of big tech. Look at all the submissions. 95% are just big tech. And look at the key people in the Linux Foundation. All a bunch of business suits with compromised motives. Serving their company above the community. There's only a few unencumbered people in there now.
Linux is no longer the community-driven choice. It's big business with billions hanging on the line. The grassroots origins are long over.
TiVo never prevented installing your own build in the device. They only prevented running their proprietary app on top of it when you had done so.
And how many options are there exactly? How many of them are capable of at least making and receiving a phone call without any issues 99% of the time?
While I agree with your general sentiment, I feel necessary to acknowledge that it's just not there (yet?). GrapheneOS is a great option if you want to have a fully working and secure device.
Years ago I looked into GrapheneOS, and I ultimately didn't go with it because, at least at the time, they only supported pixel phones (specifically pixel phones that Google actively had security updates for). I realized that if I got that OS, I would be at the mercy of Google supporting the device in order to continue using GrapheneOS.
In the end I just opted out of the android ecosystem altogether and went with a flip phone that I used as a hotspot for an iPod touch (we only used over VPN with locked down DNS and nothing google related).
My privacy lasted about two weeks, because unfortunately Spotify was able to fingerprint that device to Facebook.
I would highly recommend LineageOS. Supports non-Pixel phones, some of them many years old (although now that I double check, the Galaxy S3 and OnePlus One aren't on the devices list anymore, I guess they do stop supporting old stuff eventually...). The OnePlus 5 is still supported and was released in 2017. For anything older than that, I guess I'd recommend looking into postmarketOS.
> at least at the time, they only supported pixel phones
At the time? They still are the only devices officially supported.
Having your freedom be tied to a handful of devices from Google, is a massive supply chain risk.
You're not wrong, but we gotta do what we can and take every advantage we can get.
There is no FOSS modem. The baseband is a separate computer operating on a lower level than the OS.
Your provider can run arbitrary code there.
I thought the PinePhone community had succeeded in making custom firmware for the modem in the PinePhone, though I'm not sure of the legality of actually using it. Plus both PinePhone and Librem 5 had a killswitch to disconnect the modem at least.
Your point is valid and yeah, it's a never-ending fight just to keep the control we have. Things like the Play Protect API and loads of Android apps being coupled to Play Services is it's own big challenge we're stuck with just to stay within the Android ecosystem
Let them eat steak!
What about banking Apps? No problem there?
Some of them have ridiculous secur... compliance rules.
There is a list of compatible banking apps: https://privsec.dev/posts/android/banking-applications-compa...
Big list, unfortunately one of my banks is not there (BCGE, Switzerland), most probably meaning I can't even login into ebanking in any other way since they have their properietary authentication app (CrontoSign, also not listed). Its rather small regional/cantonal bank so I get it, even though that region is Geneva, mecca of (some types of) banking.
Other banks that I use are there. Almost perfect...
Being missing means they haven’t been tested, not that they don’t work. Generally they probably only don’t work if they require the google play verification thingy
My banking apps were missing in list too, it doesn't mean that they are not working. You can test and report on that issue tracker about your banking app if it works :)
> What about banking Apps? No problem there?
Most banking apps work, but Google Pay/NFC payments won't work.
If your bank doesn't have its own payment app, but PayPal Card is available in your country, I got this setup to work on Graphene by installing PayPal into the Secure Folder, install the sandboxed Play Services there (required) and setup the mobile payments in the app. It's not a great solution, but for I keep it around for emergencies.
I know a handful of german banks that have their own nfc payment apps that still work in Graphene
Google Pay may not work, but NFC payments through yiur bankapp probably do. They did for me.
The vast majority work, check this list for details: https://privsec.dev/posts/android/banking-applications-compa...
You trust a phone with your banking?
I had to enable "exploit protection compatibility mode" to use my credit union's app.
In my experience: Everything™ works, except Google pay unfortunately.
My banks app complains will block me and tell me to disable developer mode, but if I turn it right back on after launching the app it won't complain for maybe another week. The post that really annoys me, though, is that if you don't set up biometric unlock they will not allow you to use the extended login cookie, so you need to put in your password every time, most don't work with password managers either (whether intentionally or not).
iOS is also going into this direction, just open the AppStore, it’s all the cheapest most horrible apps. Temu (shop like you don't give a s* about the planet), addictive AI Waifu’s (who needs human interaction anyway), clean your stuff but fake-time-wasting style (it's free dopamine!), search option’s first hit is often scammy (ie search for MS Authenticator). I feel that Steve ("If you want pr0n get an Android") would turn around in his grave from the sight of this.
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.
You should read https://discuss.grapheneos.org/d/24134-devices-lacking-stand... about /e/ and also look at what they say about devices with strong privacy and security including but not limited to https://grapheneos.social/deck/@GrapheneOS/11635397373214317....
I'm aware of this discussion, I don't really like the way the Graphene people communicate, also against FairPhone.
But nevertheless I'm looking forward to their Motorola offer that should come any minute now?
Grapheneos communicates with facts, not opinions. It can come off as abrasive but it's never unfounded attacks or opinions.
The AppStore has been like that for eons, but then again I don’t know a single person that uses it or checks the “content” posted there. It’s an utter waste of time.
I don’t think it will leak. After the U2 debacle, Apple might have learned not to push too hard on this front.
> it was filled with ads
You bought a phone from an advertising company?
All factory operating systems come with ads and bloat and spyware, Apple/Samsung included. Google remains the lesser of all other evils because at least to date, they offer an open source OS, bootloader unlocking, and root. A community driven mobile OS is absolutely where we should go, but for now and the foreseeable future you can call a Lyft, deposit a check (in America), and do other mainstream tasks on AOSP flavors without Google/Apple/Samsung having to know anything about it. It's never been easier to make the user friendly choice too: https://grapheneos.org/install/web
It's not like buying from Samsung is any better.
for some reason i read that in archer(animated) voice.
Probably because it's a dumb useless comment in the same vein as most of that show.
I read this in a whiny high pitched voice with my nose and lower lip pulled up.
Don't recall my old nexus devices having ads in the OS. Disappointing where Google has taken this.
Technically they already did a built in ad with Android KitKat. Mostly benign, but I do remember being at an Android event and KitKats samples being given out to everyone. As well as KitKat wrappers being branded with the Android logo for a while.
"Do you not?"
[dead]
When I got a new phone last year, I purposely got a Pixel (open box 9a) to put GrapheneOS on it immediately. Been happy living the de-Googled Android life since.
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.
If it's any consolation, the wipe* requirement before unlocking the bootloader is generally a good thing, even if it's inconvenient. Someone who is targeting your personal data gets access to your encrypted phone, either by stealing it or in an evil maid situation. They unlock the bootloader and install privileged code that helps them recover the symmetric encryption key or intercept your PIN. Then they either have your data or wait for you to enter the PIN. In theory recovery shouldn't be possible (access to the key depends on a secure element that rate limits brute-force attacks), but security bugs do happen. Wiping* your data before removing the bootloader's signing requirement is an extra layer of protection.
*It doesn't actually wipe your data; it just destroys the symmetric key, making the data permanently unreadable.
AFAIK you can't unlock bootloader without wiping the data, that's my experience from last 15 years unlocking bootloaders on various phones
so it's kinda pointless to wipe data prior wiping them again during the bootloader unlocking process
We're saying the same thing. The bootloader unlocking process includes a step that destroys the FDE key.
While the OOBE of the stock image doesn't force an Internet connection, the ability to unlock the bootloader does - whether you can do it or not depends on the phone manufacturer's desire, and Android for some reason uses an Internet connection to check that.
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.
Yep, on older phones it was certainly possible without an Internet connection.
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.
If it is any consolation it became intrusive on pretty much every single brand nowadays, if they at least offer bootloader unlocking option.
I misspoke when I said Android 7+, my apologies; I was thinking of my Pixel 7, which runs Android 13.
it should be possible on Sony and OnePlus phones and maybe other brands, though it can require obtaining code from internet on other device, but the device being unlocked itself doesn't need to have internet connection
I think LG had a system for getting unlock codes as well, but they closed it a long time ago.
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.
...I feel a bit silly. When I said "Android 7+", I was thinking of my Pixel 7, which runs Android 13, so "Android 13+" is what I actually meant to say. Oops.
Is it possible to install basic Google apps like Gmail, Calendar, Maps, Drive without googlifying the whole phone?
I'm not looking to fully de-Google but I want Google as apps and not my OS.
I run a litany of Google (and other corporate/business apps) apps in Private Space under the owner's profile, which is only unlocked when I need it for something. That space's connection can go out over a WireGuard tunnel if I need those apps to be on any specific networks, while the rest of the phone's traffic is unaffected. The file systems stay functionally separate (although that's not a major concern given how file encryption is handled, plus the dream that is Storage Scopes), and that space has its own camera app and such.
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.
Yes, you install the Google Play store via the GrapheneOS App Store. The OS comes with like 5 apps out of the box. The rest is up to you.
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.
Android Auto is fully supported and shouldn't be any more flaky than it is on the stock OS. It's often flaky due to a bad USB connection or problematic implementation in the car. That's just how it is everywhere.
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.
> MDM managed work profiles
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?
Yes, I mean MDM work profiles. I play an IT guy at work and am a Google Workspace admin. We have it running in BYOD mode and it's actually not intrusive at all. The most sensitive data you can see as an admin is what apps are installed in the work profile, the phone's make + model, and the version of Android. Nothing like location, charge level, or anything outside of the work profile. I'm fine with running it on my personal device (I actually really like the way it functions), but it's borked on current versions of GOS.
How to say "I work for a company too cheapass to provide work devices".
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.
Some people don’t want to carry two devices and prefer BYOD, even if the company offers a work phone.
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.
My end-run around Google's absurd unwillingness to certify GOS for Google Pay has been Garmin Pay, which has worked virtually everywhere I've ever tried it.
I'm hopeful that an OEM Motorola device will get certified for Google Pay.
Depends as bit on the country and bank. I also use Garmin Pay, but my bank only supports adding their credit card (not debit card) and a substantial portion of shops here only supports contactless payment through debit cards (credit cards have historically not been popular here).
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.
Tap to pay is mostly NFC? So is there an alternative app?
I extracted a chip (by dissolving the plastic in acetone) from my card and glued it to the wriststrap of my Pebble watch :)
When using contactless payment with my card, about 10% of the time the payment terminal tells me to insert the card to the reader slot instead and enter my PIN. I assumed this is a general security feature, but I guess it depends on the issuing bank then. This in Europe.
Well, I still have a backup physical card. It just is annoying to get it out of my wallet.
[dead]
Nice hack but sounds quite unsafe, I like having to unblock de phone in order to use it.
Garmin Pay, Samsung pay if you have a compatible bank and card, PayPal in Germany and sometimes banks' own systems.
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.
Curve Pay has worked well for me. Only good alternative as it doesn't depend on Google Play Services too
Yes you can use Curve pay.
Edit: Apparently that's Europe only? I'm in Europe so yeah. I didn't know that.
Paypay works as well (at least in Germany)
There's Curve Pay in Europe. In the US, I'm not sure.
I believe one of Graphene OS's main features is that they allow you to run google play services in a sandboxed environment, so you can run your standard google apps but without the standard android deal where google play services has unfetteted access to all your phone's location/data/etc info
Yes, those are all compatible and the only way to use them is as regular sandboxed apps without any special access. Sandboxed Google Play can be installed in the profiles of your choice. Installing it in the main Owner user is a valid choice and doesn't at all ruin what GrapheneOS provides but you can make a dedicated work profile or Private Space for it to keep it separate. Only apps in the same profile can see it and use it, so you can control which apps will use their functionality depending on it that way.
> I'm not looking to fully de-Google but I want Google as apps and not my OS.
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.
> In that case, OS access becomes moot.
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.
> 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.
I agree and have moved mostly away from everything Google. But it's hard to replace maps. I know open street maps exists but it's hard to beat Google's data gathering.
I think OSM is way way better. It has every little path in the hills I walk. On Google Maps I'm just walking in a featureless green blob. OSM even has unofficial trails that are no more than a worn-down line in the brush.
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.
Don't forget to update the business hours in OSM when you see they are missing / wrong
Yes but I mean special holiday opening hours etc. Most places do keep these up to date in google.
Or Google will call them and ask which automatically updates the data.
I use Google Maps on Graphene. It works perfectly. You still get the benefits of the rest of the phone being degoogled. Just allow it to access your location only when you're actively using the app. When it's closed, it's closed.
There are players in the OpenStreetMap ecosystem attempting to change that. I know the team behind Organic Maps are actively working to make their app as viable as possible by sourcing appropriate data for example.
Organic Maps is amazing.
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.
Organic Maps has been forked to CoMaps as a community managed project btw
TIL there has been some drama about Organic Maps, what is the difference between OM and CoMaps?
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
Please don't declare software "completely useless" just because it lacks a feature you need.
I personally also need hiking trails on my map, but I know people who don't and happily use CoMaps.
what's the point of the fork if it's missing basic features of the original app? it can't even display tram lines when tapping on tram stop...
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?
I've been using HERE WeGo for almost a year. I had to install a text to speech engine in order to get voice directions. (I installed the GlaDOS one, now the evil computer tells me where to go.)
https://www.here.com/products/wego
https://here-wego.en.aptoide.com/app
https://k2-fsa.github.io/sherpa/onnx/tts/all/index.html
Different scopes and purposes. Google Maps is made to find commercial activities and addresses, OSM is there to map the territory around.
I've settled on running CoMaps in the Owner profile, with Google Maps/Waze/etc. in the Owner profile's Private Space for when they're necessary.
Can that setup work with android auto? If so, I'll need to try that.
I use CoMaps in the owner profile with Android Auto. Only caveat is that even with Android Auto developer mode enabled, I still had to install CoMaps from Play Store to get it to show up in Android Auto.
I recommend Magic Earth. Free with traffic and navigation, and strong privacy promises (unlike Here Maps).
> I recommend Magic Earth.
LOL Bruh... this has a 1.7 rating on Android based on 42k reviews
https://play.google.com/store/apps/details?id=com.generalmag...
It used to be really good, and then it went to a subscription model, with a lot of back-and-forth uncertainty about the change. I suspect the rating reflects that.
Using Sandboxed Google Play doesn't defeat the purpose of using GrapheneOS and neither does using Google apps. It does not exist specifically to avoid Google apps or services. It exists to provide a highly private and secure OS retaining high usability and app compatibility. Being able to use sandboxed Google Play is an important part of what it provides. Many GrapheneOS users don't use it and many who do use it are only using it in a dedicated profile for a small subset of apps but that's not at all required to heavily benefit from GrapheneOS. Moving to more private apps/services over time does make sense but it isn't mandatory and users can choose what kind of compromises they wan to make.
What are some good alternatives
The best alternatives are self-hosted, e.g. your own email, CalDAV, CardDAV, and file servers, with e.g. K9 as email client.
Yes, you can have sandboxed Google apps: https://grapheneos.org/usage#sandboxed-google-play
Yes absolutely.
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.
What's the app data backup/restore story on GrapheneOS?
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...
Backup situation is absolutely awful, don't count on it.
Seedvault is still woefully insufficient, but it sounds like there's work being done to replace it. I can't imagine the enterprise crowd will overlook that and I'm hoping the Motorola partnership enables faster development.
> Seedvault is still woefully insufficient
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.
Thanks for your report. I'll give it another look.
Not without root, no
Memories of Apple force pushing a U2 album to everyone's iPod (or maybe iPhone) back in the day.
Or the more recent memory of the F1 ad pushed via the wallet app.
That was a hilariously tone-deaf incident, but it's hardly comparable. Google pushed ads. Apple gave you a free album.
Yes, but a _U2_ album. An ad is 30 seconds of irritation, but a U2 album is like having broken glass sown under your skin.
yeah but you aren't forced to listen to it
For people with no other albums, Carplay was playing that U2 album automatically when they enter their car. So some people were forced to listen to it :-)
I too, liked it.
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...
Yeah, I'm hanging on with GrapheneOS (on a Pixel) until their native-hardware (Motorola) phones come out, which hopefully will solve this. As I understand it, third-party (banks and so forth) app vendors have to accept their security attestation, which they don't right now, but (I hope) will with Motorola behind them.
Sounds like your work has been using your personal phone for free
Graphene is NOT a jailbroken/rooted OS, its a real secure unrooted, bootloader locked OS, and MS Authenticotor works just fine. If anything does not work its related to dependency of the App maker on a certain attestation google play services grapheneos.org/articles/attestation-compatibility-guide
Root =/= insecure. You probably have administrator access on your home computer operating system, and can very likely do online banking via the web browser with no issues. A secure API is possible regardless of the host metal, operating system, or user permissions.
Do you refer to app-accessible root or user root access? The former is absolutely inherently insecure and compromises the security model of Android/GOS.
Root on computers is insecure. Malware can steal secrets from other applications. We're just used to it, but the Android security model is much better.
Bingo!
Compliance =!= Security
This does not play a role - even if you lock your bootloader Play Integrity Checks still fails, and that means you can't use certain apps, MDM and overall restricts your usage. Thank Google for that.
Microsoft Authenticator works on my GrapheneOS (not rooted).
I hate how common it's become for companies to force you to install things on your personal phone. Even worse is some of them demand you install a MDM profile on your personal phone which feels 1000% over the line of reasonable.
I've just refused to install such things on my phone.
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.
Sure if you are in a strong stable position in life you can do that. The average person doesn’t want to rock the boat and cause troubles in their life so they install the invasive mdm profile.
It needs to be made illegal imo. The company should provide you a device if you need one for the job.
My company MDM doesn't consider GrapheneOS good enough to give me access to email/calendar - impasse?
"I would love to, but I do not have a compatible phone. I cannot afford it."
Spyware aside - I think about data breaches, even if my phone is "secure/compliant".
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.
From the linked article it seems this is related to Entra accounts which are Azure cloud related.
Google Authenticator works?
I think Google authenticator implements the standard OTP which lots of apps (including keepass) should support. Microsoft uses their own propietary crap
You can try to add the standard OTP even for Microsoft crap. If it asks you to register for mfa and opens the screen that says something about downloading the Microsoft authenticator app there is a small link at the bottom, letting you use another app. Then you get a qr code that you can scan with any other auth app.
I use a basic OTP password instead of Microsoft's ironically less secure (see SMS as 2FA) with my work MS account. Perhaps your org disabled it but it is definitely something a Microsoft account can do.
Proper Microsoft authenticator setup is more secure than OTP because it's pushed based and doesn't allow users to copy paste their OTP codes into phishing sites. Google also prefer push based MFA for this reason.
Push based, sure. Allowing SMS, I still hold, undermines all of this.
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.
[dead]
> [...] until I noticed Google had force bundled a 'Wicked For Good' movie promo theme with the latest security update.
This is how users learn to not update anything.
Won't matter when they force the updates anyway. You think that's your phone?
Happy GrapheneOS user here too since 2+ years now.
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.
How's the P10 camera on graphene? Literally 90% of the reason I'm on a pixel is because I love the low-light smarts that the camera software has, but I don't know if I'll lose that with Graphene.
You can install the Google Camera, if you use sandboxed Google Play. It has all the same features AFAIK.
It works exactly the same as in the original "Pixel OS", you just install the same camera app from Play store.
> Wicked For Good
Is this an antithesis to Don't Be Evil?
Any issues with banking insurance or healthcare applications?
Banking 90+% of apps work. Some apps officially support GrapheneOS.
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...
Why would you use app for actual insuranceb or even healthcare?
This is not really about me, but understanding if these apps have issues running under the OS. These type of apps typically have extra "security" features.
Such as? If there is dependency on proprietary software, you can install it on GOS if you want and consider it more "safe".
> Such as? If there is dependency on proprietary software, you can install it on GOS if you want and consider it more "safe".
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.
Chase bank app wont even load on my GrapheneOS lol
From what I recall, you need to enable exploit protection compatibility mode for that app, and it should work just fine.
I want to run graphene but I make android apps and need to test on device with a somewhat standard setup… login with google, etc. is this reasonable to do with graphene?
Yes. GrapheneOS maintains 99% app compatibility, and the 1% that is lacking is due to apps using incredibly misguided and nonsensical "antiabuse" mechanisms.
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.
Yes, GOS has excellent compatibility with Google. The play services are sandboxed like a normal app and work great.
Does this mean I could install Google wallet? I feel like this would be the only thing really stopping me.
Yes you can install and use it (I hold my passes, tickets and loyalty cards in there), BUT payments won't work for now because Google says malware-ridden Oreo handset is safe and secure, but phone without ad delivery network running in the privileged mode isn't.
There are alternatives for payments (scroll the thread, maybe look up on GOS discussion site).
No, unfortunately.
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.
I'd get a 2nd phone for that and it never leaves the house/location - living inside a bag with conductive material
Hmm, you should have cheaper and separate phone for work anyway?
It is my cheaper separate phone. Main phone is iPhone which I can test iOS on. Android is mostly for testing, and backup/utility on long trips.
What are you using for cell service? Been wanting to switch to GOS for years, but I've also been really uninterested in having to find a new service provider (currently using fi).
Makes you wonder who are clown employees coming up with these nonsense decisions
What's the status of banking apps, Google / Microsoft authenticator, and Google Wallet? Those were the things preventing me from abandoning stock Android.
You can check this crowdsourced list for the compatibility of banking apps: https://github.com/PrivSec-dev/privsec.dev/blob/main/content...
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).
Same, I've got a Pixel 9 and GrapheneOS works perfectly on it. I really love having full control over the OS on my phone and being able to decide what actually runs on it.
would it have the desktop mode and linux terminal? That's the only reason I'm eyeing a Pixel
Yep, I've used both. Desktop mode isn't exactly there yet, but hopefully with the general availability it will get with Android 17, it'll smoothen out. As for the Linux terminal I ended up sticking with a fork which provides a few extra features (https://github.com/outlawsanzhang/koiTerminal)
[dead]
hold on, are you saying graphenos has no ads everywhere? I need swap it in then
yeah the pixel 10 pro - which i have - only saving grace is graphene..
That Motorola phone that lets you install Graphene can not come soon enough. Pixel phones are not sold worldwide so it feels like they're gatekeeping security. I know that's not the case really, but there's very few ways to successfully degoogle otherwise.
> Pixel phones are not sold worldwide
Still boggles my mind the fact Google doesn't sell their phones worldwide. Obtaining a Pixel has proven to be quite difficult for me.
Not only obtaining but if you ever need warranty you're done. Just last week I went to a Samsung center and had my fold 6 fixed in 30 minutes, and these centers are everywhere around the world. Same thing with Apple, yet a 4.5 trillion dollar company can't ship and maintain a phone globally. It's so unserious.
They definitely can, they just don't want to.
And that's the unserious part, they really don't want anything to do with consumers despite making consumer products (gmail, Android, etc.) so you're always at the mercy of their automatic systems.
Google has historically always sucked at being a product company. Despite this, they're quite successful at it.
But when there was a battery/overheat issue with pixel 6a, I must say Google handled the fix / compensation surprisingly well. My sample size just being me, but very smooth process and compensation processed rapidly.
As the old joke goes: Microsoft is a software company, Apple is a hardware company, Google is an ads company.
Isn't that just the truth based on revenue streams?
Yeah. Could be difficult even if one is willing to forgo the warranty. My city has local repair services, they easily repaired my old Samsung phone. Servicing Pixels could be difficult even for them.
Out of curiosity, what was wrong with your Fold 6?
The inner screen built-in protector was peeling in the middle. It was out of warranty, but Samsung charged me 15$ which is very reasonable. The inner screen looks brand-new now, and I guess that's the benefit of these soft foldable screens - you can refresh the entire thing very easily.
It still boggles my mind that the most popular privacy OS requires Google manufactured hardware, that fact alone makes me not trust it at all.
They list their exact criteria for supporting a device. So far, only Pixels fit all of them (and I guess the Motorolas will soon)
https://grapheneos.org/faq#future-devices
> So far, only Pixels fit all of them
might as well list all features of pixel phones
GrapheneOS does not depend on all of the features of pixel phones. The baseline requirements GrapheneOS has are generic, they are not built upon or tied to what pixel phones provide. Pixels actually exceed the baseline rather than barely meeting them.
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.
Phone hardware is a hellscape it doesn’t surprise me at all that they need to keep the number of supported devices small in order to deliver a decent product.
Despite Google's other failings, it was the OG supporter of data portability, and that spirit extends to its phones. No other phone manufacturer with wide distribution comes close. It's unfortunate that the people who design the hardware do such a poor job with the resources at their disposal.
Is it still the case that Android backups leave much to be desired when compared to iphone? Pretty much the only reason I use Apple is that I can switch to a replacement phone and it’s exactly the same state as the last backup.
GrapheneOS is not going to compromise on hardware security for the sake of spiting one specific company. GrapheneOS supports all viable platforms, and right now that is the pixel lineup. Additional device support requires OEMs step up their game, and so far, only Motorola is up to the task, and we should get Motorola devices with official GrapheneOS support next year.
There is nothing crazy about doing something properly.
It's ridiculous is what it is. It makes me deeply distrustful of the organisation behind Graphene that they would make such a crazy choice.
The intersection of phones that have unlockable bootloaders, public-ish driver blobs and decent hardware is tiny.
What other phone would you pick?
Everything Lineage supports.
How do you reconcile that position with what Graphene OS lists as requirements for support, as linked by another commenter? https://grapheneos.org/faq#future-devices
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.
Please go read this and try again: https://grapheneos.org/faq#future-devices
If you want Graphene level security you need to have the hardware for it.
It is not ridiculous at all. GrapheneOS is not going to compromise the privacy and security of their users for the sake of spite for one specific company. It would be immature and irresponsible to make important choices based on spite rather than objectivity.
Motorola has stepped up to meet the baseline requirements for GrapheneOS support, and we should get Motorola devices with official GrapheneOS support next year.
AFAIK Motorola only lets certain geographical regions to unlock bootloader, not everywhere.
They're referring to the partnership between GrapheneOS and Motorola: https://motorolanews.com/motorola-three-new-b2b-solutions-at...
I'm aware. However, it is quite possible that they will only sell Graphene phones in certain countries considering their past behavior.
They could also just sell the phones with GrapheneOS already, as the final state of a GrapheneOS instalation has a locked bootloader.
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.
I just moved away from GrapheneOS to Motorola because I decided I needed an audio jack again. There's definitely some annoying things about leaving, but at least now I can use again the three apps that didn't work for me on GrapheneOS...
Which phone and is it android then? Maybe I'm out of the loop on Motorola. I just bought a pixel, thinking of trying graphene. I was a bit miffed about the lack of jack until my partner pointed out I hadn't used the one on my old phone for over a year. I'd like to in the future though.
I use usb-c dac and it is honestly fine. you can get one with charging bypass and keep that one with the charger
Which apps didnt work?
This is a thing now
https://volla.online/en/operating-systems/volla-os/
Posting about Volla in a GrapheneOS thread is... I guess courageous?
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.
Wow, good to know. Sounds like the kind of company that Worse On Purpose would love! The shenanigans people go through to make money…
For the curious: https://marbit.substack.com/p/worse-on-purpose
I don't see anything they offer for security that's not also in AOSP/LineageOS/eOS/stock/etc.
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
Not GP, but Volla phones are cool in that they officially support running proper Linux[1], so you could just use Linux instead of Android if that's enough for your needs. And you can still boot into their de-Googled Android if you need to run Android apps.
[1] https://volla.online/en/operating-systems/ubuntu-touch/
Volla just Eurowashes/rebadges other low to midrange phones at a huge markup. E.g., the Volla Phone Quintus is:
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.
It takes more than an unlocked bootloader to make Linux boot on random phones and work properly (and ensuring all the radios, camera, audio, phone calls etc work), and Volla have achieved that with their phones. I could be wrong, but I don't think it was possible to get a fully functional Linux distro going on any of these rebadged phones before Volla got to them.
Volla is just forwarding the trees made available by their upstream ODMs. E.g. Gigaset publishes them:
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.
Ubuntu Touch is drastically less private and secure than AOSP let alone GrapheneOS. Volla's devices don't come anywhere close to meeting the update and security requirements for GrapheneOS. GrapheneOS is a Linux distribution much closely following along with the Linux kernel LTS releases, unlike those devices. It also regularly moves to new Linux kernel LTS branches. Pixels are in the process of moving to the 6.12 LTS branch with Android 17 QPR2. 6.18 is currently in the early stage of stabilization.
Ubuntu Touch (or any Linux distro for that matter) offers drastically more freedom than GrapheneOS or any other Android distribution. Some people care more about freedom than so called "security", and I don't know about you, but I'll take freedom any day.
Freedom to get a stroke from an incomplete toy OS?
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.
Not everything needs to be "production ready". And giving out root willy-nilly is freedom. It's my device, I should get to decide how I want to use it and not have artificial restrictions put on my be by someone else. If I want to rm -rf /, I should be able to do just that.
You can, but maybe don't make it an easy to accidentally invoke default.
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?
>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.
What about Fedora?
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.
>What about Fedora?
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.
> 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.
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.
> 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
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
How can you be free when you're not private or secure?
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.
> Grapheneos is fully open source and comes with 0 Google services.
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.
MicroG requires privileged access. It also downloads and runs proprietary google code within this privileged context. MicroG additionally has very poor app compatibility and has had severe privacy issues in the past.
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.
Thanks, but there's no way anybody here hasn't already heard all of that. GrapheneOS' statements are inevitably reposted to every thread and subthread that touches on the topic.
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?
note where I wrote:
> 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
For context, GMSCompat is Google Mobile Services Compatibility. GrapheneOS installed the google play store and services as normal apps, and worked backwards to make it behave. There is no google specific sandbox, rather it uses the standard android user app sandbox. This means google is bound by the same rules, as special casing anything creates more maintenance burden and attack surface. GMSCompat is fully open source.
> "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.
> How can you be free when you're not private or secure?
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.
You can't have privacy without security.
Privacy is when nobody is looking, whether that's because they cannot look or because there's nobody that looks.
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)
That is a vague, meaningless statement. What sort of privacy are we taking about? What sort of security? What's the target? What's the attack vector? What's the environment? What's your threat model?
Without all of those details, your statement is meaningless.
Oh, one vendor supporting multiple OSes! I hadn't clicked through (https://volla.online/en/operating-systems/), that is neat indeed and quite a unique selling point among mobile vendors
This should have gone in my spreadsheet before I chose a new device xD. Ah well, next time
Android similarly supports, and in fact uses, "proper" Linux. Android and its forks are Linux distributions. You can use a mainline kernel in Android just fine.
Nah, Android is not a really a proper Linux system that 'supports' Linux software within any reasonable definition of the word; not anymore at least
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
Most of this is not related to the claim and is more tangential discussion about things you like that run on the linux kernel, now, there is nothing wrong with that, but I must emphasise that none of what you describe is a part of the criteria for what constitutes a linux distro. A linux distro is an operating system using the linux kernel. Android fits that criteria.
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.
Sure, we can have different opinions on what makes a useful Linux distribution. Either way, you can't install Ubuntu Touch on just any phone. That Volla supports that alongside their AOSP derivative gives you more options on how to use the device; it's worth pointing out to potential buyers as a bonus on top of running Android only
They look way more trustworthy.
Those are much less private and secure than the Android Open Source Project on Pixels without the major privacy and security improvements of GrapheneOS. Those aren't privacy or security hardened devices.
I've been using Graphene on my Pixel 7a for about a year and I'm happy I made the switch. For sure it is a bit rougher than using Google's OS, but not enough to make me regret it.
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...
> 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,
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.
Yes! FUTO keyboard, then go into VOICE INPUT → MODELS → Explore Voice Input Models → English-244: “Best for the most accurate results, but more demanding.”
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 just did. I had been using FUTO voice, but I see that FUTO keyboard also supports voice input, so I'm not sure if I should delete FUTO voice as being redundant now.
I don't believe it's necessary, it's move of an "if you want a dedicated voice keyboard, the UX is a little better" option. I don't have both installed though, as anecdotal evidence.
There's also Heliboard, which has a swipe-type option
Thanks for your thoughts. I use FUTO voice usually, but there are situations where typing out a short message is better -- eg, in a restaurant or doctor's office or someplace where voice input might bother other people.
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.
> 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.
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.
They are referring to Gboard and Pixel UI or the stock OS shipped on Pixels.
FUTO and GBoard has the feature you're describing and I use it all the time. Pretty much anything you miss from Pixel UI can be attained by simply installing Google's app from the playstore.
The problem I still have with the futo one is that it can't swipe type in multiple languages without switching every time. Gboard can do that. I use 3 languages intertwined constantly so I need that.
So I still use gboard but block its internet access.
Have you tried Heliboard? There's a few clicks to do, but I think it has multilingual swipe input.
Problem (1) is a keyboard problem, not a GrapheneOS problem. Graphene comes with the stock AOSP keyboard which is very basic, but you can absolutely replace it. Personally I'm using the FUTO Keyboard and it does have that feature, as well as swiping, speech to text and much more.
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.
Regarding 2: that is literally how SMS reactions work. Apps that recognize it just interpret it as "put that emoji on that message". It is unfortunate that it doesn't do that tho.
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).
GrapheneOS will eventually have a GrapheneOS RCS app, but for now RCS is fully supported via Google Messages and sandboxed Google Play:
https://grapheneos.org/usage#rcs
There have been consistent problems with activating RCS, for many years. But it does work for some/many, yes.
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.
For what it's worth, strcat is the GrapheneOS founder so they will have a keen insight into current plans.
It's always good to be wrong about good news, then :)
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.
I agree with this post and add one anecdotal data point.
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
Yeah, it's pretty awful tbh. I generally recommend disabling RCS, after learning a lot more about it - it feels like a hostile grab at global messaging at this point, heavily entrenched by telecom agreements. Use Signal or something instead.
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.
Yeah RCS always has been an embrace extend extinguish thing. The carriers were super pissed to lose their SMS revenue to WhatsApp and iMessage so they came up with this shit to be an active partner in the loop again, and they can bill for it again. Consumers didn't fall for that and it died off.
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.
> Yeah RCS always has been an embrace extend extinguish thing. The carriers were super pissed to lose their SMS revenue to WhatsApp and iMessage so they came up with this shit to be an active partner in the loop again, and they can bill for it again. Consumers didn't fall for that and it died off.
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.
RCS is not modern. E2EE is only an addon and it's not open. As others have mentioned it's not even available with interoperation. And it was really invented by carriers for exactly that purpose: To regain SMS/MMS revenue. But at this point here in Europe SMS usage between people had vanished anyway (except for spam and poor 2FA implementations)
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).
iMessage isn't a thing in Europe?
No not really. It's technically available but nobody uses it. Everyone is on WhatsApp. Even companies. I never get messages from contacts on SMS either (so it's not going through fallback). I think it's because iOS just isn't really that widely used here. Not used enough to have critical mass for an iOS-only messaging service.
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.
> RCS is not modern.
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.
This is an extremely strange rewriting of history in which Google is some kind of altruist, moved by the plight of suffering school-children in a brief period where the rich bullying the poor (something truly shocking and unprecedented) over the color of their messages simply couldn't be tolerated any further.
Yeah what would really get me onboard with RCS if it were actually open, if I could choose which RCS provider I wanted to use. Like a privacy-driven foundation similar to Signal. Someone I could actually trust.
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.
I wouldn't be particularly surprised if they're hiding the spec / charging pointless $$$ to reduce access, but I was under the impression that it would be available, like RCS's spec itself. e.g.:
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.
Ah when I last checked the E2EE was only in practice implemented by Google and invented by them. It looks like this might have been opened up, unless this is an earlier version somehow? And interconnect traffic to e.g. iMessage was not E2EE.
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.
yea, from my understanding Google has had E2EE when messaging itself for a couple years or so now, mirroring how iMessage encrypts messages to itself. iMessage is even very similar (maybe identical) to MLS, and Google Messages might be as well but I don't know the details. but neither encrypts when sending to the other, nor any other client/server/etc, because there is no agreed-and-implemented spec last I looked (a few months ago).
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.
RCS via Google Messages and sandboxed Google Play is fully supported on GrapheneOS:
https://grapheneos.org/usage#rcs
Yes. It was kind of a bumpy road getting there, but I haven't had any problems for the last 6 months or so.
Regarding (1), that's on your keyboard, which you can choose. Maybe you can give Futo a try? https://keyboard.futo.org/
Why does it need its own F-droid repo?
Because the code is not provided under a free/open-source license, and therefore does not meet the requirements for the main F-droid repo.
Ah interesting. They use the "FUTO source first" license. https://github.com/futo-org/android-keyboard/blob/master/LIC...
Open source with limitations on commercial use.
Technically it's "source-available", not "open-source".
Simple Keyboard is on F-Droid too. Supports moving cursor via space bar.
Same for HeliBoard
I use GBoard on GrapheneOS. I just deny it network permission so it can't phone home.
I used to do this but I found it downloads needed language files in the background. So every time it updated, I would clear all the app data, open it again on something innocuous, like a text file, toggle each language I used. Not knowing how long it would take, I'd wait until each seemed to be behaving, then disable network permission. I still don't trust that it doesn't send data off via Play Services.
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.
I do usually this, but recently on older phone (using it temporarily while I buy new) I had to reinstall it and found out, it didn't provide any word suggestions for ant language other than English and even gesture input for other languages didn't work, so at least during initial setup it must have (now?) internet connection most likely to download dictionaries (I thought they used to be included in past, never noticed this before), after allowing the connection, setting up and then disabling the connection, it works fine
Other people have noted that you can switch out the keyboard and SMS app (which I did).
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.
You should consider using signal as texting app?
You shall engage more with your apps, user!
I used to dread the promised deep system integration of AI, but honestly after setting Claude up on a server box and having it do sysadmin stuff for me that I've been putting off for ages I see the vision. I don't really want to mess with the details of working through system orchestration tasks, I want to say "spin up this service" and start using it, "change my config so X happens" and it does, and knows what needs restarting to pick up changes and all the fiddly knobs and configs that need syncing and their bespoke formats. I think Nix tried to unify this for people, but it arrived too close to LLMs so a lot of value (in this dimension) has been delivered by other means.
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.
The vendors are never going to give you control over your computer no matter what vision they try to sell you on. The whole point, from their perspective, is to use their control of your computer to gain more control over you, which they hope to then exploit for profit.
Right: Look at the ways Google has persistently taken away user-control and autonomy on the OS level.
Why would we expect the same company to exhibit a completely opposite philosophy as they add LLM features?
Idk I feel like Ansible and RHEL aim to give you that control in a way that’s not typically corporate icky in the way you describe but ymmv. Granted both are products based on FOSS; so in the broader sense that pattern may hold
Yes, Google famously uses their most advanced technology to make your life easier and not to look up your nose with a scanning electron microscope
The thing is they don't setup their "intelligence system" for the type of task you wanna do. They are integrating it for tasks like "buy me a plane ticket for my next holidays", "order diner for me, the usual"...
I took the plunge into GrapheneOS a week ago. I picked up a new Pixel10 Pro and never even tried the stock OS (except to unlock the boot loader).
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.
The most hilarious is McDonald's app - it refuses to work without Play Integrity check. I wonder what braindamaged reasoning is behind this. Do they want to position themselves as a bank or something?
I recall a year or so ago, there's been a story about someone hacking McDonalds loyalty program, with that app doing something stupid like storing your balance on the client or something. It seems instead of firing whatever offshore sweatshop that made that, they just doubled down on "mitigations".
Was it this it this one by Eaton Works?
https://news.ycombinator.com/item?id=42462354
the app actually did the play integrity thing long before that :P
Also on the homepage: "Volkswagen started blocking GrapheneOS users"
Huh, it works just fine in the UK. Wonder if they have different builds (or completely different apps) for different regions. Or maybe it's the GrapheneOS compatibility layer that makes it work? Not sure.
Play Integrity has several levels. GrapheneOS MEETS_BASIC_INTEGRITY, which I believe only requires a locked bootloader and no superuser.
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
I saw on the GrapheneOS forums that some people had managed to get it working, but I was unable to do so.
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.
Hmmmm.... Actually you can have an unlocked bootloader for the basic integrity level.[0]
[0] https://developer.android.com/google/play/integrity/verdicts
Fastfood apps typically offer deals to new customers.
I suspect this is an attempt to prevent folks from spinning up many new accounts to get these deals.
What would anyone use an app to order food from McDonald's? Just walk into the restaurant, pay cash, and walk out with the food.
McDonald's app (other other similar apps) offer discounts to ordering through their app.
For example, McDonald's has a long running campaign, 99¢ for coffee. Any size, iced or hot.
"Strava is an American internet service for tracking physical exercise which incorporates social networking features."
Sounds like spyware, to be honest.
I don’t know about the company’s ethics*, but the app is fine and it’s genuinely useful. For one thing, it has a map with the most popular running routes around you. And if you want to be part of an exercise community in the US or Europe (at least UK), it’s the only game in town. *Strava is one of the worst apps I’ve seen in terms of aggressively upselling you to a subscription. Genuinely infuriating.
I know a friend is using Strava on his Pixel 10 running graphene so there should be a way
There should be a way, but I have not yet found it, and I've spent some time on this. I've installed/uninstalled Strava about a dozen times, rebooted each time, tried various permissions, but stood my ground on some of the permissions. Should I give Strava access to my photos and my microphone? I'll never go that far.
Regarding the photos, the "storage scope" feature on Graphene should make that a non-issue. Microphone would be rough, but at least you would see a "microphone icon" show up on the top of the phone if an app was actually listening.
I run Strava on my Pixel 10 Pro Fold running GrapheneOS. IIRC you need to have Google Play Store installed (with zero permissions, preferably) to make Strava work.
Both Google Play Store and Google Play Services are installed, with minimal permissions. Strava still does not work.
You have to give it more permissions. You shouldn't blame GrapheneOS for an app not working when Grapheneos simply gives you more control than stock and you are taking advantage of it.
Of course many apps work fine with turning of more permissions that GrapheneOS allows.
~Happy iPhone user for almost 20 (!) years. This has got me seriously thinking about picking up a Pixel.
I feel like you'd be taking on a lot of pain for no real benefits though?
I did this half a year ago and it was fine for me. One of the benefits is of course privacy. For instance, I noticed that ads get completely out of touch which proved to me that I'm being tracked less.
Also never have that feeling anymore that my phone is spying on me.
Any iPhone user with a measure of privacy knowledge will experience the same.
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.
Apple still pushes ads to you. I can't recall how many times I saw ads in the App Store, and how many times they tried to push me into subscribing to whatever nonsense their executives' KPIs demanded (Apple Arcade+? News+? Music+?). No matter how many times I told Apple "No," they just kept pushing it. And now ads are coming to Apple Maps as well.
GrapheneOS has zero ads in the OS and main services.
real benefits: being able to install free software
What are North American people doing for replacing contactless payment? Last time I checked, the solution was to use Curve but it only works for Europe.
I don't. GrapheneOS is worth the effort of pulling a card out of my wallet.
In general I'd agree.
Curve demand a "video selfie" and I've never been comfortable with sending companies such biometric data.
It's infuriating that they won't do this for non Google Android. It's in the best interest of both the bank and the card owner. Credential theft risk goes down to basically zero when backed by a fingerprint authenticated virtual card.
I'm sure contrats between Google and banks provide the financial guarantees that not open-source project would be able to. Unless governments mandate there's zero interest from banks to put extra effort into building for unpopular solutions
The bank makes money on chargebacks, so they have an incentive to allow a certain level of scams.
What do you mean by credential theft? Stealing the numbers on the card or a malicious person triggering the contactless payment?
Stealing the numbers. Could've been someone taking a photo of the card out of sight. I honestly don't track my card that well when I'm out cause it's easy to have a transaction voided if it's legit not me. Then again cameras are everywhere now.
Banks don't want the headache of supporting multiple weird phone OSes and it's understandable. As long as they don't require running an apple/google-certified device and OS I don't care.
> Banks don't want the headache of supporting multiple weird phone OSes and it's understandable.
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.
> Commercially, this makes sense.
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.
Does skimming still happen a lot? At least in Europe we have switched from magnetic strip to chip-based cards, which are protected against replay attacks.
We have chips but magnetic strips are still on most credit cards and payments are still accepted that way in many older payments gateways. From what I read on the topic the cost of lost business if this was disabled is greater than eating the cost of skimmer attacks. There is a several year plan to phase it out entirely. It's mostly because initially when chips came out a lot of business owners were angry that they had to buy new payment machines and good luck explaining this to a none tech person.
In the UK, many banks disable the magnetic strip by default, and you have to temporarily enable it from the bank's app/website if you want to use it.
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.
The US first got magnetic strip readers in 1970 so we just have a ton of infrastructure using them. Since most people drive pickpocketing and things of that nature are much less of an issue for us. Typical use has someone using the card for everything then paying it off at the end of the month so if there's a random extra charge the credit card company will typically let it go to maintain the active user.
whether a device is rooted kinda does matter from this pov as it undoes a lot of the security assumptions on android...
however grapheneos isn't rooted anyway
We're talking about just in time tokens that disappear after use. There's nothing you can do to defeat that on a rooted device. That's the whole point of the entire tech. That's why yubikeys are even a thing.
I'm in Europe, but I had accepted that I had to do without. I hadn't heard of curve, going to check that out.
the Play store reviews for Curve are attrocious, especially the most recent ones. Looks like Curve is absolutely unusable, for many reasons
I notice that their user identity verification involves "Entrust":
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 have these cards I keep in my (RFID-blocking) wallet, one for each credit account. Then I just pull them out and tap to pay. It's super convenient - no app required!
What does RFID-blocking wallet do?
People cannot steal your card info via proximity to your wallet over NFC if the wallet’s physical barrier blocks the RF signal.
People can't steal your card info via proximity to your wallet over NFC even without an RF blocking wallet. This is tinfoil hat security cargo culting, like putting tape over your webcam while leaving the laptop's microphone connected (audio from your room is much more useful than 2834823428 frames of your greasy face).
No but they can steal up to the pin-free amount of money your card allows. They can just hold a sumup to your pocket. Here in Europe most people use debit cards with non-reversible transactions and that limit is often 70-100€ which is quite a lot of money where I live. And they can steal a lot more if they follow you and shouldersurf your pincode.
I definitely use one of those wallets. They're quite convenient too.
[flagged]
Can you please not post aggressively like this? It's against the site guidelines because it destroys what HN is supposed to be for.
If you wouldn't mind reviewing https://news.ycombinator.com/newsguidelines.html and taking the intended spirit of the site more to heart, we'd be grateful.
[dead]
The person mentioned it like it's a feature for them, but I haven't heard of it being anything other than a marketing gimmick, so I was curious for their perspective.
It just has a Faraday cage and blocks radio signals. That's it.
Garmin pay if you're ok with Garmin is one possibility.
It's even available in my country! Never heard of it, would have assumed it's not being sold here. Let's see what that costs when I click the "shop now" button that's front and center
> 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
They have an app for Android that can do NFC? I thought it was only for their watches. Thanks!
They don't support amex or capital one, the two I use the most...
There is no replacement. Strap a credit card to the back of your phone or pay cash.
Use a solvent to dissolve the plastic from the card then epoxy the extracted antenna and chip innards to the back of your phone case. Problem solved. (I'm only 50% joking, you can actually do this but maybe epoxy isn't the best option.)
Somewhat similar, Polar sells a band with an NFC payment chip in it (no experience, just saw it the other day):
https://support.polar.com/en/payment-wristband
Other solutions that use the same underlying technology:
https://fidesmo.com/consumer/wearables/
I'd like to do this, but epoxy it to a dress watch
Cash for most things, and just use a card like normal otherwise.
I don't really see the appeal of contactless payment, pulling a card out really doesn't take much time.
Just having to take your phone with you is quite comfortable. Your phone is probably the pocket-sized item you are unlikeliest to lose.
True, but I also need my license to ride my motorcycle or drive a car, plus cash needs to go somewhere.
The perks of living in a city with good public transport
+ my country already has a mobile driver's license app
And most places take card (or nfc via google/apple pay)
Google Pay (Google Wallet) actually also has virtual number so my real card number won't leak in many cases.
Cards are "contactless payment" these days.
There are a few other banks running their own NFC payment systems, like Swedbank in my country.
I am not North American, but instead of Google Pay I use my bank's app for contactless payments.
Putting my credit card in my phone case
Graphene made me like using a phone. It behave like a computer. Really lovely
I can say the same. Been using LineageOS and GrapheneOS for most of my life. Some things are not super convenient (I generally dont install non-free-software applications and don't have Google Play services enabled), but the rest of the experience is great. No crashes, no bugs, no unexpected behavior. Currently I'm using the Pixel 9 Pro XL.
I can also recommend Gadgetbridge for BLE smartwatch integration.
Also on the homepage: "Volkswagen started blocking GrapheneOS users"
That's exactpy why I get Google Pixel phones.
Support 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.
The iPhone 11 was released almost 7 years ago and is still supported by the latest iOS.
For context, that would put it at the same release as Pixel 3 or Pixel 4. Those devices stopped receiving updates in 2022-2023.
That is not relevant for pixels at and above 7.they all have guaranteed 7 years of security updates, which is longer than iphones 5 years.
the only problem I have with grapheneos is that it doesn't support E911 or the equivalent European standard https://github.com/GrapheneOS/os-issue-tracker/issues/1174
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.
I have always wondered what this OS looks like. They have an incredibly detailed website with zero screenshots.
There are numerous video walkthroughs of GrapheneOS. This would be one starting point:
<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.
Clarifying, a stock install of GrapheneOS has far fewer apps.
It's valid question for people unfamiliar with the project, but it is the AOSP in terms of looks, GrapheneOS does not customize the UI in any way beyond what their own features require as additions. Note that Pixel OS is not AOSP. The default home app of course also influences the experience quite the bit unless you replace it, which is what I'd personally recommend everyone to do as it's so incredibly barebones. Lawnchair is already a big step up as an open source alternative.
Perhaps screenshots and sleek UI is not their selling point (and it isn't).
One mans sleek ui is another's trash fire
It looks very plain (black background, monochrome icons, very few apps included). You can customize all that if you want. I personally quite like the default appearance, but I am also the kind of person who uses the default GNOME or KDE theme on Linux and does not bother with custom themes or anything beyond daily Bing wallpapers.
The post doesn't say - what's new? Anything to look forward to besides the security patches for A17 being available for longer than they will be for A16?
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?
Desktop mode is new and exciting.
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...
Ah, right I forgot they are discontinuing ChromeOS. Makes sense that current Android releases are focused on getting the Android laptop experience on par
Edit: not discontinued but 'merge with Android' https://en.wikipedia.org/wiki/ChromeOS
New garbage collector could be pretty big.
But some of the garbage collector changes are also rolling out to older Android versions through a Play System Update.
https://android-developers.googleblog.com/2026/06/Android-17...
I'm not sure though if GrapheneOS gets mainline modules at all (most likely not).
Presumably any new Android 17 features that aren't counter to GrapheneOS's mission, such as "Bubbles allows you to turn any app into a compact, floating window" https://blog.google/products-and-platforms/platforms/android...
Does GrapheneOS run on tablets? I don't see a whole chat app (shown in the example) fitting on my phone screen alongside something like a web browser, and the screenshot is from a square screen
GrapheneOS runs on an extremely limited set of hardware, mostly Google's own Pixel phones.
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_...>.
It's complicated. The Tensor G2 Pixel tablet was a solid device, and you can still buy it new from Google (with no choice on color or size in my country), but production has been discontinued and the two direct generational successors were canceled, in sequence. First it was skipping a generation, then it was canceling it entirely. The rumored "Pro" version also appears to have been axed.
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.
> production has been discontinued and the two direct generational successors were canceled, in sequence. First it was skipping a generation, then it was canceling it entirely. The rumored "Pro" version also appears to have been axed.
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.
It really is.
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.
It runs on tablets and folding devices. There hasn't been a recent tablet meeting the requires but the Pixel 9 Pro Fold and Pixel 10 Pro Fold are supported. Both of those are phones folding out into a close to square tablet. There will be more standalone tablets supported again.
There's an (un)folding Pixel that runs GOS. Not exactly a tablet, but possibly sufficient depending on your needs. Not cheap, however.
Not sure about tablets, but you can connect most of the recent pixels to a display
I have two questions, if anyone has any advice.
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?
1) any currently-supported device is good, but i'd say go for minimum pixel 8a if you can
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
Thanks! (And thanks to the others responding here too.)
What are the reasons to avoid /e/, according to you? (And not according to the GrapheneOS maintainer).
Because why would you trust an operating system of which the companies CEO says that security hardening is only for criminals and spies?
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.)
>I could go on for a while
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?
I would suggest Pixel 8 series or later, since they get 7 years (instead of 5) of updates, which is also decisive for Graphene support duration.
1) I'm typing this in a pixel 7 pro running grapheneos. I'd say these are plenty good enough. Device support is pretty solid compared to cyanogenmod of previous times. App installation is a bit slow using sandboxed play store. Not sure why that is.
For security reasons, GrapheneOS uses ahead-of-time compilation for apps. The stock OS compiles the heavily used parts of the code dynamically in-memory and then does partial ahead-of-time compilation later in the background. The install-time compilation will become more asynchronous in the future so the app can be used right away.
We Have been successfully using graphene on a pixel 4 plus, 5 plus and a 6pro. They all work. Very well. They were cheap to buy. Super easy to install graphene (remember they have a very easy stepu by step process, takes about 10 minutes) It's a good way to test and see if you like it. Truly amazing operating system. Simple and beautiful control of your apps and their behaviors.
If you want to try it out, you can easily buy an 8a for like 250 euros used. 128GB is certainly good enough, unless you plan on migrating your mp3 library to it or you take a lot of videos. My only qualms is the lack of SD card, for the aforementioned mp3s.
And trust me you'll like it ;)
299CHF for pixel 9a NEW in my local electronics webstore - the only difference between this and 10a is increased level of flatness of newer one..z
That's 325 euros, and here the cheapest you can find it is 350. which is is almost 50% more. Whatever floats your boat !
Pixel 7 is definitely good enough if you don't have special needs. I'm writing this from a 6a right now.
Any phone that is good enough with stock Android for your case is good enough with Graphene. If you really just want to try it out, it's the cheapest old Pixel *a you can find.
Checking which phones are supported by Lineage and Graphene can be done by everyone in a matter of minutes.
https://android-developers.googleblog.com/2026/06/Android-17...
> 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?
No, the Ai features come from Google apps and services that you can manually install. Grapheneos doesn't ship with any Google services.
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.
Jumped to GrapheneOS a few months ago. Works great. The keyboard was bad but you should install FUTO, as some other comments recommend.
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.
Why don't you connect with the makers of Madrid and see what they can do about it? That is sometimes the best way to fix these types of incompatibilities.
If you are new to GrapheneOS and wanna try. Here is the great introduction: https://dataswamp.org/~solene/2025-01-12-intro-to-grapheneos...
That looks like a good intro!
And they accept XMR donations, so instant credibility boost.
With Google making side loading extremely difficult soon, there's never been a better time to switch to a more secure OS for your phone.
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.
Rethink DNS is in the Play Store though:
https://play.google.com/store/apps/details?id=com.celzero.br...
Its there. Before rethink I used DNS66 which is similar. Only available on F-Droid.
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.
I was using GrapheneOS for years, until the battery died while I was on an important call, trying to get someplace. Plugged it in, but little did I remember that I had installed OS update that was pending app optimization phase that happens during next boot.
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.
App optimization happens in the background now, and pops a notification when it is done, asking to restart all open apps.
Oh, then the biggest pain point I've had is now resolved. I should give it another go.
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.
I'm not sure how Garmin works, but for instance with Google Wallet-compatible watches, you need a phone where wallet can run. I've had this setup for a year where I loaded the cards from another phone and used a watch to pay.
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.
You only need a phone to add the card to the watch. After that it works without a phone.
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.
I have multi day battery life and I only charge to 80% so it was either user error or a hardware failure.
GOS has much better battery than stock pixel ui because of less services and telemetry.
i have mine set to auto-restart for updates and i shortened the 'restart when idle for n hours' value so it usually just does everything at night
> GrapheneOS recommendation to this was to have fewer apps
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.
Having many apps will not affect battery life on Android in any meaningful way. Actively using them will. Apps can't just sit there and run in background, unless you explicitly gave them that permission.
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 don't trust the battery usage screen. When I debloated my phone, battery life increased from 1,5 days to 5 days and those were all apps I don't use.
Sadly not an option as long they don't support Fairphones
Fairphones are far from meeting the security requirements to run GrapheneOS and have chosen an incompatible path. It won't be available for their devices.
https://discuss.grapheneos.org/d/24134-devices-lacking-stand...
https://grapheneos.social/@GrapheneOS/116353973732143171
I don't think that fairphone is interested in privsec so it will never be supported.
them supporting e/OS suggests otherwise
/e/ is the direct opposite of a privacy or security focused OS. It doesn't provide bare minimum standard privacy and security patches while setting an inaccurate Android security patch level. It lags many months behind on patches even on devices where they're the least behind. It's typically years behind on kernel, driver, firmware and major OS updates. It doesn't keep the standard privacy and security protections intact and lagging behind on OS updates means not having the current ones. It sends user data to OpenAI and other third parties without consent.
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.
It seems to me that /e/ is opposed to privacy and security.
https://xcancel.com/GrapheneOS/status/2066908368560656652#m
It's interesting how you are able to conclude that.
e/OS is clearly a step up from default Android
/e/ has drastically worse privacy and security from the Android Open Source Project or especially and iPhone. It's not a step up from standard AOSP. It lags many months behind on many High/Critical severity patches, years behind on overall patches and rolls back the privacy/security in a bunch of ways. It includes many invasive services.
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.
Insinuating that real privacy /security is for pedophiles and criminals is primarily what supports my conclusion.
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.
https://xcancel.com/GrapheneOS/status/2040887784253141142#m
This German security researcher maintains a comparison table showing the differences between mobile OSes.
https://eylenburg.github.io/android_comparison.htm
No, them supporting e/OS corroborates the claim that their goal is not privacy or security.
What do they need to support to convince you? Providing all hardware features required by GrapheneOS is not feasible for a small company.
Fairphone doesn't design or make their smartphones. The devices are designed and made by a large ODM. It's entirely feasible to use a modern SoC with current generation security features and provide proper updates. Their ODM isn't doing it to cut costs.
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...
> What do they need to support to convince you?
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
You completely missed the context here. my comment was not about skipping the security features of GrapheneOS. The original parent comment was
> 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.
> Providing all hardware features required by GrapheneOS is not feasible for a small company.
Supporting all hardware required by fsflover is not feasible for a small project.
From Google's Android 17 release:
> ... 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?
Been toying with the idea for a long time, but I'm concerned about US financial institution apps and multiple countries specific apps (local transport, finance, medical and governmental), whose apks do no exist, as well as (crucial for me, as a heavy international traveler) google voice. For a lot such I now need to use a combo of Google playstore, for US account tied apps, and Aurora for non US apps.
You will find that a lot of banks and other companies have old fashioned websites that open work better (and more privately) than apps. Even Google Voice should be usable through its website. However what is usually recommended by the Graphene community is to call or text via Signal instead.
> We've already tested the Android 17 port of GrapheneOS on the Pixel 6a, 7, 7a, 8, 10a, 10 and 10 Pro Fold.
No love for 9 or 9a? I guess it's still coming eventually.
- A 9a owner running GrapheneOS
https://grapheneos.social/@GrapheneOS/116761945417419946
>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.
I've been thinking it might be worthwhile to showcase that you can make GrapheneOS look beautiful or the same as stock Pixel UI. When I was considering switching from iPhone I had this misconception that it would look ugly or wouldn't look the same as Pixel UI, which is not the case at all. When I asked about it I wasn't given this clearcut answer that you can make GrapheneOS UI look the same or better than Pixel UI.
How much flexibility is there in changing appearance?
As an iPhone user, I really like what Oppo is doing with their ColorOS: https://www.oppo.com/nz/coloros16/
Wow that looks nice. I don't think you can get that.
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.
Thanks! I've been contemplating trying out Graphene, but I really enjoy the user experience of iOS. But I feel like I should at least get acquainted with Graphene as the inevitable enshittification of iOS will occur.
Definitely try it out! The key to good UX on Graphene is choosing the right apps.
I run GrapheneOS now 2 year :) always working fine
What does it mean for an OS to be ported to another OS? Do they mean "ported to devices that support Android"?
It means they rebased all their changes on top of the new version. This is usually time-consuming because AOSP is not developed in the open, so you can't do this incrementally as things change -- you just get a massive drop sometime after release.
Android makes yearly releases. It is developed in cathedral-style. Google releases the source as a single big update. GrapheneOS is a fork. They need to port their customizations and extra software on top of the new release.
Every six months, not yearly. Google releases the major version and QPR2 as part of AOSP. QPR1 and QPR3 are Pixel-only.
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.
It's a fork of the Android Open Source Project (AOSP) with major privacy/security improvements and alternatives to Google apps/services. The massive set of changes needs to be ported to new major versions of AOSP.
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.
Think of GrapheneOS as being a set of patches on top of the Android Open Source Project that Google releases:
https://source.android.com/
They've ported the patches to work on top of the latest release.
Well, both, probably. GrapheneOS requires a lot of framework and device side changes.
I wish they supported much more phones
Only Google Pixel’s and Fairphone’s currently provide bare minimum for 3rd-party OS support: working verified boot with user-provided signing keys. None of the other phones doing that yet
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
There are a lot of devices with the ability to install another OS and lock the device with verified boot, but none with the required updates and security features other than Pixels. Fairphones are near the bottom for security among the available options.
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.
[dead]
[dead]
I own a z fold 6.
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?
You can't install Graphene OS on Samsung phones.
GOS won't install? It's blocked somehow? Or it's not officially supported?
It's not supported and you cannot unlock the bootloader most Samsung phones anymore (IIRC since OneUI 7).
It is only developed for Pixel phones
It isn't only developed for Pixels. Pixels are currently the only devices permitting an alternate OS with the required updates and security features. GrapheneOS has a partnership with Motorola Mobility and there will be official GrapheneOS support for a subset of next generation Motorola devices.
GrapheneOS would be so much more interesting if there was an official supported way for rooting it. That's the only reason I haven't switched to it on my several devices (all rooted)
That completely goes against what they're working towards. I understand why you would want to root your own phone, but GOS is targeting highest security standards and root ain't one of them (for good reason).
But in that case why you would need to use GrapheneOS at all? Without security you cant have privacy and OS with security as priority cant just add hole in the system because it would allow to bypass all security features added on top of AOSP and AOSP features too. Most features people use root for can be achieved without root by modifying Android Framework itself with SystemUI/Settings app
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
If you value freedom to do what you want on your devices, then you may want to consider Librem 5 instead. It runs a desktop Debian derivative with full root access.
You have the ability to do what you want on your device. Root access in AOSP is just used as a hacky shortcut to achieving specific functionality. To do it properly while maintaining the security model would be to build it into the OS itself. The same concept applies to desktop platforms and the Librem 5. This isn't related to freedom.
That device, and the Debian derivative it runs, are not private or secure.
What do you mean when you say "not private"? Are you accusing the company of sending private data to their servers, as Google and Apple do?
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.
Maintaining one's data as private requires that it is protected as a baseline. Privacy violations do not solely exist as telemetry or data offered up by the platform to some other party.
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.
> Maintaining one's data as private requires that it is protected as a baseline.
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.
>> Maintaining one's data as private requires that it is protected as a baseline. > So you're conflating privacy with security, as I expected.
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.
So this comment of yours just states that I'm wrong and the parent is right. I see how you advanced the discussion here.
> 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.
They value privacy and security. Allowing userspace apps to completely circumvent Android's permission system massively weakens both.
But the we need a compact high-end phone for this.
From two months ago:
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.
It's quite a big phone compared to the S10e.
I've been running GrapheneOS for over an year now. Bought a Pixel 6a last year as a cheap way to test waters, but pretty soon I upgraded to discounted Pixel 9. It took a while to set the basics (coming from iPhone), and I'm still have a couple of stuff missing, but at this point don't intend to use anything else (for as long as possible).
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)
I started rebuilding my phone from factory tonight, and I opted for the private profile partition inside of the main profile for my play store apps. It's accomplishing everything I wanted a fully separate profile to do without the hard switch.
I made the same mistake after being burned by the PinePhone, buying a heavily discounted Pixel 6 to test various Android forks, which eventually included GrapheneOS. I quickly knew I'd found home upgraded to a 9 Pro XL.
Couldn't be happier using this on an old Nord Oneplus N10. Had to look around since it was out of date but thankfully they have archived builds.
What's the biggest draw of GrapheneOS apart from de-googling? Does it have a better battery life? And compliance with NFC payments?
For me it's the added security features: per-app network permissions, scoped storage/contacts permissions, and a bunch of system hardening measures.
Greatly improved privacy and security and end-user control of your phone and its data. In those areas, possibly the best option, though iPhones might be better in security (not necessarily the other two areas) - Apple has a slightly bigger budget and a few more engineers, and directly controls the hardware.
GrapheneOS exists to greatly improve the privacy and security of an existing open source OS project. Android Open Source Project has good privacy and security as a starting point.
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.
The ability to sandbox Google Play Services (if you need it, but realistically, you probably do) and to simply not assign it more permissions than it absolutely needs is awesome. I run it with very restricted permissions, where it by default requests every single permission it can. In stock Android, it has all those, and you can't limit it. Just that is worth it for me.
If you actually degoogle, supposedly battery life is better but if you start adding back in sandboxed play services, you lose some of the gains.
It will depend on your banks/services. If those apps strictly implement Play Integrity API, you won't be able to use them on Graphene OS
Makes me sad, because I can't make the jump until I know my banking and related essential apps will work.
See https://privsec.dev/posts/android/banking-applications-compa... for banking apps. Anything that's not a banking or government app is extremely likely to work. Very few other apps ban using a non-Google-certified OS and that's the only significant reason for incompatibilities. GrapheneOS has a per-app exploit protection compatibility mode to work around memory corruption bugs caught by the features. It's in the process of overhauling the secure spawning feature to avoid tripping rare anti-tampering measures in certain banking apps. Play Integrity is increasingly the only compatibility issue. Some apps using Play Integrity have explicitly permitted GrapheneOS though.
In terms of apps, I fully believe it will only get worse from here: Google’s trajectory has been pretty hostile, and third‑party developers tend to follow it.
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.
I had the same idea in mind, would you mind sharing how you do it? I also use 2 phones, GrapheneOS as my daily, another phone at home just with banking stuff and some other crappy apps.
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!
Sure, will do a small write-up about my setup in a few hours.
Interesting, please post a link
Looking forward to it.
Me too.
I refuse to ever use a banking app on my phone, so I don't even know if my bank's app would work. But every other app I've tried to use works just fine on GraphineOS.
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?
Might be worth switching banks
[dead]
Does it means that any device that supports android 17 will support graphene as well?
No, only devices meeting the hardware requirements will be supported and it's a lot of manual work per device for them to support a device.
Reqs: https://grapheneos.org/faq#future-devices
Currently that means modern pixels and the next generation Motorola flagships once they come out.
Been waiting for this for so long. Huge respect to the team for pulling this off.
GrapheneOS is fantastic
If you'd like to donate to the project, you can do so here: https://grapheneos.org/donate
A pity that GrapheneOS works only on Pixel and those phones are trash for me (no microsd support). I have a 1.5 tb microsd card with all media/books and it is easy to move to another phone by just swapping the microsd card so this is one of the most important features for me.
Do you not encrypt the microSD card?
Well, for some reason Pixel 9 series and also 10 pro is excluded?
<https://news.ycombinator.com/item?id=48563154>
ehh I'd happily pay to get Graphene on my Wacom Movinkpad Pro 14...
It does not support the requirements so no amount of money could get it running on that specific device. You'd need a completely different device.
Requirements: https://grapheneos.org/faq#future-devices
permanent reminder that graphene and all other "alternatives to android" depend on extracted binary blobs. tons of them. which is the reason new (kernel) versions are such a chore/achievement.
The kernel drivers are fully open source and moving to new kernel branches is a standard part of the update process. Pixels are currently moving from 6.1 and 6.6 to 6.12 with Android 17 QPR2. This is part of the hardware requirements for GrapheneOS listed here:
https://grapheneos.org/faq#future-devices
Are you saying that GraphebneOS running on Google Pixels has no proprietary blobs apart from the firmware?
No, but all of the kernel drivers are open source and always were. The closed source userspace libraries such as the Mali GPU library aren't a barrier to porting to a new kernel version which is what was said above. We could move to 6.12 ourselves but we choose to wait for them for much broader testing which is happening with Android 17 QPR2.
Is there a list of the drivers and closed libraries somewhere?
The kernel drivers are all published in the GrapheneOS kernel repositories. A subset of the libraries/services in the vendor partition used with those drivers are closed source.
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.
sigh. always this reply. go look at all the binary blobs in the source tree. you won't get modem, video out, touch, etc etc etc working without extracting eom drivers as binary.
also, there's ZERO mentions of drivers or binary blobs on that link!
[flagged]
I had been using LineageOS + microG for many years on my Pixel 3. I upgraded to a Pixel 8 and tried out GrapheneOS and the install experience was good, but I found some odd performance quirks - apps would be slow to install and run, downloads were slow, etc. Has anyone had similar issues?
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.
>but I found some odd performance quirks - apps would be slow to install and run, downloads were slow, etc. Has anyone had similar issues?
not sure about downloads specifically, but app installs are slow because grapheneos forces AOT compilation (JIT is disabled), presumably for security reasons.
Ah that makes sense, thanks!
A lot of developers are lured into building in a dependency on Google services, so yes you'll need microG or, as GrapheneOS prefers, the original Google code running on your device for those apps to function. Or patch the app, like Langis does for Signal (not necessary for it to function without Google in this case, but it removes its calling out to Google's apps and services for those who don't want that). If you're happy with that setup and don't need protect-from-the-government levels of security (street thugs aren't going to ransomware your device by abusing an unlocked bootloader or send exploit chains that work on anything but the hardened allocator), LineageOS is probably the better choice for you. GrapheneOS has some nice things like easily denying the network permission for an app (even if they could theoretically work around it with intents) and having a custom A-GNSS server, but you can do the same on LineageOS by using root and something like AFWall+ for the network and configuring Graphene's A-GNSS (SUPL) proxy in the system settings (don't forget to donate if you use it and are able)
GrapheneOS is designed for everyone, including average users. It does not require a high threat model, and the features it provides are not only useful to people with high threat models.
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.
> Contrary to popular belief
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
You cant respond to any opinion because I have not provided any. Security is objective. What security someone may need can vary, yes, but that does not change how the security of a device works. You are downplaying serious issues and claiming features that nearly everyone benefits from are unnecessary.
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.
>but you can do the same on LineageOS by using root and something like AFWall+ for the network
lineageos has built-in firewall for years now. no need for afwall.
[flagged]
[dead]
[flagged]
[dead]
[dead]
Since grapheneOS only supports latest Google pixel phones, I tried installing LineageOS on my Mi11. Sadly, if you own a Xiaomi, you can’t just install another os. You need to unlock the bootloader and Xiomi limits you with a global quota of daily unlocked phones, you basically need to enter at midnight and hope. This is a complete nonsense, we have zero governance on our devices after paying them so much.
[flagged]
[flagged]
[flagged]
Any examples?
Here's an example of what they're responding to with inaccurate personal attacks:
https://grapheneos.social/@GrapheneOS/116353973732143171
GrapheneOS posts factual information debunking inaccurate claims from groups attacking it. Some of those groups react to their misleading claims being addressed with personal attacks. Threads about GrapheneOS on Hacker News usually have multiple posts with personal attacks towards our team from people influenced by those groups.
[flagged]
> GrapheneOS is security before anything else.
GrapheneOS is a privacy project highly focused on usability and compatibility. Privacy depends on security so it has to put a lot of work into security too and it has always been a major focus, but it's a misconception that it's all about security.
> This means they strongly advice against using other software many in their core audience are predisposed to like: Firefox, Signal, plugins for browsers, F-Droid, ect.
GrapheneOS doesn't recommend against Signal but rather it's the main recommendation for end-to-end encrypted chat from the project including via the Molly fork of Signal.
> The explanations are usually quite... blunt, and they're not exactly open for discussion (which makes sense, from a pure security perspective, those apps are indefensible).
This isn't true. GrapheneOS provides nuanced information with detailed explanations for these topics.
So I still need to buy a Google phone to get it? No thank you.
To get a sense of the project and its goals I recommend reading this post[1].
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
> Buying a used Pixel is economical, environmental, and likely doesn't support Google
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.
> What do you think are reasons for google to run Pixel then?
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.
Pixels used to be a reference devices for AOSP. Maybe they're proving that ultimately they have the skill and capabilities to provide good solutions?
[flagged]
> The Pixel was never sold in my country
Okay, see, that's an important thing to add to your original post. Saves everyone a lot of time.
If they don't sell them in your country, it's not "no thank you" as you said, it's "this doesn't apply to me".
I don't see how it's relevant. I couldn't possibly have made it any more clear I would not buy a Google device, new or used, because I don't like Google.
I am not sure why you even consider an android based OS then.
Because AOSP is open source and can be built without Google Play running at the background unlike the other alternative: giving up privacy to yet another big tech Apple.
Graphene adds many privacy features on top of regular AOSP. But it only works on phones that has good security features that are not woefully outdated or completely closed-off. Google has complete control over Pixel supply chain and they can make their phones with all bells and whistles for their ends and they behave a bit benevolently and expose the interfaces to the user too.
Most Android phones use Qualcomm which doesn't give a flying fuck about giving control or privacy to the users.
Opensource or not if someone says they hate so much google they do not want to touch a google device with a 10ft pole even if they didn't gave money or personal data to google to access it, I don't see how that person can accept running code from them.
Because average people are not just zealot crazies. Compromises and spectrums exist.
AOSP is still the best Linux-based environment for consumer use case from many aspects. It handles hardware better than GNU-based desktops, it is more secure, it supports things like HiDPI screens better and it has a stable API to write applications against and many people and organizations did so (you can still use Android 4 apps).
AOSP has strong Google influence but it is possible to use it without feeding data to Google.
Perhaps you may be interested in GNU/Linux phones, which do not rely on Google in any way.
I have bad news; Do you know who is a major contributor to the Linux kernel? (It's Google)
And many libraries in GNU/Linux desktops too..
They do not decide on the future directions of the development. It's a distributed process with many actors.
That's a value judgement, and it's a fair one. It does throw an additional constraint in the works though.
FWIW, I've been looking at the mobile / portable computing space fairly intensively for a month or so. I share your quite dim view of Google.
GrapheneOS does seem to be one of the most attractive Android alternatives.
There are also Lineage (based on CyanogenMod), AOSP, KaiOS (based on AOSP, via Firefox OS), LightOS (by Lightphone, AOSP), AphyOS (used by Punkt. mp03, also based on AOSP). These tend to be minimal, used on feature phones / dumbphones / minimalist phones. And there are /e/OS and iodéOS.
Among Linux-based non-Android options are Sailfish OS (Jolla), Ubuntu Touch (Ubuntu), PineOS (Pinephone), and PureOS (Purism), Tizen, Mobian (based on Debian), postMarketOS (based on Alpine Linux). These tend to be maximalist, offering a fuller experience than Android, with support for native Linux applications and configurations.
There are some non-Linux OSes, of which I'm aware of System 30+ (a/k/a S30+, Nokia), OpenHarmony (by Huawei), and ... something described as "realtime OS" or "RTOS" which actually had a name, for a Japanese flip phone, but which has slipped my mind (probably something reviewed by Jose Briones on his YouTube channel).
And of course there's iOS.
Briones by the way is an absolutely excellent resource: <https://josebriones.org/>. He's also one of the mods of /r/dumbphones at Reddit.
There are trade-offs, and what you choose depends on what you value, in the marketplace, in capabilities, in your own peace of mind.
If you want a full-featured device with wide acceptance, few limitations, and want nothing to do with Google, look at iOS devices.
If you want (nearly) full Android capabilities, but without Google's prying eyes and ears, GrapheneOS or LineageOS are probably your best bets. Whilst Graphene currently only works on Google Pixel devices, there's been a partnership announced with Motorola, there may be others in future (my speculation, with no other basis). And ironic as it seems, Graphene + Pixel actually does get you further from Google in many ways, though I still understand your position.
If you want full freedom / maximal privacy, and are prepared to make compromises on capabilities and battery life, look at one of the Linux-based, non-Android options. I've heard of quite a few bugs with these.
If you're looking for specific hardware capabilities (e-ink, folding / candybar, keyboard (T-9, qwerty, ...), small, large, tablet, headphone jack, etc., etc., or specific software capabilities, you're going to further refine your search. (Briones has a Dumbphone Finder at his website which does this pretty well.)
If you want modularity or repairability, there are devices such as Fairphone or Keyphone with (some) replaceable components.
If you want minimalism, look at an AOSP-based device, or perhaps S30+. These will give you feature phones capable of calls, texts, and a few apps, but not much else. For more complete computing you'll need either a desktop or a laptop.
There are more extreme options. I'm considering, for example, whether or not a roving SIP WiFi-only phone might be an option, and if so, what would be necessary to make that work. It would rely on a WiFi network provider (public or non-public network, or a cellular modem), and wouldn't function everywhere but should function in many locations sufficiently to be useful.
Most non-smartphone options I've looked at, and in particular the usual "dumbphone" suspects (Light Phone, Punkt.) tend to run an AOSP-based OS, with Nokia being the principle exception.
Briones FWIW uses the Light Phone III as his daily driver. That's somewhat spendy, and quite minimal, but he has his reasons, discussed at length at his blog and YT channel.
I'm leaning fairly strongly toward an option now, though my main hesitation is that KaiOS devices have very limited phone/SMS spam and/or traffic management. I'd prefer known-contacts-only could reach the device, that doesn't seem to be possible (KaiOS has only specific-caller blocking, and apparently a limited API for enabling more robust phone blocking). On the flipside, the device can be powered off, and/or battery removed.... I'm also looking at some VOIP/SIP options.
This probably falls under "capabilities", but another consideration worth strong consideration is mobile network support. With the past phase-outs of 2G/GSM, ongoing 3G phase out, converstion to LTE and VoLTE, and expansion of 5G networks, as well as differing network and frequency standards around the world, finding a device which will work with your preferred mobile provider(s) is a challenge.
This is one of my strikes against the Punkt mp02: it doesn't work with most of my carrier options. I was hoping that either that device's capabilities would be extended, or its replacement would follow a similar ethic and expand bandwidth / protocols, but neither occurred. Further reading on Punkt's offerings has further cooled my interest (bugs, fragile HW, spendy).
RCS and group chat support seems to be another sticker, though with a small-form-factor laptop or tablet you should be able to work around that.
The other sticker for me (mentioned in my original post) is voice/SMS/messaging filtering options. The increase in spam / unsolicited contacts across the comms spectrum is immensely frustrating, and few devices / OSs / apps really address the situation adequately and in a privacy-respecting manner. That's still giving me a lot of hesitency on what really ought not to be this complex a decision, though for now I'm thinking it's a good thing to spend the time.
If you want full freedom / maximal privacy, and are prepared to make compromises on capabilities and battery life, look at one of the Linux-based, non-Android options. I've heard of quite a few bugs with these.
Most of them also have really bad security, for various reasons, including:
- Since virtually no hardware vendor (outside Jolla) supports non-Android phones, they typically use phones that were made by their ODMs as Android phones and rely on kernel/firmware/device trees made available for those Android builds. Sadly, nobody outside Google (PixelOS) and Samsung really cares about giving their kernels and firmware timely updates. So usually the kernel and firmware are full of known holes (Qualcomm and others do monthly bulletins).
- For many reasons, Linux systems have never really focused on proper security isolation and sandboxing. So most of these phones have really poor isolation and you are only one browser/image parsing/... vulnerability away from full phone compromise.
- Unlocked bootloaders or otherwise compromised boot chain. So, it's easy for persistent malware to compromise a phone and there is no way to attest that the system runs unmodified binaries (as you can e.g. can with GrapheneOS' auditor or Android phones with fully verified boot and Strongbox).
Let's say, if I was a bank, I can understand why I would want to block such devices.
> Let's say, if I was a bank, I can understand why I would want to block such devices.
So as a bank, you would be forcing your customers into the duopoly of the American megacorps. Thankfully, there are banks that do not do this.
Nice strawmanning!
Obviously I want banks to support alternatives, but I can understand if they only want to support secure OSes. Some banks support GrapheneOS remote attestation besides Google Play Integrity at the strong level.
By your reasoning, 99.9% of people use awfully insecure OSes on desktop and servers. And yet, the world hasn't collapsed. My bank account is not hacked regularly, too (actually, not at all).
This is a personal anecdote and you are making up an absurd conclusion. No one said things would collapse. Security can be evaluated objectively, and the better the security, leads to fewer instances of exploitation. I'm certain the actual data around InfoSec would support that idea.
My point was about the word "awful", or, as many GrapheneOS supporters say here, "atrocious" security. This is definitely an overstatement.
Otherwise, you're not wrong.
Among other mobile OSes I've run across: CloudOS and ThreadX, the latter used on some AGM models. Proprietary, non-Linux/non-Android.
> Wake me up.
Motorola announced it on 2nd of March 2026.
Motorola is not mentioned in any of the links.
https://news.ycombinator.com/item?id=47214645
third link
It makes sense that an open source project would focus on one series of phones since their time and resources are limited.
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 Pixel 9 had a vastly improved modem and the 10 switched to TSMC for their Tensor SoC, resulting in better performance and better battery life/less heat.
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?
> The Pixel 8 Pro has hardware WiFi problems, the 9 and 10 are both minor updates
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)
Only silver lining to this is they run a lot of discounts and promotions on them, and it's possible to buy them at a significant discount. Got my first Pixel 10 on a very cheap contract with trade-in promos on top, and got a second Pixel 10 at a 70% discount from the RRP.
It's not possible to buy them at all where I live, even if I wanted to funnel money to Google - which I do not. I have gone to great lengths to de-Google my life.
Ebay? A friend to ship it? I agree on the de-google part but putting graphene on a used pixel is aligned!
Absolutely, and it is irrational to refuse to buy hardware from Google (which, with Graphene, is under your control) when the alternative is to either run a Google OS on a third party phone (and give up control of the software), or Apple (equally bad), or some impractical and less secure alternative like a Linux phone incompatible with Android apps.
Agreed. I dislike most of Google's products, but their Pixels have secure hardware and are very open (compared to other modern smartphones). In short - a good product for people wanting to run free software on modern-ish smartphones. If a product is good, why not buy it?
Soon, there will be compatible Motorola phones.
Watch out in the US though, apparently some carriers disable OEM Unlocking (so you cannot unlock your bootloader).
If you buy used, you save a bundle and google gets no money from you.
I still don't want a pixel, so I went with a used ebay phone and installed lineageos.
They have no choice at the moment, this is the ONLY hardware secure enough to even make effort in hardening the OS.
Everything else is meh, bad, or atrocious.
Next year we'll have Motorola flagship(s) to choose from. Can't wait.
I have tried ubuntu on mobile only once and never come back, because it had very bad and poor experience compared to native experience of that mobile. On which models this system works the best?
GrapheneOS is highly usable and compatible with nearly all Android apps. It has a similar experience to a mainstream Android OS if you choose to set it up that way such as using sandboxed Google Play in the main profile (which does not ruin what it provides at all, it's a perfectly valid setup). The purpose of GrapheneOS is to provide far better privacy and security than the Android Open Source Project (AOSP). AOSP is a lot more private and secure than a traditional desktop OS including one ported to mobile.
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.