Posted by to3k 14 hours ago
Building fintech apps, we integrated Play Integrity as a fraud signal. Sandboxed Play Services on GrapheneOS actually passes most of these checks now, and false positive rates for legitimate users are negligible. The hardliners who refuse sandboxed Play can still use most banking apps that fall back to basic root detection rather than hardware attestation.
The real gap is NFC payments - Google Pay needs privileged hardware access that sandboxed apps cannot get. But that is one use case, not a reason to skip GrapheneOS entirely. Curve works fine in EU.
AFAICT, Garmin Pay works like Apple Pay, meaning (unlike Google Pay) no network connection is required.
What most people miss: the real value of GrapheneOS is not just escaping Google surveillance but the per-app network and sensor permission toggles. Being able to cut network access to apps that have no business phoning home changes how you think about every install. That alone is worth the switch.
However, there was one case that lead me to thinking about ditching grapheneos to this day. I installed Uber on my phone and I was able to successfully create an account and use it. When it came to booking a ride, the app crashed and I had to log in again. Once I did that, I was told that my account has been suspended for violating the terms of services. All I did to that point was creating an account and booking a ride. I was able to resolve the issue luckily after a few days and going back and fourth a couple of times with the Uber support, however, the risk of getting banned on any such platform is still risky, and thus I'm not sure if grapheneos is usable if you need to use such services.
I've run into my share of scammy taxi drivers.
Taxi across the town is £20, Uber usually 5-10. There are no other providers.
Taxi from my airport (some 15 miles away) is £60-80, Uber usually £30-ish. Public transportation (2 trains + 2 buses) over £50.
I wish I had an option.
Your aim is misplaced: ditch Uber, not GrapheneOS.
Every app on my phone has at least one other app, usually already installed, that can replace it. This wasn't intentional, it just happened naturally. Unless all two or three apps in a category get blocked for me at the same time, this already unlikely situation is barely an inconvenience.
If using GrapheneOS significantly increases the risk a person won't be able to use a service they rely on, that may be unacceptable.
I'm not doing this on purpose, I just now scrolled through my app list looking for one app that would actually fuck me up if I lost it in an instant. There are none. And I'm not currently even running graphene or anything else, just a stock Samsung.
The good news is that they are actively working on developing their own hardware. The bad news is that it’s been delayed. But I’m watching closely.
https://www.galaxus.at/en/page/grapheneos-postpones-pixel-al...
Google would not allow this and they're way too entangled with Samsung.
That limitation might be doing you a favor, as these things go...
Even if Pixels hadn't PWM a larger screen (or, dare I say, a book) will be an improvement for longer reading sessions.
In the meantime, I use a Motorola G Power 2024 which has IPS. I'm very much a non-expert but made a minor hobby out of trying to de-google it as much as possible.
Never signed into Google with it. Using NetGuard with a whitelist to prevent most of the phoning home. Uninstalled or disabled most built-in apps. The apps I use are installed via either Obtanium or Fdroid. Have Dropbox from Aurora. Use Motorola's private space for keeping some data and apps in a separate, supposedly secure locker.
I'm sure this doesn't come close to GrapheneOS's security level but it's the best I can do within the limitations of this device. It was a fun mini-project. NetGuard is invaluable for this purpose. Almost feels like the phone is truly mine.
The problem with nearly every other phone, except maybe Samsung flagships, is that they don't fulfill the security requirements. And Samsung is hostile against unlocking (even when it was still possible, it would burn a Knox eFuse).
I also with they could support non-Google phones, but that's a problem coming from the manufacturers, not from GrapheneOS.
My understanding is that there are close to half a million GrapheneOS users. And many potential users don't want to buy a Google phone. So it feels like it is starting to become worth considering for manufacturers...
I don't get why Fairphone doesn't look into that. Is it because they are not aware, or is it too hard for them to make hardware that is compliant with what GrapheneOS requires? Hundreds of thousands of devices may not count so much for Samsung, but they must definitely count for Fairphone.
What is "its alternative"?
> I also wish they could support non-Google phones, but that's a problem coming from the manufacturers, not from GrapheneOS.
The manufacturers aren't blocking the installing of GrapheneOS...
I meant alternativeS, sorry. Well, anything AOSP-based that is not Android.
> The manufacturers aren't blocking the installing of GrapheneOS...
Of course they are not. But they produce hardware that is not secure enough for GrapheneOS to consider. I wish they saw value in GrapheneOS and produced hardware that met their requirements.
It's actually weird, because I'm convinced that it's completely worth it: just add those requirements to the design of one new model, and a potential of hundreds of thousands of people may buy it just for GrapheneOS.
The OS makers don't have to go out of their way to support a device they don't want to (that's the beauty of open source passion projects), but it's also not like any manufacturer (that allows bootloader unlocking or ships an unlocked bootloader) is blocking GrapheneOS or anyone else from doing it, which the quote implies in my reading (maybe other people read it differently)
I agree, but you are the one who talked about "blocking". I did not :-).
The requirements are indeed minimal. I have no problem with your valuing independence from Google, but please don't misrepresent GrapheneOS' requirements as the highest degree of security because not even they have said that. They have actually mentioned wanting to be more involved in the hardware/firmware side to implement more pro-user changes.
They are mostly basic requirements that Android OEMs should be embarrassed not to meet in 2026.
I don't get your logic. Requirements are a choice. It's very easy to create requirements that exclude every device but one.
Example: "It has to be the Samsung Galaxy S23". Done.
Now you can disagree with those requirements, but that's completely different from saying that the requirements are wrong.
Again, requirements are not laws of physics. As the author of a project, I am free to make up my own requirements, and when something doesn't meet them, then I am free to reject it because it does not meet my requirements...
If you go to a bank and they refuse to lend you money because you don't meet their requirement, you will have a hard time convincing them that their requirement are wrong and that they should instead replace it with yours :-).
Why are GrapheneOS releases dependant on Google releases?
I'm not even really sure what you mean by "manufacturer updates".
The more I hear about this project, the less is sounds like an alternative OS and more it sounds like a thin skin around whatever shit Google throws out, to be honest.
I have trouble understanding why this is different on mobile devices. People keep speaking of blobs but that doesn't seem to be a thing in laptop/desktop hardware, unless they mean something like the firmware running on your wifi card and uefi chip? But those can be interfaced with from any kernel version, afaik, so I don't get it
That's a dependency: if you want your system to be secure, you depend on the software running on your system to be patched when a security flaw is published.
The attack vectors against this firmware are virtually always physical right? As in, hardware access in one way or another (including radio waves reaching the device), not something that can be routed over a (cell) network
If you have an EOL Pixel and a new major version of Android is released, Google will not port this new version of Android (and therefore AOSP) to it. So GrapheneOS would have to do it. GrapheneOS just say they don't have the resources to do that, so they follow the Google releases. Could you keep an EOL Pixel without receiving updates? Sure. But then it's not supported anymore, it's just outdated, insecure software.
> I'm not even really sure what you mean by "manufacturer updates".
There are the AOSP updates (which bring new features, but importantly in our case bring security fixes) that come from Google, but your phone is more than that. There is a bunch of hardware running in your phone and a bunch of firmwares exposing it. Say your camera, or your wifi module, etc. If there is a security issue in the firmware of the camera, then it won't be fixed in the AOSP codebase. You need the camera manufacturer to fix it and release a firmware, pass it to the phone manufacturer who will then deploy it on your phone.
Google split both of those concepts years ago in order to deploy Android updates faster and make everybody more secure, because manufacturers had a tendency to lag a lot. Some still do but the situation generally improved, I think. Anyway, you need to receive those security updates from your manufacturer because they are independent from Google.
> the less is sounds like an alternative OS and more it sounds like a thin skin around whatever shit Google throws out, to be honest.
If you think that AOSP is shit, then sure. I mean, if you think that the Linux kernel is shit, maybe you don't want to run a Linux distribution.
I personally think that AOSP is pretty great, and vastly superior to Linux on mobile (among other because it has a much better security model). I am not a big fan of Google being root on my phone (with Android and system apps like Play Services), which is something that GrapheneOS fixes (by making Play Services run like any other, unprivileged app). GrapheneOS is also adding privacy features, be it by proxying your location requests (so that they go through the GrapheneOS servers instead of directly to Google) or by adding features like "scopes", where you can choose exactly which contact you share with an app, for instance, or refuse Internet access to an app without breaking it (GrapheneOS will just make the app believe that it has the permission to access the internet but there is just no connection right now). And of course GrapheneOS hardens the system in terms of security (e.g. with a hardened malloc or memory tagging stuff that Apple recently introduced as well).
So yeah, it is relatively thin, because AOSP is a huge codebase. But it doesn't mean that it's worthless: this skin makes it more secure, more private, and for me more enjoyable than Android.
I think breaking away from open source Google code is not really meaningful. It's kinda like saying "I don't want to run Linux because it contains code from IBM/Google/Meta". AOSP is a great and useful project. If the day that Google stops releasing AOSP ever comes, a consortium of interested organizations can fork it. But it does not make a whole lot of sense to start a new mobile ecosystem completely from scratch, if one that is great and open source already exists and buys you compatibility with millions of apps.
I'm not a mobile phone security expert but my feeling is that in the case of GrapheneOS - which target is probably high-profile people at risk of state actors et similia attacks - a zero-day in the closed source firmware from Qualcomm will probably screw you anyway.
I understand that you are anyway reducing the attack surface (now they need to target the modem firmware specifically), I understand the concept of security in depth and I also understand that by using GrapheneOS you are already placing mitigations for many other known and unknown attack vectors. But still...
All the devices that GrapheneOS supports implement a clear separation of the baseband and the CPU in the form of SMMU, ARMs version of IOMMU. So a zero-day in the baseband does not immediately screw you - unless the code on the CPU side also contains vulnerabilities or there is a major flaw in the SMMU implementation that somehow breaks isolation.
I probably explained myself in a shitty manner, I didn't try to downplay GrapheneOS efforts, and I should have kept my initial statement about "next best thing can create a false sense of completeness" as a generic remark and not specific to GrapheneOS, for which I don't have enough knowledge to know if it applies or not.
What that means is they can push malicious settings and configurations (Definitely) and probably malicious firmware to the handset at will. They don't need to code this, they buy the software packages from the usual suspects. Adversary simply needs to put a drt box or a hailstorm or what-not close enough to the handset to do the work.
The baseband can do a lot, it has dma (if I recall correctly) and can almost certainly screen look, and extract information from some but not all base bands. This varies.
GrapheneOS cannot really influence this, but hardened_malloc could conceivably help. What would be great is a bench firmware re-flash, but I don't want to do this every single day.
There's an IOMMU:
> Is the baseband isolated? > Yes, the baseband is isolated on all of the officially supported devices. Memory access is partitioned by the IOMMU and limited to internal memory and memory shared by the driver implementations. [...]
https://grapheneos.org/faq#baseband-isolation
> GrapheneOS cannot really influence this, but hardened_malloc could conceivably help.
They can and do, see above. But I don't see how hardened_malloc is related to the baseband doing DMA.
To answer your question, I thought it might just be slightly harder to extract secrets or exploit a running process directly. Thats all I was saying.
I do this on iOS I’m sure it’s do-able on GrapheneOS and hopefully on Android too.
Essentially, 5G is sort of a lie. Phones spend a lot of time exchanging information via 4g/lte, and just like 2g/3g and 3g/4g, there are simply downgrades that can be performed in the field, without getting too far into the weeds.
5G matters not for this.
And it's not only security - simple stuff like USB data off unless the phone is unlocked, native call recording, much enhanced user profiles (to separate data mining apps like Uber or Instagram from your financial affairs), etc.
And yes, it's about reducing the attack vector. On most other handsets you'll get most of the fixes 6 months or a year later. At best.
I do understand your point that people at risk of state level attacks might get a false surface level appearance of defence from this. But then anyone who's a target of state level attacks and is making OS decisions based on a surface level understanding of the tech is not going to have a good time anyway.
How about Pinephone with its partially freed baseband OS [0] or Librem 5 with its removable modem [1]?
Many people here might recoil at this: to go through the trouble of de-Googling your phone and then just install Google Play services and the Play Store, but the important part is that it is a choice they could make.
Pixels are arguably the best option for software choice among mainstream phones (and iPhones are the worst), but both are a huge regression of choice compared to traditional personal computing platforms.
That said, I do not like how much the project depends on Google.
- GrapheneOS is based on Android, which is solely developed by Google.
- GrapheneOS only supports Google Pixel devices. Thankfully, they are working on partnering with a different manufacturer, but details are still very limited.
- They recommend using the Google Play Store (requires a Google account) to get apps and recommend against using F-Droid.
- Their Vanadium web browser is based on Chromium, which is controlled by Google. It also does not have an ad blocker or support extensions. They recommend against using Firefox. Firefox, and Safari to a more limited extent, are the only web browsers keeping Google from having complete control over web standards and the way we can access the internet.
This is not a criticism of the GrapheneOS project or developers. I understand that security is the biggest priority of GrapheneOS and I understand that Google is often good at security. They are following the goals of the project. It is more directed towards the GrapheneOS community that often blindly recommends GrapheneOS as the only option and treats any alternative as inferior and not to be considered. Most users do not need security at all costs. Especially among the free and open source enthusiast community, freedom and user control are often prioritized. There should be more awareness and discussion about what the user wants and whether that actually aligns with the security-first goals of GrapheneOS.
It does have a network-level ad blocker. What it doesn't have is a blocker which modifies/injects Javascript into pages, which iiuc is the main reason that the blocker doesn't help with ads on YouTube much, or pages which employ similar techniques.
> They recommend against using Firefox.
To clarify: they recommend against Firefox Mobile because it didn't support site isolation until last month's v147 updates. I don't know if the goalpost has moved since, but in any case: there's nothing on Graphene that would prevent you from using Firefox.
The complete lack of content and site sandboxing on Firefox for Android is only one of the reasons we recommend against it. It has major security deficiencies beyond this and cannot benefit from many of the hardware and OS protections due to it. Vanadium is much more secure than standard Chromium while Firefox is much less secure than it, so there's quite a stark difference between them.
Recommending against using Firefox and F-Droid due to major security deficiencies doesn't in any way reduce user choice as the post above portrays it. Having a lot of accurate information provided by GrapheneOS enables our users to make more well informed decisions. We also do not specifically recommend the Play Store as the post says above but rather we provide nuanced information about the available choices. Specifically for obtaining apps from the Play Store which aren't available directly from the developers, we recommend using the sandboxed Play Store for users who using sandboxed Google Play in a profile for app compatibility already. Play Store itself has signature verification while Aurora Store only has TLS with a smaller set of trusted CAs by default similar to many Google apps. Aurora Store is sometimes needed to work around app's filtering who can install it so we do recommend it for that specific purpose. Aurora Store still logs into a Play Store account and making a throwaway account to use the Play Store app doesn't reduce privacy compared to using sandboxed Google Play without one.
GrapheneOS is based on the Android Open Source Project. It's incorrect to say it's solely developed by Google and it's open source software which we're free to change as we see fit.
> GrapheneOS only supports Google Pixel devices. Thankfully, they are working on partnering with a different manufacturer, but details are still very limited.
No, we already have a partnership with a major Android OEM. It's not something we're working on obtaining and we've provided a fair bit of details including that it will be publicly announced by the OEM in March, that the devices will launch in 2027 and that they'll use a high end Snapdragon SoC which is either the flagship (most likely) or one step below it.
> They recommend using the Google Play Store
No, that's not our recommendation.
> recommend against using F-Droid
We recommend against F-Droid due to it being an unnecessary middleman between users and app developers which does not truly reduce trust the app developers. F-Droid apps are consistently out-of-date and often lag months being on important privacy and security fixes. F-Droid consistently makes problematic undocumented changes to apps including rolling back dependency updates. F-Droid is known to use highly outdated build infrastructure which is very poorly secured. They have a bunch of bad security practices throughout their approach and have made it clear it isn't a priority for them. They've repeatedly said they don't believe app sandboxing is useful and much more than that. Many open source apps including Signal and WireGuard have asked to have their apps omitted from F-Droid due to the security and trustworthiness issues with the project. That's not at all something specific to GrapheneOS.
> Their Vanadium web browser is based on Chromium, which is controlled by Google.
Chromium is an open source project which is collaboratively worked on by multiple projects using it as the basis for their browsers. That includes Microsoft who implemented the WebAssembly interpreter available in the upstream Chromium codebase which is used by Vanadium but is dead code in Chrome and regular Chromium builds since it was added for Edge.
> It also does not have an ad blocker
No, that's not true. Vanadium has a default enabled ad blocker which uses EasyList, EasyPrivacy, EasyList's Adblock Warning Removal List and also selectively activates a whole bunch of EasyList affiliated language/regional lists based on the currently active languages. This approach avoids adblocking being used for fingerprinting, avoids greatly weakening site isolation sandboxing as extensions do and is much higher performance which is important on mobile. It very clearly has ad blocking and a per-site toggle for it.
> or support extensions
Extensions greatly weaken site isolation and give third party code without verified boot extensive access to website content similar to dangerous Android accessibility service apps. Very few extensions are focused on privacy and security in a similar way to GrapheneOS and would compromise what we're trying to build. It's not the approach we want to use in Vanadium. If you want to use extensions then you can use a browser with them but it doesn't fit into what we're building with Vanadium where we want to implement features ourselves in a very private, secure and robust way which cannot be done with extensions. Extensions fundamentally reduce security including because they used a shared process across all isolated websites which inherently reduces isolation. Few extensions take this seriously, even the ones focused on privacy. They commonly add leaks between sites. There are plenty of other browsers available but ours is aiming for a standard of privacy and security which cannot be achieved with extensions.
> They recommend against using Firefox.
Firefox's Android app has atrocious privacy and security. A browser without even basic content sandboxing let alone sandboxing with full site isolation. That's combined with major other major security deficiencies and it isn't something we could recommend using. Recommending against it doesn't mean people can't use it...
You'll still be using Vanadium as the web content engine within apps using the WebView such as email clients rendering HTML email and many more. Many people have a misunderstanding of what the WebView is and confuse it with custom tabs which are provided by the user's selected default browser rather than the WebView used within other apps.
> This is not a criticism of the GrapheneOS project or developers.
How isn't it criticism of GrapheneOS? Regardless, Vanadium does have an adblocker and we don't specifically recommend the Play Store as you said. The biggest issue is that what you're saying about what we prioritize, advise or provide isn't accurate.
> I understand that security is the biggest priority of GrapheneOS
Privacy is the biggest priority of GrapheneOS and privacy depends on security. GrapheneOS is a privacy project.
> It is more directed towards the GrapheneOS community that often blindly recommends GrapheneOS as the only option and treats any alternative as inferior and not to be considered.
Our project and community regularly recommends iOS as an alternative which provides far better privacy and security than non-GrapheneOS options. Most other options have very poor privacy/security including lacking even basic privacy/security patches and protections. Similarly, our project and community regularly recommends using macOS for better privacy and security than either Windows or desktop Linux. What you're saying are blind recommendations are anything but that but rather very well informed information provided by the GrapheneOS project.
> Most users do not need security at all costs.
GrapheneOS is not about security at all costs and this misconception which regularly comes up that it's about security rather than privacy is completely wrong. Many projects failing to provide decent privacy treat it as if privacy is solely about which apps/services are bundled rather than needing to provide privacy patches, privacy protections and solid security to protect that from being bypassed. Much of what GrapheneOS provides are privacy features such as Contact Scopes, Storage Scopes and the Sensors/Network toggles along with much more. The security protections it provides exist to protect privacy. Why else would the security protections be there other than to protect privacy? It's not a separate thing from privacy but rather is a huge part of providing it. There's no other reason for us to work on security than protecting privacy. It doesn't make sense to say we work on security instead of privacy.
Most users do need basic privacy/security updates and protections. Failing to keep up with basic updates and misleading users about it is a severe issue. There isn't any major non-GrapheneOS AOSP-based OS that's doing the bare minimum of keeping up with updates.
> Especially among the free and open source enthusiast community, freedom and user control are often prioritized. There should be more awareness and discussion about what the user wants and whether that actually aligns with the security-first goals of GrapheneOS.
You aren't accurately representing what GrapheneOS provides, our approach or our priorities. People can see for themselves from the detailed article that it provides a highly usable and compatible system with a huge amount of user choice. People can choose from a wide range of approaches based on their privacy and security goals. It doesn't impose choices on people. You treat it as if people are forced to use Vanadium when it's another choice of browser which people have on GrapheneOS but not elsewhere. GrapheneOS users have more choice among browsers and the one we have DOES provide ad blocking contrary to what you said. GrapheneOS users can use F-Droid despite us recommending against it due to the major security deficiencies. Providing well informed recommendations with detailed explanations does not in any way hinder user choice but rather informs people so they can make better choices. Our recommendations not aligning with your personal beliefs or preferences doesn't mean we're somehow reducing user choice.
Luckily I have hardware 2FA keys from my bank so I can authenticate using that. It also slightly decreases the suck-factor from whenever the phone decides to fly off down a drain. This may not be the case for you, so do your research on what you need for daily living.
Still missing Android Pay but that's due to Android Pay being closed. I wish banks would do something and support NFC payment systems that don't require the device to be controlled by Google (how can we be okay with this?!)
There are countries where it's possible to pay everywhere with the banking app scanning a QR code. No need for NFC :-).
You need the Google/Apple app though, don't you? Or can you write your own personal app that will handle that?
NFC is by far more convenient and reliable.
QR codes are reliable.
NFC (EMV) works offline.
It's pretty common here that people will be told they need to turn off an otherwise working Wifi connection when facing problems because bank apps will often just not work properly on wifi.
But as I said, even without that, the convenience level is ridiculously different. It's arguably quicker to open your wallet and use a debit card with an NFC chip than it is to use QR codes, before we even talk about the convenience of watch/phone payments using NFC.
Got it, that's a fair point!
> But as I said, even without that, the convenience level is ridiculously different. It's arguably quicker to open your wallet and use a debit card with an NFC chip than it is to use QR codes
This part sounds like those people who use a different unit system than I do and explain to me how my unit system is objectively more inconvenient than theirs. To which I answer: "I think I know better than you what is more convenient for me, given that I use it everyday" :-).
I use QR codes instead of opening my wallet, which kind of hints towards the former being more convenient than the latter for me. And for the millions of people who also do that.
I'm not saying "yours" is less convenient. I'm saying the one you and I both use regularly is less convenient than anything NFC based, which I also use semi-regularly.
> It's arguably quicker to open your wallet and use a debit card with an NFC chip than it is to use QR codes
So I assume that even though QR codes are available where you live, you use your debit card with an NFC chip because it is quicker than using QR codes...
Anyway, the important part is that NFC doesn't require an internet connection, and I had missed that. Now I wonder why a QR code couldn't work without an internet connection just the same. I'll have to look into that!
Yes, I generally use my card rather than than QR unless the shop doesn't take cards, doesn't have a paywave/etc-enabled card reader, the card reader is broken, the sales person doesn't know how to use it, or the sales person insists I give them my card and PIN to pay (none of those are hypotheticals, I've experienced all of those first hand, some of them quite repeatedly).
> Now I wonder why a QR code couldn't work without an internet connection just the same.
Because a QR code is just a short piece of information to tell your banking app who to send funds to - it's like putting a mailto: link on a website rather than asking people to re-type your email address to contact you.
The problem is not GrapheneOS, but rather that phone manufacturers other than Google don't care. Now if there were millions of GrapheneOS users, it would start becoming interesting for other phone manufacturers to care.
My point being that I buy Pixel in order to give more weight to GrapheneOS, in the hope that other manufacturers will eventually realise that.
E.g. a new Pixel 9a is currently 369 Euro in The Netherlands and 367 Euro in Germany. The Pixel 10a will be released soon, but the 9a will run GrapheneOS just fine (same SoC except modem as the vanilla 9).
In any case, for me this also sort of defeats the purpose: I'd rather break free from Google and Apple, not just (stock) Android and iOS.
https://privsec.dev/posts/android/banking-applications-compa...
Not really. On GrapheneOS, the Play Services/Play Store run as sandboxed apps, i.e. they are not system apps like on Android. They just run like a normal, unprivileged app. That's a lot better than on Android.
> I'd rather break free from Google and Apple, not just (stock) Android and iOS
If you want to break free, you don't have to install the Play Services / Play Store on GrapheneOS, just like you don't have to install microG on LineageOS. There is a misconception that microG is better than sandboxed Play, but I disagree. With microG, your apps still connect to the Google servers, so you're not "breaking free".
Moreover, some OSes (e.g. /e/OS) give certain Google apps higher privileges than other apps even with microG, install Android Auto and it's still game over. GrapheneOS does not have this issue because as you say, Google apps/services get sandboxed.
Obligatory link: https://eylenburg.github.io/android_comparison.htm
Edit: ignore this - there's a list elsewhere in this thread!
If you are using a rather popular banking app, chances are high that it has been discussed in the GrapheneOS forum.
Anyway, with google play services installed, mine have worked out of the box.
Why start from scratch?
I've been on ubports for 3 years and while it also has some weird caveats like read only rootfs, no working package manager (due to read-only fs. however ubports has pretty cool support for lxc containers where you can use apt). Due to chronic lack of time I haven't been able to sit down on my phone to play with it a bit (for example id like to install waydroid), but it seems a lot easier than android. For example, while there isn't an app for call recording, some guy worked around it by writing a systemd user service as a workaround[1]. This is exactly the type of thing I'm thinking about when talking "linux phone".
For me as a linux user, the difference if ubports was a human, I'd think that perhaps they were sick, whereas if android was a human, i'd shoot them in the face :)
Remember that GrapheneOS is not Android: it's an AOSP-based OS.
I actually had hopes that Huawei would start that with HarmonyOS.
It is finnish, anyone knows how are they going?
i used that for 2 years, it's linux+kde bottom to top, a terminal + shell is a builtin, though only supporting 5+ years old Sony phones got tiresome.
Still.. it seems the only one that's usable enough apart of the duopoly. May have to switch to it again.
You can run desktop apps on GrapheneOS including on a desktop monitor via the desktop mode with free form windows. There's support for non-native apps via hardware-based virtualization. These features are experimental but already work pretty well.
The situation with Sony Xperia devices is not great, the best experience is still on the X10III (from 2021 I think) and there are significant issues with the support of 10 IV and V generation devices (a free beta release is available for those as well).
It seems that recently there has been quite a lot of buzz in the Sailfish community compared to the past few years. In the public repos there are some interesting contributions like xdg-shell support for Lipstick, which looks set to enable compiling many previously unavailable Linux apps natively if that will actually be integrated in an upcoming OS version.