Experimental release of GrapheneOS for Pixel 9a

icard NFC payments also work fine

Dutch banks did this, it is called iDeal: https://www.ideal.nl/en/

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.

Banks do that for p2p payments and e-commerce (like iDeal mentioned by sibling comment or BLIK in Poland).

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.

Generally what you're describing is in countries that don't have widespread adoption of NFC payments. In Europe almost every country has standardised NFC payments so Apple/Google Pay is the most frictionless option for users.

I agree, but in this banking apps (around me) use the Integrity API anyway.

> 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.)

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.

The app crashes I found were always due to the additional security hardening features in GrapheneOS. You can toggle these individually for each app.

I did using their website form. It needs to be clear from the complaint that Google is violating fair market principles. They also like details about what exactly is happening and who is affected. That was why they called me after I filed the complaint.

Yea, I really don't understand how using a phone is any simpler than just tapping my debit card at the terminal. There's no way in hell I'm letting Google anywhere near my personal finances.

GrapheneOS has various features requiring hardware integration. Our hardening features also uncover bugs across the code especially in drivers, especially the hardware memory tagging integration in our hardened_malloc project and the standard Linux kernel hardware memory tagging support we use in the kernel. Pixels are very similar to each other though so this work is largely but not entirely done for them.

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.

Reminds me of iOS and iDevices and how even after months they keep stabilising and then they fail to stabilise and then they release the next version after a year with all those bugs intact and accumulated. In this case that OS is literally made for only those devices and vice-versa, in iron claw control of one control freak corporation that has a net worth more than GDPs many countries would nuke for.

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.

All Android devices support running the Android Open Source Project via Treble and we could quickly add support for non-Pixel devices doing things in a reasonable way too. Those devices don't meet our hardware security requirements (https://grapheneos.org/faq#future-devices) which is why we don't support them. It wouldn't be that hard to add a Sony or Motorola device but they're missing the expected security features and proper updates. It wouldn't be possible to provide our standard security protections on them which is the real blocking issue, not difficulty. Android has made device support simple, but the rest of the Android device ecosystem is not at all competitive in security with Pixels and iPhones.

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.

?

As in the OS in question is GrapheneOS itself?

The changes are overstated and it really changes very little for GrapheneOS. See https://discuss.grapheneos.org/d/21315-explanation-of-recent....

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).

Oh wow, how did I miss that! If strcat / Daniel Micay happens to pass by: How much will this impact future development of GrapheneO?

Android Open Source Project and operating systems based on it like GrapheneOS are Linux distributions. The kernel drivers are Linux kernel drivers. The userspace drivers are part of Android's Treble hardware abstraction layer providing forwards compatibility with future Android releases and SELinux-based sandboxing with the drivers split up into isolated processes. Most of the driver complexity is in userspace with most kernel drivers acting as shims between the isolated drivers and the hardware. It's done that way for practical reasons on Android but it's good for security.

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.

That's not at all normal. Sandboxed Google Play doesn't consume more batter than privileged Google Play in a standard Google Mobiles Services device. It indicates something is very wrong with your setup.

Online banking (anecdotally) works great, though may use the sandboxed google play services. At least here in Switzerland with Swiss banking apps I've never had issues with it.

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.

The fixing offer is only valid in some locations, would require you to be without your phone for some time, and since Android still doesn't have anything that would be considered working backup and restore, I can't imagine many people being comfortable mailing their phone out for a replacement.

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).

> 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...

They never ack'd the reason why they did it. My wife's phone was basically bricked, and the google offer for "free fix" was functionally worthless because the contracted companies wouldn't repair it. See many articles online (including ars technica editor who personally was screwed).

I don't have any idea what the situation is here and whether it's as black and white as you paint it, but regardless, surely something as significant as this should be presented to the user as an option rather than the manufacturer deciding for you that your phone that you own and paid for should now be unusable?

I was never even notified for my 4a and when I try to check it's eligibility it simply says my pixel 4a "is not eligible for a repair, cash payment, or discount." without any additional information.

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? ¯\_(ツ)_/¯

I just bought a replacement battery from ifixit and replaced it myself as the original battery was worn out only to now suddenly have garbage battery life on a brand new battery for no good reason.

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.

That sounds really good. What are the downsides? How does it fare in terms of PlayIntegrity and SafetyNet etc?

Do you think you are target (idk, by maybe three letter agencies or black hat groups) for the work you do? Do you have any special OPSEC to account for something like this?

> Graphene is not for everyday casual users.

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.

Not sure if you've used GrapheneOS recently? If apps are heavily tied to Google Play Services you can install that and, in the vast majority of cases, get very good compatibility.

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.

So, is the current recommendation to create such a backup to an external storage and then restore it on a new device? There is currently no direct device-to-device transfer feature using this, correct?

It would answer my question properly if I'd seen that it looks just like the stock Android UI, so even though it's almost exactly the same, that's still quite valuable for me rather than pointless.

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's still a custom ROM and it's not uncommon for those to be reskinned in interesting or weird ways. Plus, their website already uses the outline of a phone with their logo inside of it, why not make that a screenshot of their ROM with their logo as a background?

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.

I have a question you may be able to answer. Are contributions to GrapheneOS in general welcome? If yes, where would one start, is there a page about setting up a development environment or outlining a list of features/areas that could need work/help? I have quite a few spare Pixel phones that are currently just idling but I'd love to try building and installing GOS myself to start out.

Does it record 2-way audio in good quality? Ear & speaker & Bluetooth

https://f-droid.org/packages/com.github.axet.callrecorder

I wonder how much Google actually makes on these. I won't be surprised if they basically make nothing on them.

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.

> 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.

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.

Interesting. I used to have problems using such apps on LineageOS due to their dependence on this Google Push Messaging service (don't remember what it's called) and also dependence on Google Maps services.

(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.

GrapheneOS Camera does have HDR+ and Night mode on Pixels along with HDRnet and EIS for videos. Pixel Camera has more features and more aggressive HDR+.