Experimental release of GrapheneOS for Pixel 9a
grapheneos.social
grapheneos.social
There's no contact info in your profile so I couldn't reach you. If you don't want to share it here, you could use the email address in my profile
But yes, as said I'd not use the same wording because it shouldn't just be a copy-paste, that's also wasting their time. I could refer to what was already submitted so they can more easily bundle them, but I understand you don't have it anymore so np. Thanks for mentioning you've submitted this in the first place and the additional info, that does motivate me to continue also submitting things and to know better what makes sense to submit :)
That sounds like a very big mistake to me. And a missed opportunity: in some countries, banked work together to develop their own systems. People can send money to each other and pay everywhere with a small app that is not BigTech from the US.
I think there should be such an app in every country; you don't want your payment system to fully depend on US companies.
I don't know anyone in Switzerland using Apple/Google Pay, which IMO is a national success.
iDeal is ubiquitous in The Netherlands for individuals sending money to each other, and for online payments. However it does not support NFC payments in physical stores. Dutch banks decided to go with Google/Apple wallet for this. I believe in the longer term Wero https://wero-wallet.eu/ (and potentially the digital euro https://www.ecb.europa.eu/euro/digital_euro/html/index.en.ht...) is supposed to take over this usecase in the EU.
Twint does that. They started trying to make it "seamless" with NFC, but couldn't do it because of Apple (maybe now with the DMA it may change) and went for some kind of weird bluetooth stuff. Nobody used it. Then they moved to QR codes, and it quickly got very popular.
Everybody understands QR codes. No need to know whether your phone supports NFC or not, no need to go check if NFC is enabled in the settings, nothing. Everybody understands that they need to scan the QR code with their camera, period. Seems perfect to me.
It already does for web purchases, so there is no reason it could not. Not sure why this is not more commonplace.
For physical transactions there's barrier of hardware and network effect - everybody has card terminal. Users expect near 100% acceptance for them to use payment method daily.
If you consider creating own NFC payment app instead of Google/Apple Pay - that's actually possible, but more expensive and often disliked by the users due to inability to easily switch between cards issued by different apps.
Is it? Last time I checked, Apple & Google were also interfacing with banks on the server side, i.e. banks had to integrate with Apple/Google specifically. I'd love to be wrong, though.
The last time I looked at it, it was not possible because Android doesn't let apps control the uid that gets used for NFC.
Either way, even if apps had full control over the chip, my understanding is that building a wallet app would still amount to much more than just interfacing with the NFC chip.
For technical side - there are companies selling complete SDKs.
While I've known that building a wallet is not as simple as configuring the NFC chip and one would have to interface with banks on the backend etc., I've failed to understand exactly why. What prevents a phone from emulating a regular physical credit card?
What it means - you cannot obtain working card profile if bank doesn't issue it to you. Therefore you need blessing from bank & card scheme to be connected to this ecosystem.
If you want to go deeper into this rabbit hole I can recommend two sources:
* https://developer.mastercard.com/product/mdes - Mastercards framework for tokenization
* https://developer.verestro.com/books/token-requestor - actual solution. It focuses on offering for single issuer, because market for Google Pay competition is pretty narrow, but technically it's mostly the same + way more red tape.
If you ever decide to try - ping me, I happen to know a few guys there :-)
> If you ever decide to try - ping me, I happen to know a few guys there :-)
Ha, I have actually been entertaining that idea for quite some time, but it seems rather difficult to penetrate that domain as an outsider. The links you shared only seem to confirm that. :-\ I'm not sure I would even want to compete with the Google/Apple Pay duopoly, for now I'd mostly just be interested in an open-source, privacy-preserving solution for contactless payments.
Anyway, you might want to add your contact info to your HN profile – just in case. ;-)
If this were possible fraudsters would be easily be able to clone people's cards by getting close to them. The protocol was explicitly designed for this to not be possible. There are secrets that live on the card itself and are not exposed
Behaving like a credit card does not mean that the credit card is clonable.
With some luck it will be even routed to your bank. Then it will fail due to invalid authentication. I think there's a defcon talk on YouTube that details the exchange.
That's not related to ability to create own app - on both ios and Android you can access NFC hardware directly (on iOS it's limited geographically), and send card data as you see fit - Google & Apple do nothing in such case.
It's even better than NFC because a small store can print their QR code on a piece of paper and not need to buy a terminal. Most stores just have the normal card terminal print the QR code and people scan it.
The TWINT app says -- if their promo videos are to be trusted -- "Scan only QR codes from trusted sources and check the receiver of the payment in the next step". That doesn't fill me with confidence :(.
A dynamic QR code could be fine -- they have their app, you're able to bootstrap what is effectively a secure channel between the PoS machine and the app to give the vendor confidence their device has received payment and the consumer confidence that they're paying the right vendor. A static QR code is more challenging, and it sounds like they're putting more weight into social protections than I'm comfortable with -- especially considering a technical solution is possible and exists.
I'm especially wary of the warning that individuals can't have QR codes. Why not? Unless it's part of the social protection. But I can personally accept NFC contactless payments (having opened an account with a suitable provider), and indeed I bought a device which means I can accept chip and PIN payments too.
* The vast majority of the payments (almost all of them) are done with dynamic QR codes.
* The static QR code is mostly used by very, very small entities. Like the person asks you to scan their code, enter the amount and show them the confirmation. It is in their interest to show the right QR code.
* Sending money to a friend is done with the phone number as an id. It works, but you need to enter the mobile phone number of the receiver.
* There is one situation where static codes are printed and where phishing has been reported (it's not MITM, it's really just a QR code that sends you to a bad website): when paying for parking. You don't have to use it if you don't feel comfortable, and it is possible to feel comfortable because it actually just opens a website (so if you use it regularly you can learn to check that you are on the legit website before you make the payment).
Overall, it is super popular and it works really well. No need for NFC, and no need to install the Google Play Services \o/.
A counter-point might be that my credit card doesn't require Google Play Services either. And won't run out of battery. And works with all the local businesses, including the smallest -- while there are some people (mostly outside cities) who still only take cash, I can't imagine them signing up for TWINT either.
There are several providers of services allowing individuals and small traders to accept credit and debit cards, and I've happily accepted cards from foreign banks too.
I'd be sceptical of anything like TWINT catching on in the UK, because NFC payments are already ubiquitous and also really easy to use.
I didn't say you have to like them. But if you claim they are insecure, I feel like it's my right to note that you may be wrong.
> A counter-point might be that my credit card doesn't require Google Play Services either.
That is not exactly a counter-point in a discussion between a mobile app doing NFC and a mobile app using QR codes, is it?
> I'd be sceptical of anything like TWINT catching on in the UK, because NFC payments are already ubiquitous and also really easy to use.
That's another question. My original point was that non-US banks should not depend on Google Play Services or Apple Pay (which at least until very recently was the only way to pay with NFC on iPhones, wasn't it?).
Phone nfc payments do not.
So yes, it's handy. Jot handy enough to use gpay for it, of course, but handy nonetheless.
The bigger problem came from apps that threw null point exceptions on startup when probing for google play crap.
The following failed for at least one week over a two month period: parkmobile, multiple ev charging networks, uber, lyft, yelp.
Is this still an issue, or are things more reliable these days? (Ignoring the Google integrity stuff.)
I noticed that GrapheneOS got more than 2x Google’s advertised battery life until I installed Google Play Services in a sandbox. Then it dropped to advertised. You might want to add that to your complaint. Halving everyone’s battery life is easily quantified economic damage. (Privacy is more important than bundling $50 of battery, then wasting it, but easier for Google to wave away with big words and doublespeak.)
These apps have worked reliability since our sandboxed Google Play compatibility layer added support for them in 2021. There wasn't a time period where these apps weren't compatible with GrapheneOS after they initially became supported. That was a problem with your setup, but there's no way to figure out what was wrong at this point. Updating sandboxed Google Play without keeping the OS updated is not supported. If you fell significantly behind on updates but were still getting sandboxed Google Play updates, that would explain why things broke. We sometimes gate those updates. We do keep things working for legacy extended support devices, but whether people are on a fully supported device or a legacy one they're expected to keep the OS updated. We don't keep compatibility with old OS versions indefinitely. Disabling the Network permission for sandboxed Google Play services or sandboxed Google Play Store is another possible cause. Regardless of the cause, that's not at all normal and doesn't reflect a typical experience.
> I noticed that GrapheneOS got more than 2x Google’s advertised battery life until I installed Google Play Services in a sandbox.
GrapheneOS will still tend to get better battery life with the same apps installed by the user unless you install a bunch of other Google apps to match the stock Pixel OS out-of-the-box experience. It's easy to make battery life worse by having multiple push messaging systems running at the same time though. Installing sandboxed Google Play in 2 separate profiles you always keep active could easily have worse battery life than the stock Pixel OS since it's 2 whole separate isolated instances of it vs. the stock Pixel OS having them built into the OS as highly privileged cross-profile system services.
Some of those banks may also still support using their own tap-to-pay. Europe has a standardized system for it and many banks support it. Check https://privsec.dev/posts/android/banking-applications-compa... for those banks. There was a major shift to using Google Pay to reduce their development costs but there may be a major shift away from it now.
https://grapheneos.org/articles/attestation-compatibility-gu... should be sent to companies banning using GrapheneOS via the Play Integrity API. They can keep doing that while permitting GrapheneOS in a more secure way. Our users recently convinced several banks to implement it. Swissquote implemented it for their Yuh app and will hopefully do it for their main Swissquote app soon. It would be nicer if they didn't add Play Integrity API in the first place but progress can be made if users leave lots of reviews, support requests, etc. until they realize it's a big issue and either remove it or implement this as a replacement.
As in the OS in question is GrapheneOS itself?
But one could argue that the team can move fast on 9a because they can piggyback existing (GrapheneOS) distros.
We automate a huge portion of the work via https://github.com/GrapheneOS/adevtool. We do a GrapheneOS build with it and it outputs state you can see in https://github.com/GrapheneOS/vendor_state which is then used to automatically figure out all of the missing overlays, SELinux policy, firmware files, etc. When we have our own devices in partnership with an OEM we won't need to use adevtool. We can borrow a lot from Pixels for those devices though.
Pixels are very similar to each other, which does make things simpler. The entire kernel source tree is identical for 6th, 7th, 8th and 9th generation Pixels. They all use the Linux 6.1 long term support branch on bare metal and the Linux 6.6 branch for on-device virtual machines. They'll likely advance to new Linux kernel branches together rather than ending up very split across different ones as they were in the past. That makes things easier for us.
Pixels also share most of the same drivers for the SoC and lots of other drivers. Those drivers support the different generations of hardware with the same codebase for the most part. There are still 6 different Wi-Fi/Bluetooth drivers across them but 5 of those are variations of a very similar Broadcom Wi-Fi/Bluetooth driver and only 1 is a separate Qualcomm Atheros driver (Pixel 7a).
We have various hardware-based hardening features such as our hardware-based disabling of the USB-C port with variations across different hardware generations (https://grapheneos.org/features#usb-c-port-and-pogo-pins-con...) and similar features. Our exploit protection features also uncover lots of memory corruption bugs across devices in their drivers. We do have a lot of device-specific work fixing uncovered bugs. Hardware memory tagging in particular finds nearly every heap memory corruption bug occurring during regular use including out-of-bound reads so that finds a lot of bugs we need to handle. Many of the bugs we find with hardware memory tagging and other memory corruption exploit protections are in drivers or the portable Bluetooth software stack which is thankfully one of the components Android is currently gradually rewriting in Rust along with the media stack.
If we supported a device with much different drivers, there wouldn't be much work to deal with that directly but enabling our features like our hardware memory tagging support would require fixing a bunch of memory corruption bugs occurring during regular use across it. Supporting other Android devices with the Android Open Source Project is easy. Supporting them with GrapheneOS is significantly harder due to various hardening features needing integration at a low level along with others uncovering a lot of latent bugs which were occurring but not being noticed most of the time. The ones which get noticed often due to breaking things get fixed, but many latent memory corruption bugs remain there unless the OEM heavily tests with HWASan or MTE themselves, which is unlikely. Pixels are tested with HWASan and MTE by Google but yet we still have to fix a lot ourselves largely because testing them in a device farm is different than users actually using them with assorted Bluetooth accessories, etc.
Nice to know that all supported Pixel phones are not only on the same kernel version, but actually are build fro the same source tree now.
Do you also contribute your fixes back to the upstream projects like the upstream Linux kernel, AOSP or Google?
Many of the security features you are using are already included in AOSP, why does Google not activate them by default? Do they have a different balancing of performance, stability and compatibility on the one side and security on the other? I understand that Google has a different view on privacy for business reasons.
We've made significant contributions to the Linux kernel, AOSP and Pixels in the past. We continue doing it to the extent that it helps GrapheneOS users. We no longer spend our time doing work for them if it doesn't have a clear benefit to our users.
Android's security team previously got us security partner access and was in the process of getting us OEM partner access. Android's partner management team blocked us from getting OEM partner access and revoked our security partner access. Due to this, we've reduced our reports of vulnerabilities upstream and have fixed numerous vulnerabilities in GrapheneOS without reporting them. We still report all firmware and hardware vulnerabilities but we make a decision about reporting software vulnerabilities solely based on what's best for GrapheneOS users.
> Many of the security features you are using are already included in AOSP
That's not really the case. The vast majority of our privacy and security features were developed for GrapheneOS. Features being built on top of standard functionality doesn't mean that they're present in AOSP.
For example, GrapheneOS has our own integration of hardware memory tagging into our hardened_malloc project and we turned the overall feature into something which can be used in production without making the OS unusable. We had to fix issues with the standard hardware memory tagging integration in the OS and Vanadium (Chromium) along with fixing numerous bugs uncovered by it. We had to integrate it into our user-facing crash reporting system and had to create a system for opting into using it for user installed apps where users can enable it for either specific user installed apps or for all user installed apps with a per-app opt-out. Android has the foundation for hardware memory tagging support but it's not used as a production feature for hardening and we're not simply enabling it. We have a much better userspace implementation in hardened_malloc and while we currently use the standard kernel allocator integration, we want to improve that to be closer to what we do with it in hardened_malloc. We currently use the standard Linux kernel MTE integration for the kernel allocators and the standard Chromium PartitionAlloc MTE integration but both need to be improved to provide better security properties as hardened_malloc does. They're also missing the other forms of hardening used by hardened_malloc which go nicely with memory tagging. The stock OS developer option for memory tagging is not the same thing and only makes it available for usage without actually using it. It has to then be enabled via ADB but there's no way to use it everywhere we do or in the same way we do. AOSP having that doesn't mean it provides what we do with it at all.
> Do they have a different balancing of performance, stability and compatibility on the one side and security on the other?
Yes, but you're wrong about where our privacy and security features come from.
Let’s contrast that with a pure community led effort, motivated by freedom, privacy, and safety, that neither controls the OS nor the devices. It’s not what I tried to saltily explain above.
Respectfully, I hope that sunk in.
While the 9a and 9 pro are very similar, for comunity based development this is substantial.
I am often very critial, but I must give props to the grapeneos team.
Adding new Pixels including whole new generations tends to be quite easy. When we still supported Snapdragon Pixels in the official GrapheneOS branch, it would have been fairly easy to add support for a theoretical Sony or Motorola device meeting our security requirements (https://grapheneos.org/faq#future-devices). Now that we don't have a Snapdragon device, we'd need to deal with fixing or working around all the bugs uncovered in Snapdragon drivers, integrating support for the USB-C controller into our USB-C port control feature (https://grapheneos.org/features#usb-c-port-and-pogo-pins-con...), adding back our code for coercing Qualcomm XTRA into being privacy respecting, etc. Snapdragon doesn't have memory tagging yet like Tensor (and recent flagship Exynos/MediaTek now), but pretending it did, we'd need to solve a lot of issues uncovered by it unless Qualcomm and the device OEM heavily tested with it.
See https://news.ycombinator.com/item?id=43669913 for more info including about kernels. 6th, 7th, 8th and 9th generation Pixels share the same Linux 6.1 source tree and kernel drivers since Android 15 QPR2 in March 2025.
Pixel 9a is still using a branch of Android 15 QPR1 due to how device launches work so most of the work involved taking our last Android 15 QPR1 release from early March and rebasing it onto the Pixel 9a device branch tag where they forked off from an earlier Android 15 QPR1 release and backported current security patches to it. We then had to backport our changes since early March. The device branch will go away in a couple months and it will be on the same branch as everything else until it's end-of-life as usual. We could spend more time to integrate it into our main Android 15 QPR2 based branch ourselves but we can also simply wait a couple months. As an earlier example, the Pixel 8a was released in May 2024 based on Android 14 QPR1 rather than the current Android 14 QPR2. It was incorporated into mainline Android 14 QPR3 in June only a few weeks later. We know Android 16 is already going to deal with this so spending our time on this instead of implementing new privacy, security, usability and compatibility improvements would be a waste.
I got it on a P7P and love it.
Quick, someone named strcat_s or strncat correct them!
I wish it was feasible to run GrapheneOS on more devices. For some reason, Google seems to be incapable of selling Pixels world wide.
Treble's compatibility system isn't very relevant to us right now. There's a new Android release every month: a monthly, quarterly or yearly release. The devices we currently support (Pixels) receive each of these updates officially. Most Android devices do not get the monthly or quarterly updates, only the yearly ones. Other devices rely on partial backports of security patches (Android Security Bulletins) to an initial release, which are provided for ~3-4 years after the initial yearly release. If we supported typical Android devices with that situation, then we'd at least partially rely on Treble to provide the latest OS version. Pixels are currently the only devices meeting our hardware security requirements listed at https://grapheneos.org/faq#future-devices. Having proper updates for 7 years from launch is just part of that, most of the requirements are for hardware-based security features like the secure element features, hardware memory tagging, pointer authentication, USB controller support for blocking new connections and disabling USB data, etc.
GrapheneOS uses the 6.1 and 6.6 long term support branches of the Linux kernel with 6.12 as the next one that's likely going to be used to replace 6.6 for on-device virtual machines and the emulator with Android 16.
But they're drivers that are not upstreamed and which therefore make it hard to move to a newer kernel, right?
It's no harder than it would be dealing with them if they were upstream. Google ports all the Pixel drivers to newer LTS branches and a recent branch of the mainline kernel themselves.
With the recent Android 15 QPR2 release last month (March 2025), 6th/7th generation Pixels moved from the 5.10 branch to 6.1 and 8th generation Pixels moved from 5.15 to 6.1. 6th, 7th, 8th and 9th generation Pixels share the same kernel and kernel driver source tree now. They have them ported to 6.6 and mainline kernels too, it's just not ready to ship yet. 6.6 is used for virtual machines run on the devices and the emulator. 6.12 will be what's used for Android 16.
You can see at https://android.googlesource.com/kernel/google-modules/aoc/+... that they still port the 6th gen Pixel drivers to newer mainline kernels. They're ported to 6.13 and probably moving along to 6.14 soon. It doesn't mean they're going to ship them. Only LTS branches make sense to ship and they need long term stabilization first. The likely model is going to become ~12 months of stabilization and then ~12 months of usage since LTS kernel branches are moving back to 2 years of support. It was essentially increased to 6 years for 6th gen Pixels having 5 years of support, but they moved along to upgrading to newer LTS branches for 8th gen Pixels moving to 7 years of support. Greg KH works for and with Google on the LTS kernel maintenance / testing so it's actually quite Android centric rather than server centric. Long term support desktop/server distributions historically maintain their own LTS branches so they're not really the ones involved in that for the most part.
Drivers that are upstream don't actually get much free maintenance and testing. People making API changes blindly update the drivers without testing them. They get lots of updates and refactoring, but not much ongoing maintenance. Maintainers still need to deal with it. It's very common for upstream drivers to continuously regress. They can go a long time without actually working properly across releases due to how few people use them. Most people are using distributions with frozen package versions like Debian, not a rolling, and people using a rolling release like Arch Linux can use an LTS kernel branch to avoid a lot of this. The drivers for embedded hardware and things not used much by enthusiasts on desktops often break without it being noticed.
Android made a Generic Kernel Image system with ABI stability for drivers which does not benefit Pixels because they update the drivers to match the latest GKI kernel they ship. Similarly, Pixels don't really need the Treble HAL ABI forwards compatibility because they update all the vendor code to the latest monthly, quarterly and yearly OS releases anyway. It's helpful that drivers don't need to add all the new standard features to keep providing working support for new OS versions though. It's nice having it all nearly all neatly standardized and stable. We like Treble because of the sandboxing. The forwards compatibility benefits are largely unrealized because the vendors needing it aren't doing updates much anyway. Qualcomm is moving to 8 years of full update support for Snapdragon to partially match Pixels anyway.
First: I did momentarily forget that you're only targeting Pixel devices that are actively getting updates from Google. In light of that, so long as Google stays on top of maintaining those devices, yeah in your case that's probably fine. I'm somewhat accustomed to less responsible vendors and a lot of my views are shaped by that.
That said, I'm not wholly convinced that Google's downstream kernels are as good as running from upstream. AFAICT, for example, GrapheneOS is currently shipping a kernel for the Pixel 6 that's 3 minor versions behind. Trying to track things through the Android development process is... unintuitive... to me, so forgive me if I've missed something... If I go to https://github.com/GrapheneOS/device_google_raviole-kernels_... , grab a .ko file that shows as being committed yesterday, and run modinfo on it, I get a version of 6.1.131 which https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.1.1... says is from March 13 and has been superseded by 6.1.134 at this writing (from checking https://www.kernel.org/ ). Contrast https://archlinux.org/packages/core/x86_64/linux-lts/ which says that Arch's LTS kernel is at 6.12.23 which is the latest of that line. EDIT: Actually, the much better comparison is that Debian 12 is shipping 6.1.133 according to https://packages.debian.org/stable/kernel/linux-image-arm64 now. So the super stable slow moving distro is in fact still ahead of Android, even slightly lagging as it is.
As to breakage/testing... Yes, someone has to test new versions. Ideally that'd be a CI farm flashing and testing devices, but I appreciate that it's not exactly a trivial problem. Nonetheless, if that results in Graphene not shipping the latest bugfixes, I feel like that's an extremely awkward position to be in.
Pixels only recently started moving to new LTS releases and will likely be moving to a new LTS release each year going forward. Moving the older generations to 6.1 to match current devices was done in March 2025. They'll likely move along together to a new branch each year going forward.
Linux kernel LTS revisions are nothing like LTS revisions of most other projects. They're largely untested patches blindly applied by the LTS maintainers based on patches to mainline being marked for stable backports. If the patches apply cleanly, they ship. If they don't apply cleanly, they largely don't ship. Whether it works is an open question.
> GrapheneOS is currently shipping a kernel for the Pixel 6 that's 3 minor versions behind
That's not quite right.
We're shipping the latest Linux 6.1 and Linux 6.6 GKI LTS branch releases from Greg KH. They're currently in between 2 upstream revisions upstream, not on a specific one. The devices all use both 6.1 and 6.6, not just 6.1. They use 6.1 for bare metal and 6.6 for virtual machines. Even the Pixel 6 has been ported to 6.13 by Google but that doesn't mean that's a stable enough kernel ready to ship.
The Android kernel branches also have a bunch of backports not included in the kernel.org LTS releases, including security patches and improvements they decided were important. Google does their own backporting and fixes in the GKI branch and Greg KH merges those into the GKI LTS branch. The kernel branch we use is the combination of the Google GKI backporting/fixes with the kernel.org backporting. The kernel.org LTS releases are far messier than you realize, and combining these things is messy too.
Linux LTS kernels are not very well tested and have tons of regressions. Quickly updating to the new LTS versions is problematic and we regularly encounter major regressions, especially in certain areas like f2fs and USB. We still update right away to the new GKI LTS versions. We're currently on the latest GKI LTS releases for each branch.
You'd have to ask Greg KH why there are still delays despite Google supporting it. It still seems to be him doing most of the kernel.org LTS and also GKI LTS work by himself, without nearly as much review or help by others as you would think. This is also tied into the severe regressions regularly happening with the LTS releases. Those can be security regressions too. Immediately updating to them is not necessarily a great idea with how much goes wrong at the moment.
They unfortunately sometimes lag behind the kernel.org releases. We used to merge the latest upstream kernel.org LTS releases ourselves but Greg KH convinced us we don't need to do that anymore and should just use the GKI LTS branch instead. We're not completely happy with it since it's not fully kept in sync but we're using our resources elsewhere at the moment.
> Actually, the much better comparison is that Debian 12 is shipping 6.1.133 according to https://packages.debian.org/stable/kernel/linux-image-arm64 now. So the super stable slow moving distro is in fact still ahead of Android, even slightly lagging as it is.
Debian is usually further behind than Greg KH's GKI LTS branch. Comparing at a snapshot in time doesn't mean much. GKI LTS branch should really be kept in sync but the GKI ABI stability system makes maintenance hard and is entirely worthless for Pixels. We would prefer if the whole GKI system did not exist. For Pixels, the kernel image and all the drivers are built with the same kernel source tree for Pixels so the whole system for driver ABI compatibility is just making things more complex and worse.
> As to breakage/testing... Yes, someone has to test new versions. Ideally that'd be a CI farm flashing and testing devices, but I appreciate that it's not exactly a trivial problem. Nonetheless, if that results in Graphene not shipping the latest bugfixes, I feel like that's an extremely awkward position to be in.
We do heavily test them. Our community helps with it. We OFTEN find regressions in the new LTS kernels. It often takes months before the issues we find and work around get fixed upstream. It's worth noting that due to mistreatment we've largely stopped helping them except for firmware, hardware or things we don't want to maintain downstream for some reason. It would be better if everyone collaborated on maintaining LTS kernels but instead it's largely 1 person and a couple others doing it with support from Google for testing, etc.
> Linux kernel LTS revisions are nothing like LTS revisions of most other projects. They're largely untested patches blindly applied by the LTS maintainers based on patches to mainline being marked for stable backports. If the patches apply cleanly, they ship. If they don't apply cleanly, they largely don't ship. Whether it works is an open question.
I'm also not super fond of frankenkernels. And... I'm confused how you feel about them? If backports suck, shouldn't you want to be chasing the very bleeding edge? I wasn't originally intending to argue that everything had to ride the very latest and greatest, but if backporting is inherently fragile and bug-prone, shouldn't you want to be on the very latest stable version (so as of this writing, 6.14.2)?
Pixels moving 6th, 7th and 8th gen devices to 6.1 happened in March 2025. It's the first time they've moved to new LTS branches. It's likely going to move to using a newer LTS release where it would currently be using 6.6 and then moving to 6.12 after the next one comes out. We expect they move to having around a year to stabilize the new LTS and then use it for around a year before moving to the next. That fits nicely into the new 2 year lifespan for LTS kernels. This is a transition period. Once the longer than 2 year LTS kernels are gone, the quality of the LTS kernels will rise because there won't be as many to maintain. There are currently too many combined with too few people working on it. Greg KH having to handle both the kernel.org LTS and GKI LTS doing a huge portion of the work is clearly a problem. We'd also like to see the end of GKI ABI stability but that's highly unlikely. Yearly moves to new LTS kernels will at least make it a lot better.
> I would personally take [quickly checks kernel.org] 5.15.180 (latest 5.15) over 6.1.130 (not-latest 6.1)
Latest 5.15 has far fewer fixes backported for the same time periods than 6.1. The missing fixes in 5.15 are far more than a couple minor revisions. Similarly, 6.6 has more than 6.1 for the same time period and 6.12 has more than 6.6.
> And... I'm confused how you feel about them? If backports suck, shouldn't you want to be chasing the very bleeding edge? I wasn't originally intending to argue that everything had to ride the very latest and greatest, but if backporting is inherently fragile and bug-prone, shouldn't you want to be on the very latest stable version (so as of this writing, 6.14.2)?
Linux kernel code quality, review and testing is quite low. The bleeding edge kernels are nearly unusable in production for this use case (users running all kinds of software, using all kinds of different Bluetooth, USB, etc. accessories and so on while caring deeply about battery life) and have a ton of newly added security bugs which aren't found and fixed yet. We think that's a much bigger issue. We happily use Arch Linux for a lot of stuff but we use the LTS kernel package which is 6.12 at the moment.
If LTS quality was increased substantially, then we'd want to be on the latest LTS branch a while after the initial release, i.e. 6.12.15+ or so. However, at the moment, some serious regressions take them so long to find that it's still too new. We have high stability requirements where we can't have niche USB functionality, Bluetooth, video recording, etc. functionality regressing. The out-of-tree drivers are an area we don't have as much pain with since they're nearly all made for Exynos / Pixels and the drivers from the vendors so changes actually get tested well. The regressions are in the upstream code. More stuff coming from upstream would make LTS updates more, not less, painful, other than the GKI ABI stability nonsense we don't want.
I don't want to use Android, I want to use Linux and Phosh or similar. But so far, the supported hardware is junk.
The Linux kernel is increasingly the elephant in the room when it comes to security and hasn't experienced anything like the massive progress made in Android's security in userspace. Piling on many more exploit mitigations to the Linux kernel won't really change this. We need to do a lot more work on it than we already do.
GrapheneOS has hardware virtualization support, which is going to be one of the ways to avoid depending so much on the Linux kernel's fragile security. The main usage for it in GrapheneOS will be running nested GrapheneOS instances for better sandboxing rather than running other operating systems. Android supports using the virtualization support to run other operating systems via the Terminal app and we have support for GUI applications, speaker, microphone and opt-in GPU acceleration backported to the Terminal app. The main use case for that app will be running desktop applications from other operating systems for the desktop mode. Windows 11 support would be a compelling addition to it and we may implement that in the next year or so.
No interest in Android apps or Windows (hah). (Though maybe I'll try Waydroid one of these days.)
I don't know anything about your distro, not the graphics stack or what the package manager is or even if there is one? Meanwhile my starlite tablet is awesome because it works just like my desktop Fedora or Mint, though I installed Phosh on it.
Security is nice, but not before there is even a single feasible device on the market. Librem is just barely limping along, and I mean barely with a five year old handset that was obsolete when it debuted.
If your kernel is so advanced it really should be upstreamed, so these other distros could use it and support new Pixels. Y'all working together with other mobile projects would be so much better than the current surveillance dystopia we are currently living in. Maybe it's hard, but it is incredibly important. I can help though have limits.
Sounds like I should complain to them instead. Yet they are known for being unreachable.
>So the super stable slow moving distro
Slow isn't referring to the speed Debian takes for hot fixes. It is referring to how long Debian stays hot fixing packages over updating to the latest version.
We ship GKI LTS updates quickly but the GKI LTS branch can sometimes lag behind by up to a few weeks as it was doing when you looked. You happened to look at the maximum point it lags behind. It should really be kept closely in sync with the kernel.org releases but it's almost entirely Greg KH dealing with it and he deals with a lot of other stuff too.
They tried to get away with it on OpenBSD, macOS, etc and got their hand chewed off.
I wish they had an option that just used libc. Maybe, someday someone will add a target architecture/port that just uses posix. I’d prefer that in Linux too.
https://github.com/lukasstraub2/intercept-anything
Go is hardly the only thing where LD_PRELOAD doesn't work.
Regarding LD_PRELOAD, I highly doubt that this is required by POSIX. macOS (which is a certified UNIX) uses DYLD_INSERT_LIBRARIES instead. OpenBSD (which is known for their pedantic documentation) uses LD_LIBRARY_PATH, doesn't mention any standards, and refers the reader to SunOS 4.0. If this is somehow standardised, I'd love to read the actual document.
Android already published the full source code for Stable releases but barely anything for Beta releases. They didn't publish anything for upcoming releases with support for new devices. AOSP main branch received most changes through the Stable releases being merged into it. Most components were developed internally. Certain components were developed publicly in AOSP so they had to repeatedly merge back and forth between the internal and public main branches.
GrapheneOS would benefit from having early access to the monthly, quarterly and yearly releases as Android OEM partners do. The only benefit of having access to the main development branch would be the ability to backport more fixes than they do along with doing it earlier. We occasionally backported fixes from AOSP main for the few components developed publicly through it, which is what's going to be mostly going away. It was a big help to us as access to the upcoming quarterly and yearly releases would be. Monthly updates are too small for it to really matter but it'd still help.
Also worth noting the monthly security patch backports (Android Security Bulletins) are a separate thing from the new OS release each month. Those are backports of many of the High and Critical severity patches to older Android versions, often a month or two after they were released in the actual OS releases each month which are the monthly, quarterly and yearly releases (it's one of the 3 each month, with 3 quarterly releases and 1 yearly release per year although Android 16 is coming earlier this year instead of a 3rd quarterly release).
[0] https://grapheneos.social/@GrapheneOS/113917226566692707
Such a bizarre phenomenon to me that people are still griping about a software update that stops a 4-year-old battery from detonating when the same company will also fix the phone for free or just hand you $50 if you prefer that.
Not really just handing it to you https://arstechnica.com/gadgets/2025/03/how-google-nerfed-my...
The $50 "cash" offer came with so many downsides that just ignoring it would be the smarter choice for anyone who values their time (someone already provided a link).
I doubt that they'll give me any sort of money or do repairs on a phone that I opened up.
It's frustrating as I thought I would be able to get several more years of life out of this phone.
Does this mean my pixel 4a battery was unaffected for some reason... or simply that the lawyers managed to weasel out of paying 100% of active pixel 4a owners back and my phone is still dangerous or degraded? ¯\_(ツ)_/¯
https://23.social/@mj1982/114210416377875387
54% Battery consumption is lower under GrapheneOS
13% Battery consumption is lower under stock Android
33% Can't tell the difference.
For users with a single profile with sandboxed Google Play installed before other apps, it should be very similar to the stock Pixel OS if you installed the dozens of Google apps they bundle on GrapheneOS and disable the various privileged apps they integrate which aren't usable on GrapheneOS. The stock OS drains more power with a typical simple setup because it has so much more installed and running. If you make it similar, it's nearly the same. If you use a more complex setup with multiple profiles and multiple push implementations on GrapheneOS, that's going to use more power. It still shouldn't drain nearly as much as you said above without something seriously wrong with the setup.
It's very easy to make battery life much worse. Using multiple push messaging implementations simultaneously is inefficient. As an example, using sandboxed Google Play in your Owner user, sandboxed Google Play in a work profile and a Private Space without it with various apps doing their own push would of course be far less efficient than a single Firebase Cloud Messaging push connection shared across the entire device. Having 2 installations of sandboxed Google Play you always keep running would be less efficient than privileged Google Play. Regular privileged Google Play shares the same processes and connections across profiles since it's built deeply into the OS and is implemented that way for efficiency like many OS services. If you compare having a single privileged Google Play vs. multiple sandboxed Google Play alongside apps doing their own push, of course privileged Google Play would be more efficient. You can use GrapheneOS with a similarly efficient setup and battery life will not be worse. You likely just have an inefficient setup. It can still be hard to narrow down what's really draining battery usage despite Android's battery stats getting much better over time.
On my 6 pro, I got 2x advertised battery life until I installed one copy of Google Play services. Then I got advertised battery life.
It should be easy enough to uninstall Google’s stuff for a week and measure battery drain, then put it back.
Even with it though, I wasn’t losing 30% overnight. There’s probably some other problem. Maybe wipe + reinstall, then try with and without the 24/7 surveillance daemons?
I would recommend people to install the play services and play store in the main profile. Then, install apps in the main profile too but remove all permissions and abilities, restrict and disable them. After that, enable them in a "banking" profile. One can then selectively enable and disable the play store to update these apps which propagate to the other profiles. The disabled apps are still updated normally by the play store.
I do believe that they are working on a feature to limit app intercommunication in a similar vein as the other scopes. This would be cool because it would allow one to allow "point to point" communication of certain apps with the play services but otherwise restrict them. Though I don't know the state of development for this feature.
GrapheneOS gives us a way to resist. The convenience of having a modern phone is hard to give up, and with GrapheneOS you can have 90% of that convenience while reducing much of the surveillance and attack surface. Now, we just need a pixel phone with two big hardware switches, sliders on each side of the phone: one kills the radios, and the other kills the sensors (cameras, microphones). When you want to take a call, just flip the big slider switch up to activate cameras and mics.
Thank you to strcat and the rest of the team! If you don't use GrapheneOS, I would consider it. You can donate here: https://grapheneos.org/donate And if you have the right kind of programming skills, why not help out?
A kill switch for all of the radios is much less useful for this threat model because even regular apps know how to queue up all their data for later usage. If the goal is preventing detection location detection, that really requires disabling all the radios and sensors rather than just radios. If the goal is dealing with an attacker able to exploit radio firmware but not the OS from there due to the IOMMU isolation and hardened kernel/userspace drivers in GrapheneOS, that could potentially be useful, but they'd already lose access on a reboot as long as it power cycled the radio as long as the radio doesn't have any significant persistent state due to verified boot.
One of the advantages of hardware kill switches, shutters on cameras, and the like is social signaling: other people can see them, and can see them being used. If I put my mass-manufactured phone on the table, and you can see the hardware sensors switch is "off", you can be quite sure I'm not recording you.
I think there's a chance for us to normalize this sort of thing, and make it table stakes for a lot of interactions. In a meeting room and there isn't a shutter on the camera? That's breaking the rules and we need to find one. And so on.
Relevant to this discussion, another thought I had is location- and QoS-aware enabling and disabling of the cell radios so I'm using wifi whenever I can, automatically. If I have a good internet connection other than through the cell radio, the cell radio is shut off.
Thank you again for your thoughtful reply and your work.
How much do I gain from switching to it instead of say, remaining on the Stock Android?
Edit: This looks comprehensive — https://staging.grapheneos.org/features
Beyond that, most of the other advantages will be less visible. They have hardened memory allocators that make various classes of security beaches significantly more difficult. There's a lot less superfluous background services eating resources. All that and more are listed on their website. It's well worth a read.
Remarkably, Nationwide (UK) runs perfectly even without Google services. (Except it doesn't poll for payment confirmations but that's understandable. They're always fetched when you open the app though. Or it could be my setup). It's actually quite shocking and it speaks to Nationwide as being a decent organisation.
It's also not necessarily a downside. Having your banking app on your phone can be a risk of you often take your phone out in public
The absolute blocker is Google Pay. That isn't supported
https://privsec.dev/posts/android/banking-applications-compa...
with its github backend
https://github.com/PrivSec-dev/banking-apps-compat-report
If you are in Europe, Curve recently enabled mobile payments without Google Pay, and that might solve the issue (but I haven't tried it myself).
Some app that don't work because they require strong integrity are listed here: https://grapheneos.org/articles/attestation-compatibility-gu...
Awesome to read the support chat from nationwide saying it's explicitly supported. I figured as it works so well.
They're a very decent building society/bank if anyone is looking for a new one!
This could be very useful. My Google skills came up short. Do you have a link?
From 2 years ago: https://www.reddit.com/r/GrapheneOS/comments/126nd51/comment... -> Sounds like Curve (without Google Pay) wasn't officially supported in Europe and didn't work for most people.
However, this seems to have changed a couple days ago:
https://www.reddit.com/r/curve/comments/17txz6u/comment/mkwl...
https://discuss.grapheneos.org/d/443-gpay-alternatives-for-g...
https://discuss.grapheneos.org/d/475-wallet-google-pay/105
https://discuss.privacyguides.net/t/curve-pay-available-as-a...
This is in line with an interview with the CEO of Curve from last month, https://paymentsconsulting.com/qa-with-shachar-bialick-at-cu...
> We are launching Curve Pay in beta for Android soon and plan to release it on iOS thereafter. This will allow customers to use Curve as their default wallet, just like Apple Pay or Google Pay.
…and with various German news sites reporting that Curve Pay is now available in Germany (and likely other parts of the EEA).
My solution to this is put the bank apps that are annoying about it on an old phone (I knew I'd find a use for one eventually!)
Many seem to work, if you apply some tweaks. Google Wallet NFC payments totally don't, I believe.
Google Wallet does not work, therefore I cannot use my phone to pay wirelessly with my Neon card, which is a shame.
The only apps I had trouble with were Twint (had to install it with F-Droid, as Play kept telling me it was not compatible with my device), and... the McDonald's app (which forces me to move my fat ass to one of their kiosks to order my food instead of doing it from the table).
I will contact them to try to get them to support GrapheneOS, but I will not be holding my breath. I uninstalled it in the meantime and use my computer. If they ever require the app I would likely switch to a different bank.
Side note, balatro-mobile-maker works really well as an unofficial port to Android. https://github.com/blake502/balatro-mobile-maker
Here's an example demonstrating the impact of our security improvements:
https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju...
February 2025 Cellebrite Premium documentation was posted by someone further down in the thread, which is essentially the same overall situation.
https://discuss.grapheneos.org/d/20401-grapheneos-improvemen... has some details on how we've improved that since early 2024.
The stock Pixel OS is approximately AOSP with a bunch of Google apps deeply integrated into it. Pixels don't actually change anything compared to the AOSP code, they just substitute various components with their own and add a bunch of overlays, apps, etc. AOSP has all the stuff they need to provide that included already. They give extensive privileged access to Google Play and various other apps via privileged permissions, SELinux MAC/MLS policy (which is included in AOSP) and various allowlisting, etc. They also use Play services, etc. as backends for various AOSP APIs. One of our major features is our sandboxed Google Play compatibility layer enabling running Google Play services, Google Play Store, Google Search, etc. as regular sandboxed apps with no special access at all where users don't even need to grant them the regular non-privileged permissions like Contacts, Location, etc. to use most of their functionality (some functionality requires that such as if you wanted to use Google Maps location sharing or Google Contacts sync).
This is an OS for people who care more about privacy and security than having an everyday usable phone. It is very much not for normal people.
GrapheneOS is intended for everyone.
> It really only works well if you don't rely on any apps that depend on Google play, like steam or discord.
Steam, Discord and the vast majority of Android apps work perfectly on GrapheneOS. Sandboxed Google Play is a robust feature which works very well. If you're choosing to completely avoid using Google Play, that's your choice. Steam and Discord both still likely work without it, but without push notifications since they have no alternative to FCM as certain other apps do.
> If you're on AT&T, you don't get caller ID or voicemail.
You do get caller ID and voicemail on AT&T. Visual voicemail doesn't work with AT&T with the built-in Dialer app because it uses a protocol not supported by AOSP. It does work with Google Dialer based on user feedback on our forum.
> This is an OS for people who care more about privacy and security than having an everyday usable phone. It is very much not for normal people.
GrapheneOS is very usable as an every day usage phone for regular people. Nearly every Android app can be used on it. It sounds like you were choosing to use it without sandboxed Google Play, which is a choice to have a more limited app and service ecosystem. That's not the same as a choice to use GrapheneOS. It can be used like a regular Android phone with 1 profile containing sandboxed Google Play, or people can use sandboxed Google Play in a specific profile with most of their apps in another profile. Using it without sandboxed Google Play in a secondary profile is something many GrapheneOS users do successfully but it's in no way required or expected. We wouldn't have made that huge feature if we didn't want it to be used by a lot of people.
You do not get caller id on AT&T, and you do not get voicemail notifications until sometimes hours or days after the fact. I ran this on my pixel 8 for months. I had to actively call into my voicemail number like it's 2005.
The secondary profile stuff is just about useless. It's one step above having multiple independent devices. I did try having a Google profile, but you can't get notifications between profiles. You get a notification that there is a notification, so you then have to go through the entire 30 second process of switching profiles, which disconnects your Bluetooth headphones to check the other profile.
If you think regular users and normal people want to put up with this, you should really re-evaluate what you think an average user is. This is for hyper nerds who care more about security ideals than functionality. Graphene is not for the average person who wants caller id, voicemail, camera, and a web browser.
Compatibility with carriers also improved a lot a few years ago. Configurations for most carriers are pulled in from the stock Pixel OS. Some US carriers do weird things that depend upon having highly privileged apps bundled into the OS which, for security reasons, GrapheneOS doesnt include. I dont recall AT&T being one of them.
GrapheneOS is very usable and fine as a everyday phone for normal people.
It is not usable for normal people who want to use their phone to stay in contact with others.
Graphene is just taking control of my phone from Google and giving it to whoever runs Graphene. I don't get any say in how my phone works.
Graphene thinks you can't be trusted with your own device. But don't worry, they definitely know what's best for you and it's a totally different kind of control from what Google has. Really, just trust them, it's totally fine, promise.
I switched to Lineage after a few months.
What specific ways do you feel are "more locked down" than stock? It's not recommended, but you can install magisk + root if you really wanted to. It won't try to prevent you.
>Graphene is just taking control of my phone from Google and giving it to whoever runs Graphene. I don't get any say in how my phone works.
That's fine. The homepage of grapheneos says:
"The private and secure mobile operating system with Android app compatibility"
Surely you must understand that "security" and "giving users a say in how their phone works" are diametrically opposed? A phone can't be secure if its sandbox can be bypassed in one tap by the user. You might have a lot of say in how your linux system works, but don't kid yourself into thinking it's secure. It's only one `bash -c "$(curl -fsSL http://...` from getting pwned.
Try putting that sentence prominently on the front page of the GrapheneOS website and watch the monthly download count rapidly drop. It would not be out of place for an Apple press release, but it would be out of place there.
I think the Graphene people sometimes forget that the vast majority of their users are nerds who aren't being targeted by APTs, don't want to be locked out of their own device, and really just want a trustworthy Google-free OS on their phone. They also probably use Linux on their computers and yet haven't been hacked by "fake sudo" or "evil maid" attacks and likely never will be.
> It's not recommended, but you can install magisk + root if you really wanted to.
Apps will then either detect that you're rooted, or use AOSP attestation APIs to cryptographically verify that you aren't using a known-good custom ROM, and block your access to basic features of modern society such as mobile banking. This isn't Graphene's fault, but it should be noted that you will start losing out on things as soon as you start customizing or rooting the OS. So it does matter what upstream does to some extent.
FWIW I don't agree with the OP, just replying to your comment in particular.
We don't reduce the functionality or configuration of AOSP.
> I think the Graphene people sometimes forget that the vast majority of their users are nerds who aren't being targeted by APTs
The overall audience using it is not super technical. The community of people active in the chat rooms on Matrix and Discord really doesn't reflect the overall userbase. There are around 300k people using it, who largely went out of the way to purchase a phone for it and then installed it via the web installer. Many people also purchase devices with it preinstalled.
It's easy to use and we're focused on making it easier including filling in gaps like the recently added network location support which will be added to the initial setup wizard.
We also protect against a lot more than sophisticated targeted attacks against someone.
> don't want to be locked out of their own device, and really just want a trustworthy Google-free OS on their phone.
GrapheneOS exists to provide a high level of privacy and security while maintaining usability and app compatibility. It's working towards being as usable as the stock Pixel OS. It's meant to be an OS for everyone, we just don't have unlimited resources to quickly build most of the things we want. It has never been aimed at power users tinkering with and customizing their device. The level of functionality and usability we want to provide is the stock Pixel OS experience. Features unrelated to privacy or security which are not present in the stock Pixel OS are mostly out of scope.
> They also probably use Linux on their computers and yet haven't been hacked by "fake sudo" or "evil maid" attacks and likely never will be.
Software being open source doesn't mean it's trustworthy or privacy respecting. Running everything without basics like a strong app sandbox and permission model isn't a good idea on a desktop either. Linux doesn't imply not having a strong application security model.
Supporting and normalizing applications depending on having incredibly invasive access where they can access all of the user's sensitive data, etc. is the opposite of what we want to do. We don't see apps being able to request more invasive permissions and refusing to work without them as user control. User control is being able to avoid that without the app knowing. Giving root access to a huge portion of the OS and to apps is the opposite of what we're building. You seem to want GrapheneOS to be something it's not for an audience that it's not targeting. We never said GrapheneOS is for power users who want to have a bunch of customization and to grant more invasive access to apps.
GrapheneOS supports hardware-based virtualization across all the supported devices and that's the way people will be able to more freely do things like software development without compromising the security of the base OS.
> Apps will then either detect that you're rooted, or use AOSP attestation APIs to cryptographically verify that you aren't using a known-good custom ROM, and block your access to basic features of modern society such as mobile banking. This isn't Graphene's fault, but it should be noted that you will start losing out on things as soon as you start customizing or rooting the OS. So it does matter what upstream does to some extent.
Those apps wouldn't be willing to support GrapheneOS if we didn't maintain the standard security model. We're already going to be pushing the limits of what some apps will tolerate via our alternatives to permissions, etc. but we don't plan to eliminate parts of the security model. At the moment, nearly every app using the Play Integrity API would be willing to support GrapheneOS if they understood what it was and that they could verify it. It's an issue with lack of knowledge and unwillingness to do extra work for it rather than any apps actually wanting to ban GrapheneOS. It's something which can be addressed but it will get worse before it gets better as apps adopt the Play Integrity API. Growing the userbase by an order of magnitude or more will help solve this. Apps using the Play Integrity API are already feeling increasing pressure to permit using it and several have done so recently.
The vibe I generally get from Graphene users is that they feel that they are taking control over their device by installing Graphene onto it (which is almost always a manual process, at least for now). I probably exaggerated when I said the vast majority of users care deeply about this, but I think it's still a major selling point of Graphene for a lot of people.
And yes, I do agree that sandboxing actually provides more control to the user, not less! I'd just hate to see Graphene become more like iOS over time and start intentionally omitting features that would otherwise empower the user, for security's sake. If "security" and "giving users a say in how their phone works" really are diametrically opposed, and user freedom isn't a concern, then it would probably make sense to start gutting out stuff like developer mode, adb, and sideloading for the user's own safety. But the project's track record has been pretty good so far from what I can tell, and I don't think this will happen.
In very rare cases, someone complains about the removal of pattern lock, but it's a terrible feature and shouldn't be included in modern Android. It's a much worse variant of a PIN which gives people a false sense of security and encourages choosing an insecure lock method. We also didn't want to support it for our duress PIN/password feature or our upcoming random PIN/password generation feature. It's not really suited to either of those things. Pattern lock is genuinely an awful feature and shouldn't be included in modern Android, but they don't want to upset people by removing it. Extremely few people care that we remove it, and we've helped them by getting them to use a PIN instead especially if they use a proper random PIN.
> developer mode, adb, and sideloading
These things can be disabled with a device management app already, if what you mean by sideloading is installing apps via an APK or arbitrary app store. Sideloading an OS update to recovery has all of the usual signature verification and downgrade protection.
Absolutely not. With that logic, Google shouldn't allow people a say in what ROM it runs but I think the people in this thread are rather happy with having such choices
Absolutely not.
> A phone can't be secure if its sandbox can be bypassed in one tap by the user. You might have a lot of say in how your linux system works, but don't kid yourself into thinking it's secure. It's only one `bash -c "$(curl -fsSL http://...` from getting pwned.
In both cases, yes, a user may choose to bypass a security measure. In most threat models, that's fine. If malware needs me to give it permission to compromise the system, I consider that a secure system.
An independent mobile OS with platform-independent apps. No Apple/Google ID needed, no appstores. That was the point of this test install, and it worked.
One currently missing thing is a "transfer" or backup functionality otherwise. There's really no good solution other than to manually port over applications and use their built-in import/export features if available.
I've also done some image search and it does change a bit with apps and they look quite good. So I'm still baffled why this aversion to images is decided. Or just overlooked maybe?
> it does change a bit with apps and they look quite good
Hmm, I haven't noticed any difference. Which apps are you referring to?
Is that the default?
Furthermore, I'm interested in what their solution for email, calendars, and all the other Google services look like. If it's AOSP, that's a good reason not to use this ROM. I suspect it's not actually using AOSP's apps, though.
There are no built-in apps for that. The only custom apps GOS provides are Auditor (https://attestation.app/), Camera, Calculator¹, Contacts¹, Files¹, Gallery¹, Messaging¹, a hardened PDF viewer, and Vanadium (a hardened version of Chromium). Everything else is up to you.
¹) AOSP app or fork of the AOSP app.
I'd love to make the switch.
Audio quality is very good. By all means test it out in different configurations before relying on it.
A native implementation would still be better. I hope the GrapheneOS devs can pull it off.
1: Why? File management and getting files into apps is the #1 area where Android wins.
For example, iOS has me copying or saving audiobooks into a folder only to import them into BookPlayer, whereas Android’s Smart Audiobook Player lets me copy my book to my audiobooks folder and hit ‘rescan’.
Funnily enough, one of the only music apps on iOS that offers the same functionality - copy a folder into your library and rescan - is the same Neutron Player I used to use on Android. The interface is clunky, but that’s a small price to pay.
It is a bit fun that seemingly the best way to de-google and de-apple yourself is to buy an actual Google device and install grapheneos on it.
It hasn't happened in a year though and I've been happily upgrading lately. I'm not saying you couldn't have run into a unique bug but I'd find it surprising if your phone was really left completely bricked except for reflashing/wiping it.
Maybe there still was a way to salvage it, but I really can't tell in hindsight.
I totally understand giving up there though as it sucks to not be able to use the phone for a while and is very inconvenient. Let alone if this happens at an inconvenient time/during a work day, etc.
Leaving the device unlocked makes it far more likely something will go wrong and data will be lost. Disabling or revoking permissions from core system components which are not user-facing apps or making low-level changes with ADB to unsupported settings, etc. are other examples of how people can screw things up entirely on their own. If people disable something like the OS permission manager component and the OS can't boot anymore without a factory reset, that's not a bug. This is likely the kind of issue which happened to you.
We recommend against using developer options on a production device, particularly making changes with ADB. We also recommend against disabling core system components or their permissions in the Settings app via the Show system menus. Android allows users to break the OS via developer options or disabling core system components. It may not happen until after a reboot or update. We don't think the Android Settings app should allow disabling as much as it does but we didn't design that and taking away options from people in the GUI would make a lot of people angry even if it can still be done via ADB.
Not locking the device is an extremely poor security and robustness decision. It's not considered a completed GrapheneOS installation without locking.
> but honestly it shouldn't have happened to me either
It depends on what you changed. Android doesn't block power users from breaking the OS and needing a factory reset. That's not GrapheneOS specific. We did eliminate a few common ways people locked themselves out of their device like disabling the built-in keyboard if they use a different one which can then break or might not support running Before First Unlock via Direct Boot support.
I can't remember disabling any core system components, executing low level adb commands or any other unusual things which may have let to update breaking.
I think the error message that I got was the "No valid operating system found" one. Maybe the issue would have resolved itself, if I had rebooted my phone a few times more, through the A/B slot mechanic. I honestly didn't know all this in that situation and only found some vague forum posts about it. I think it would have helped if there was a bit of official documentation about boot loops and what to do when one occurs on the graphene os website.
The experience was for me a bit off putting because I lost some personal data (shame on me for not having proper backups), but after reading these comments I might try Graphene os again.
This doesn't mean that it was a GrapheneOS issue.
> I also agree that having a unlocked bootloader is a security risk
It's a major reduction in security. It completely ruins the defenses against data extraction and significantly reduces security against a remote attacker persisting access. It also reduces robustness.
> I can't remember disabling any core system components, executing low level adb commands or any other unusual things which may have let to update breaking.
Based on the error message you give below, it wasn't any of those things because the error message isn't from the OS and is from before the OS boots.
> I think the error message that I got was the "No valid operating system found" one.
This is an error message from the firmware indicating that there's no OS installed on the current slot. If that happened after an update, it would have automatically rolled back. What you're describing was either caused by a firmware bug or a hardware failure. It indicates data loss on the SSD. If you had the device unlocked and modified the OS, it indicates that went wrong. It's highly unlikely that this had anything to do with an OS bug or misconfiguration.
> The experience was for me a bit off putting because I lost some personal data (shame on me for not having proper backups), but after reading these comments I might try Graphene os again.
You're describing a Pixel firmware bug or hardware failure such as SSD data loss. It could have occurred with the stock OS too. It's not really feasible that it was an OS bug. The error is from the firmware, not the OS, and if the firmware was working properly with no hardware failure involved it would roll back automatically if it had happened after an update. If it wasn't after an update, then it indicates data loss for the existing OS images.
Having bootloader locked you get verified boot, big security benefits and automatic healing of operating system files damaged by the drive degrading.
Otherwise privacy and security would be meaning basically nothing.
All of the kernel drivers are open source, which would be the case for Snapdragon too.
Firmware is largely closed source but Pixels do use Trusty OS for the TEE and secure core, littlekernel as the late stage bootloader firmware and OpenTitan as the firmware/hardware basis for the Titan M2 secure element that's holding up much better to attacks than anything but Apple's SEP (see brute force info in https://discuss.grapheneos.org/d/14344-cellebrite-premium-ju... or the newer February 2025 documentation someone posted further down). We still do security research work on the hardware and firmware including reporting vulnerabilities and suggestions. Several firmware and hardware based features we've proposed were implementing including the pinning-based hardware attestation support we used to improve our Auditor app and AttestationServer, reset attack protection and various other things.
There are still shared source libraries and services for certain hardware but Pixels moving away from Snapdragon has led to that approach being on the way out. The move away from Exynos with the Pixel 10 should help.
If we make our own device with an OEM using Snapdragon, we'd have access to most of the sources for their driver libraries/services and a lot of firmware. It's not open source but OEMs have access. That also means a lot of it gets consistently leaked. They stopped sharing their radio firmware sources with OEMs because of those leaks.
Is it normal that phone OEMs have access to most of the source code of the kernel drivers and user space libraries provided by the SoC vendor.
I worked in the home router business and there it was normal that a OEM gets most of the kernel drivers and user space code in source code, but it was often restricted what they are allowed to publish in source code. Many vendors even published much less than they had to according to GPL and allowed by the SoC vendor.
I have heard that in the smart TV industry OEMs sometimes are only allowed to write an app and have no kernel source code access for their product.
You can build it for the emulator. It's straightforward to do, but it requires a lot of disk space and it will take around 40-60 minutes on a high end desktop CPU like a Ryzen 9950X. We don't publish official releases for the emulator at the moment because it's not intended for production use and isn't really a good experience to use. We could start doing it, but it'd add some extra work and we'd be concerned about people misinterpreting what it's meant to provide. Emulator builds don't have the regular security model intact or OS updates, etc.
You can test hardware attestation on any modern Android device but you'd need GrapheneOS on a real device to fully check that you have the SelfSigned fingerprint allowlist working properly. It wouldn't be hard to do it without testing it though, and our users can test if app developers ask our community on https://discuss.grapheneos.org/.
It ensures requests to your backend are vaguely from actual devices, rather than a bunch of emulators. There's many reasons why developers might want this. It significantly raises the bar for credential stuffing attacks, for instance.
Can't wait until we finally kill hacker culture for good. Everyone and everything will be fully secured. It's going to be beautiful. The nerds can cry about it all day long, but they're powerless to stop it.
Especially regarding:
- Usability of taxi apps like: Uber, Grab, Bolt
- Camera quality versus stock ROM
(Grab is like Uber/Bolt but used in different regions of the world.)
Camera quality of LineageOS was really bad.
A voyage was the catalyst for switching to iPhone as this seemed back then the best option to LineageOS and I couldn't risk not being able to use such logistically relevant apps.
Especially in Asia you have to be ready to install and use whatever app is required and not being able to might be seriously handicapping.
Camera quality is the same within the same app on either.
Pixel Camera can be used on GrapheneOS with full features and photo/video quality if you want it.
GrapheneOS Camera has support for HDR+ on Pixels for regular photos and has Night mode too. It has EIS and HDRnet for video recording. It has a single exposure slider rather than their dual exposure sliders. It uses each of the cameras via zoom level / light level in the same way. More advanced features and configuration are being added to it over time.
Pixel Camera has more features and the HDR+ it uses is more aggressive which makes the photos look higher contrast than a more natural look.
We're actively working on several major improvements including automatic generation of random passphrases and PINs, further improvements to VPN lockdown mode, per-app toggles for access to clipboard content from other apps to go beyond the existing restriction of only the focused app and keyboard being able to read it, etc.
You can look through https://github.com/GrapheneOS/os-issue-tracker/issues with the Feature type and enhancement label. GitHub unfortunately didn't provide a way to automatically migrate the older enhancement label to Feature type. We could use the API for it but haven't yet so you'll need to use both the old and new methods.
Photos in Pixel Camera look different because the HDR+ it uses by default is more aggressive resulting in higher contrast but a less natural look. Both are using HDR+ with hardware acceleration though. Videos are more similar and Night mode photos likely are too.
Pixel Camera can be used on GrapheneOS with full features and photo/video quality if you want it.
GrapheneOS Camera has support for HDR+ on Pixels for regular photos and has Night mode too. It has EIS and HDRnet for video recording. It has a single exposure slider rather than their dual exposure sliders. It uses each of the cameras via zoom level / light level in the same way. More advanced features and configuration are being added to it over time.
Pixel Camera has more features and the HDR+ it uses is more aggressive which makes the photos look higher contrast than a more natural look.
Note installing GrapheneOS doesn't involve rooting. Installing it uses an officially supported process and doesn't void the warranty. It preserves the standard security model and massively improves privacy and security on top of that (https://grapheneos.org/features). It's largely the opposite of most other alternative Android-based operating systems are doing with security.
Not sure if I'd use GrapheneOS even if it was available on other devices though. Really not a fan of the hostile attitude towards rooting when it's needed for basic functionality like backups — actual, reliable backups for every app, unlike those provided by the built-in solution.
> GrapheneOS is exclusive to Pixels because no other device has the same security features like bootloader relocking.
Sure, because they picked a set of features exclusive to Pixels. Nothing is stopping them from being more permissive about the security features they require.
I do understand why they chose to stick to Pixels; I think it was a mistake nonetheless.
Except for the fact that they don't want to be permissive to keep on being secure.
No, we don't do that. The security requirements are not exclusive to Pixels. Samsung flagships with an Exynos or MediaTek SoC have nearly every feature listed at https://grapheneos.org/faq#future-devices. They don't quite have proper updates and quality of implementation is an issue. If Samsung allowed us to properly support their devices, we would likely be supported a few Samsung devices. There are no other devices with a reasonable level of security combined with support for using another OS available for us to support. We've also made sure to keep the required support time at 5 years instead of 7 to allow for non-Pixel devices. Snapdragon still not supporting hardware memory tagging at this point is embarrassing for Qualcomm and it should be expected that it's supported at this point, especially since even MediaTek has it now. The OEM making that and other security features available is also needed.
> Nothing is stopping them from being more permissive about the security features they require.
It would not have our core feature set and comparable protections. It would not protect users from real world adversaries like Cellebrite and NSO in the way that it does right now. Our security requirements exist for a reason and major parts of GrapheneOS are built around hardware-based security features. If the device doesn't have hardware memory tagging, then how can we provide one of our main flagship features?
> I do understand why they chose to stick to Pixels; I think it was a mistake nonetheless.
It's strange that you keep mentioning this in the past tense. We support Pixels because they're currently the only devices providing our security requirements while permitting us to use them. If Samsung started permitting us to support their devices, we could support certain Samsung devices. There aren't currently any other devices meeting our requirements, but there isn't a reason to think that there won't be in the future. Our list of security requirements is a very reasonable list of industry standard features. Android OEMs largely aren't trying to provide reasonably secure devices and are not trying to compete with Pixels and iPhones on security. Samsung is an exception, but quality of implementation isn't as high and they're ruining the end result with the massive non-security changes they make that's massively expanding attack surface and making updates much harder.
You're not the target audience for this OS. Strong security guarantees require vertical integration.
If Samsung had allowed a non-stock OS to properly support devices like Samsung Galaxy Tab S10+ and Samsung Galaxy Tab S10 Ultra, we'd have been very interested. They did not allow it. They permanently cripple their devices if you unlock them. People should criticize Samsung for this rather than criticizing us for something we don't control. Companies like Fairphone are not realistically capable of building what we need due to lack of resources so there's little point in people bothering them about it.
My OnePlus3 (2017-ish?) can do that.
It's not even a feature, but standard android bootloader will do this much. Vendors deliberately remove such features, if not disable phone unlocking outright[0].
OnePlus supported it on several devices but then removed it in updates fixing serious security vulnerabilities. Their non-stock verified boot support was insecure and instead of fixing it they removed it. It's likely there wasn't a clear or possible way to fix it due having a poor implementation which never worked properly. Fairphone 4 had a completely insecure implementation of verified boot trusting publicly available AOSP test keys. Having support for it really doesn't mean it works or will even keep appearing to work in future updates.
It's also just one feature. Our overall hardware security requirements are listed at https://grapheneos.org/faq#future-devices. People focus too much on relocking the device but we require a lot more than that. There are non-Pixel devices with essentially all the features we require such as the Samsung Galaxy S10+ and S10 Ultra but they don't allow using another OS without losing the security features. The updates are also still not what we expect, but if Samsung actually make it possible to support their devices we could accept some compromises. On the other hand, supporting far less secure devices missing things we consider hard requirements like memory tagging needed to provide our core feature set doesn't interest us.
I previously documented this here: https://web.archive.org/web/20250120181249/https://divestos....
Pixels are the only available smartphones meeting our hardware security requirements while permitting us to use the hardware-based security features. Our requirements are very reasonable and listed at https://grapheneos.org/faq#future-devices. Recent Samsung flagships using an Exynos or MediaTek SoC have essentially all the security features on this list on paper. However, Samsung doesn't let us support their devices. Samsung cripples the device if you use another OS, mainly by disallowing using security features. Some of it is permanently disabled even if you go back to the stock OS and lock it again. There's an eFuse they refer to as the warranty bit which they burn when you unlock, crippling the device forever.
The audience using GrapheneOS has become much less technical over time as usability and app compatibility has greatly improved. Installation via the web installer is something many very non-technical people are regularly doing successfully, largely without help. 24/7 real time help with installation is available via our chat rooms. Our overall audience is less technical than you think. The chat rooms attract a more technical subset of the community and isn't really representative.
Pixels have digital USB-C audio output and DisplayPort alternate mode support. They have the start of a proper desktop mode and hardware virtualization support for running applications from other operating systems. In GrapheneOS, that can already be used for GUI applications with speaker, microphone and opt-in GPU acceleration support. Analog 3.5mm audio output isn't something people focused on bleeding edge technology want. Audiophiles never wanted to use low quality DAC in the phone but rather a high quality one connected via USB-C with digital audio output.
> Really not a fan of the hostile attitude towards rooting when it's needed for basic functionality like backups — actual, reliable backups for every app, unlike those provided by the built-in solution.
GrapheneOS has a built-in encrypted backup system which uses the device-to-device mode. That's the mode Google Play services uses on Google Mobile Services devices when you transfer to a new device. It does back up every app, they can't opt-out of it. They can explicitly exclude data from device-to-device backups which is non-portable or shouldn't be used across devices such as a device-specific login token. The previous systems for opting out of backups or excluding files only exclude them from cloud backups now.
Some apps like Signal encrypt their data themselves as an additional layer so no backup system other than the one built into their app is going to back that up and restore it in a useful way. Transferring data encrypted with a hardware keystore key which then can't be read/used by the app wouldn't be helpful. Transferring device-specific login tokens, etc. isn't wanted. The way the standard backup infrastructure is designed in Android is the right approach since Android 12. It does work well. The current backup service we're using is not a great implementation of it but has gotten better. We intend to completely fork it and massively overhaul it at some point. It was originally written by a GrapheneOS user for GrapheneOS but it got largely taken over by others and we don't agree with their approach or choices for it, so we'll be forking it.
That's a very recent feature, isn't it?
> They can explicitly exclude data from device-to-device backups
Curious how many apps abuse that for purposes beyond the original intention? The big/popular apps etc? Ie what will be the real world experience despite this new feature
Android 12 theoretically added it but it didn't fully work yet and apps needed to start targeting Android 12+. Then, the backup app needed to add it which took a long time, so it's fairly recent as in within the past 2 years.
> Curious how many apps abuse that for purposes beyond the original intention? The big/popular apps etc? Ie what will be the real world experience despite this new feature
Many apps use the older system to disable backups or exclude files which only applies to cloud backups now. Most apps don't exclude files from device-to-device backups improperly. Excluding device-specific login tokens, caches, etc. is how it's intended to be used. It annoys people they need to login to apps again after a transfer but that's generally how those apps want their security model to work so there's an entry for each login session and logging out of it only logs it out on 1 device.
Apps can exclude files and define their own backup agent for handling converting to and from a portable format. Chrome does this to backup Android-specific settings, etc. not handled by Chrome's Sync feature. This means non-Chrome Chromium-based browsers largely lacking sync have poor backup support. We plan to address this in Vanadium but haven't decided how we want to approach it yet.
It does work well. People mostly have a good experience with device-to-device transfer with Google Mobile Services devices now. Certain apps like Signal or TOTP apps using the hardware keystore inherently can't be backed up this way. Signal doesn't use it in a sensible way for security and really just seems to have introduced hardware keystore based encryption to prevent using root-based backup systems not taking into account which data should be backed up or not backed up. They don't trust the OS backup infrastructure particularly since OEMs can include sketchy backup services so they don't want that to work either.
Compare that to other custom ROMs, where you typically depend on volunteers maintaining the various devices. Sometimes people decide to step down, and suddenly find your device unsupported. This happened to me with LineageOS/CyanogenMod.
My understanding is also that the OEM ROMs of Pixel devices are closer to AOSP than those of other vendors like Samsung. This simplifies the maintenance of the ROMs, and enables the project to develop meaningful features instead.
We can't safely use a device where they might patch out support for what we rely on. As an example, OnePlus patched out support for alternate OS verified boot due to serious security vulnerabilities with how they'd implemented it. Operating systems relying on it would no longer be able to update the firmware, leaving them insecure, but yet the verified boot never worked properly anyway so it ended up worse than them not trying in the first place.
Realistically, what we expect is that Pixels are the only devices we're not involved in making which we'll be able to support for the foreseeable future. To support other devices, we need a partnership with a competent OEM like Samsung. We can raise money to pay the usual licensing fees for platforms and then work with them where we have paid support so they aren't going to break things for us, drop update support unexpectedly, etc.
> To support other devices, we need a partnership with a competent OEM like Samsung.
How realistic would it be to have an official Graphene phone? Could you partner with an open-source friendly company like Purism or Framework to design and manufacture the hardware to your specifications? That would be the ultimate mobile device for tech and privacy nerds, for which I'm sure many would be willing to pay a premium over mass manufactured devices.
As much as I trust your vetting of Google devices, there's a strong incongruity between the mission of a trillion-dollar adtech company and yours that I just can't reconcile.
> As much as I trust your vetting of Google devices, there's a strong incongruity between the mission of a trillion-dollar adtech company and yours that I just can't reconcile.
Apple and Google provide a high level of security for their mobile devices. Other OEMs aren't on the same level. Samsung is the only one that's even remotely close. We'd love to work with Samsung but wanting to do it doesn't mean they will work with us. We could potentially pay them to build a device for us if we raised enough money in advance. We choose devices based on their security and other properties along with the actual record of the company making it. Corporations are amoral profit seeking entities in general. That's not something specific to Google.
> Could you partner with an open-source friendly company like Purism or Framework to design and manufacture the hardware to your specifications?
Framework doesn't currently build devices close to meeting our requirements but is not anti-security or misleading people like Purism. We wouldn't have any issue working with them, we just don't really expect them to start building what we need any time soon.
Purism has extremely anti-security practices and makes extraordinarily insecure devices incredibly far from meeting our requirements. They purposely choose low security components and don't provide important updates. They even block providing the updates from the OS. We'd much rather support a low-end Motorola phone with only 2-3 years of support than a Purism device because they're so much less secure than mainstream hardware. Purism has 0 days of update support for their products in the sense that we require.
We don't consider Purism to be a privacy friendly company due to the atrocious security of their products and services. The software they use on top is also far less private and secure than the Android Open Source Project. It's largely the complete opposite of GrapheneOS. They also do a lot of false marketing that's directly harmful to us such as their false claims about cellular radios. In reality, their device has a much less secure cellular radio with far more attack surface exposed from the OS than an iPhone. It's less isolated, not more isolated, and yet they've convinced many people otherwise with their marketing and done harm to the whole space with the misconception people now have. The same applies in other areas.
If we partnered with Samsung, people would know they're going to get a good product and that the company making the hardware would still be around providing support years later. If we instead partnered with a company known for not shipping people what they ordered and not providing what was claimed in the promotional material, that would be very hard for people to trust. Our community would be shocked and incredibly disappointed if we did that.
Jesus Christ, this again. Just buy good wireless headphones already, gramps.
Then what to do when the battery dies? They only a last a couple of years. I can replace my phone pretty easily, but how can I find another pair of earplugs? That's a process I don't want to go through again. The human-device interfaces should just work.
The only other solution I have found is a USB-C-to-3.5mm dongle but then the phone doesn't fit comfortably in my pocket anymore, and it's very inconvenient when running.
> The only other solution I have found is a USB-C-to-3.5mm dongle but then the phone doesn't fit comfortably in my pocket anymore, and it's very inconvenient when running.
Get USB-C headphones rather than a DAC so that the DAC is in the headphones. There are high quality ones including earbuds.
I literally mean this.
I'm sure there are valid technical reasons for removing the 3.5 jack, and I have adapted my headphones to the new situation, but man do I hate it.
Interesting that someone would say this. I’ve had several Nexus and Pixel phones in the past (last one was a Pixel 2) and they were all pretty bad in terms of hardware and the support from google was non existent. I only bought for them for the software… which wasn’t great either. They have always been mediocre phones, to put it mildly.
What I noticed though is that Google often tries to upsell based on software features alone. For example, there is really no point in buying a Pixel 9 Pro instead of a base Pixel 9 as the hardware is practically the same except certain things. But Google markets the Pro model with more software based AI features. When installing GOS this really doesn't make a difference so one can always opt for the more inexpensive models.
The base devices are better value but the Pro devices do mainly differentiate based on hardware. Better display, addition of the 5x telephoto camera, better front camera and more memory are the main selling points. Pixel 9a is similarly a downgrade for the screen, cameras, memory, wireless charging speed and cellular radio (back to a variant of the 7th/8th gen Pixel radio). Pixel 9a has very good value but the cellular radio downgrade is a big one which people may care about more than they realize due to how it impacts battery life when using 5G.
GrapheneOS includes a fork of the open source TalkBack. You need a text-to-speech implementation such as Google's Speech Recognition & Synthesis, RHVoice or eSpeak NG too. None of those is suitable for inclusion in GrapheneOS due to licensing and other reasons. There are some promising new apps based on more modern approaches which we're keeping an eye on. We may make our own text-to-speech and speech-to-text similarly. We recently built our own network location implementation in the OS and are building our own network location database/service with full offline support. The same thing is probably needed for TTS and the other direction.
You can install Google's Android Accessibility Suite for the full proprietary feature set including extended TalkBack features. It works fine on GrapheneOS. It needs sandboxed Google Play for the full feature set.
Why build your own instead of working with BeaconDB? Or if you predate that project, vice versa: will this be an open dataset that other projects can use and contribute back to?
I tried looking up more info about it but DDG only comes up with forum threads about workarounds