[0] https://grapheneos.social/@GrapheneOS/113917226566692707
Not really just handing it to you https://arstechnica.com/gadgets/2025/03/how-google-nerfed-my...
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.
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.
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.
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.
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.
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.
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 >>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.
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.
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.
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.
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.
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
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/.
Many seem to work, if you apply some tweaks. Google Wallet NFC payments totally don't, I believe.
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...
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].
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.
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.
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).
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.
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?
I previously documented this here: https://web.archive.org/web/20250120181249/https://divestos....
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.
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.
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.
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.
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).
Side note, balatro-mobile-maker works really well as an unofficial port to Android. https://github.com/blake502/balatro-mobile-maker
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).
Is that the default?
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.
https://github.com/lukasstraub2/intercept-anything
Go is hardly the only thing where LD_PRELOAD doesn't work.
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 :-)
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.