GrapheneOS

HN discussion of an LWN article.

https://foxnews.com/tech/new-android-attack-tricks-you-giving-dangerous-permissions

GrapheneOS, a security-focused operating system based on Android, confirmed that its current version is also affected. However, it plans to release a fix in its next update.

No, we said that on July 7 and then shipped https://grapheneos.org/releases#2025070700 fixing it.

They likely found https://x.com/GrapheneOS/status/1942235186923499549 but didn't realize our next release was shipped later that day. The TapTrap site from the researchers at https://taptrap.click/ documents that we fixed it. Our fix works well and many users tried the proof of concept app to confirm it.

Android 16 was released June 10 and we'd already done our final Android 15 QPR2 releases with backports of Android 16 drivers/firmware when we were informed about TapTrap near the end of June. Once our port to 16 was near Stable, one of our devs spent a few hours fixing TapTrap.

The researchers reported it to Android on October 31, 2024 and Android still hasn't fixed it. We fixed the vulnerability by only allowing third party apps to use custom activity animations for their own activities. It's likely Android doesn't want to remove part of the feature.

Changes in version 4:

• temporarily allow Dynamic Code Loading via memory for the sandboxed Play Store by default until it's resolved upstream or by us coercing it to stop doing it (users can still disallow Dynamic Code Loading via memory for it as it doesn't appear to cause many issues but we don't want to have errors occurring for regular users)
• update Gradle to 8.14.3
• update Android Gradle plugin to 8.11.1
• update Protobuf Gradle plugin to 0.9.5
• update Protobuf library to 4.31.1
• update Kotlin to 2.1.21
• update SDK to 36 (Android 16)
• update target API level to 36 (Android 16)
• switch modern Gradle Java toolchain configuration
• improve code style

A full list of changes from the previous release (version 3) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.

Tags:

• 2025071900 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, Pixel 9a, emulator, generic, other targets)

Changes since the 2025070800 release:

• Dialer: always show scrollbar for button grid when there are more than 6 buttons to make it clear it can be scrolled
• Dialer: move RTT button to the end since it's rarely used
• Network Location: improve position estimation implementation to provide better performance, accuracy and stability
• Network Location: add support for detecting location based on cell towers when Wi-Fi-based location can't obtain any position estimate
• add back "Prevent ringing" gesture via Power + Volume Up which was lost in the port to Android 16
• Settings: fix discharge time estimates not being shown when charging optimization (charging limit) enabled
• Settings: avoid explanation in per-app Play Integrity API settings being cut off
• fully prevent empty end session button being shown
• kernel (6.1): update to latest GKI LTS branch revision including update to 6.1.145
• kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.98
• include more color overlays from the stock Pixel OS
• add back desktop mode toggle to developer options which was missing due to Android 16 requiring enabling config_isDesktopModeDevOptionSupported in addition to the config_isDesktopModeSupported feature we were already enabling
• adevtool: add infrastructure for defining synthetic overlays and migrate to using it (automates more of device support and results in the battery charging limit text being updated)
• adevtool: heavily optimize state collection by only calculating what gets built instead of building it
• enable optimization of pausing wallpaper rendering for Pixel Camera
• Terminal (virtual machine management app): temporarily disable GUI support until Android 16 regression causing surfaceflinger crash is resolved
• Seedvault: update to 15-5.6 (will be replaced with a better backup implementation in the future)
• Vanadium: update to version 138.0.7204.157.0
• GmsCompatConfig: update to version 159

Apple and Google both provide support for offline speech-to-text using local models. Users can configure it to be fully offline.

The Murena Voice to Text service in /e/OS sends the user's audio to OpenAI which is hidden away in their terms of service:

https://community.e.foundation/t/voice-to-text-feature-using-open-ai/70509

/e/OS is heavily marketed as private but in reality it has enormous privacy issues like this with their default apps and services. It's also heavily marketed as avoiding Google services but yet has privileged integration for Google services and connects to multiple by default.

/e/OS doesn't keep up with basic privacy or security patches for the OS or browser engine used not only for the default browser but also the WebView used by many apps including email clients and far more for rendering web-based content. For more info see https://discuss.grapheneos.org/d/24134-devices-lacking-standard-privacysecurity-patches-and-protections-arent-private.

/e/OS is not a threat to mass surveillance but rather significantly helps with it by making exploiting devices to extract data or take remote control over them far easier. They do not keep up with basic High and Critical severity patches. All devices sold by Murena are insecure.

Even on Pixels, /e/OS is extremely far behind on providing the current High and Critical severity privacy and security patches due to being so far behind on OS updates. They mislead users by setting a fake security patch level and changing the UI to mask what's happening.

Murena is a for-profit company and /e/OS is very clearly built and managed for the benefit of Murena. Despite this, /e/OS receives a huge amount of EU government funding. If you're an EU taxpayer, your money is being used to build this extraordinarily insecure and non-private OS.

Changes in version 159:

• add stubs for AdvancedProtectionManager which was preventing us moving the post-Android-16 sandboxed Google Play services to our App Store's Stable channel (GrapheneOS enables far better security features by default with per-feature and per-app controls where that makes sense instead of the all or nothing iOS Lockdown Mode approach copied by Android 16 which we don't plan to imitate)
• update target API level to 36 (Android 16)
• update Android Gradle plugin to 8.11.1
• update Gradle to 8.14.2

A full list of changes from the previous release (version 158) is available through the Git commit log between the releases (only changes to the gmscompat_config text file and config-holder/ directory are part of GmsCompatConfig).

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release.

GmsCompatConfig is the text-based configuration for the GrapheneOS sandboxed Google Play compatibility layer. It provides a large portion of the compatibility shims.

We published this response to a recent article promoting insecure devices with /e/OS with inaccurate claims, including inaccurate comparisons to GrapheneOS:

https://discuss.grapheneos.org/d/24134-devices-lacking-standard-privacysecurity-patches-and-protections-arent-private

The founder of /e/OS has responded with misinformation promoting /e/OS and attacking GrapheneOS.

We made a post with accurate info on our forum in response to inaccurate information, that's all. There's a lot more we could have covered. See https://kuketz-blog.de/e-datenschutzfreundlich-bedeutet-nicht-zwangslaeufig-sicher-custom-roms-teil6/ for several examples such as /e/OS having unique user tracking in their update client not communicated to users.

The founder of /e/OS responded to the post we made on our forum here:

https://mastodon.social/@gael/114874688715085353

Gaël Duval has repeatedly personally targeted the founder of GrapheneOS in response to us posting accurate information responding to misinformation from /e/OS and their supporters.

Contrary to what's claimed in this thread, /e/OS does not improve privacy. /e/OS massively reduces privacy compared to the Android Open Source Project in multiple ways. /e/OS is consistently very far behind on shipping important privacy improvements in new major Android releases.

/e/OS regularly lags many weeks, months and even years behind on shipping important privacy and security patches. They roll back various parts of the privacy and security model, add a bunch of privileged Google service integration and their own privacy invasive services too.

The link posted at https://mastodon.social/@gael/114875028964272029 shows /e/OS shipping the previous round of Chromium privacy/security patches a couple weeks late. It regularly takes them months instead of weeks. They take far longer to ship many of the important driver, firmware and AOSP patches.

The link also shows they're using the wrong Chromium tags for Android and frequently results in missing Android-specific privacy/security patches. Chromium 138.0.7204.97 was a June 30th release for Windows, not Android. The Android tag for June 30th was 138.0.7204.63.

https://chromereleases.googleblog.com/2025/07/stable-channel-update-for-desktop_15.htmlhttps://chromereleases.googleblog.com/2025/06/chrome-for-android-update_30.html

Patches in Chromium Stable channel updates for Android are often only in the Android tags, not the Windows ones.

The current Android release is 138.0.7204.157, with security patches beyond 138.0.7204.63:

https://chromiumdash.appspot.com/releases?platform=Android

These were minor releases of Chromium. It's trivial to incorporate the changes and ship them on release day within hours. Even major releases of Chromium every ~4 weeks are easy to ship on release day because major releases are open source for weeks in advance, unlike Android.

As can be seen by looking back through https://github.com/GrapheneOS/Vanadium/releases and comparing it to the Android release dashboard linked above, we ship the Chromium Stable and Early Stable releases on release day. This is not impressive. Shipping privacy/security patches is the bare minimum.

Our forum post and this thread were both posted in response to inaccurate info about GrapheneOS posted to promote /e/OS. Once again personally targeting our founder with fabricated stories and harassment from their community is what /e/OS has done before and continues doing.

/e/OS targeted the founder of DivestOS in a similar way and /e/OS supporters directed a massive amount of harassment towards him. It played a significant role in DivestOS being discontinued. /e/OS will not achieve the same thing targeting our founder and should stop doing it.

/e/OS is extraordinarily insecure and non-private due to lagging so far behind on patches and crippling Android Open Source Project privacy/security protections. Selling many devices many months or even years of missing Critical severity patches and hiding it in the UI is wrong.

Murena's services are not nearly as private as claimed and not at all on the same level as serious options such as Proton's software suite. Many of their services recently went down from early October 2024 through March 2025:

https://community.e.foundation/t/update-on-murena-io-service-outage/61781

It's somehow a paid service.

Swissquote Bank is in the process of adding official support for GrapheneOS to their main app. They've published a Beta version of the app with GrapheneOS support for us to share with our users. Can use https://appdistribution.firebase.google.com/testerapps/1:922102381011:android:b7cac4eab8e5776d/releases/4rp8ha7plvg00 to obtain it via the sandboxed Play Store.

Swissquote previously added GrapheneOS support to their Yuh financial app. They're following our guide on using hardware attestation as an alternative to Play Integrity able to support more than Google Mobile Services hardware and operating systems: https://grapheneos.org/articles/attestation-compatibility-guide.

The link we provided might not work in Vanadium since Firebase appears to use the Client Hints headers to detect the OS version. We set the OS version in the Client Hints headers to the frozen User Agent value which is Android 10. May need to install and use Chrome to access it.

We've previously seen an issue where a site used the Client Hints provided OS version to ban using incredibly out-of-date Android versions. We didn't remove the Client Hints headers because that trips bot detection. Reusing the frozen User Agent values was working quite well.

A Dutch bank (Triodos Bankieren NL) has added explicit support for GrapheneOS and will be testing it going forward:

https://github.com/PrivSec-dev/banking-apps-compat-report/issues/133#issuecomment-3087638715

They join a growing number of banking apps actively permitting users to use a much more secure device instead of trying to ban it instead.

Every single time I get out of my car I get this damn notification asking to rate my audio quality on my drive.

Doesn't matter if I answer the survey or not it always asks every time. It's driving me nuts, I don't want this unnecessary notification on my phone every time I get out of my car. Going to the notification settings for the app for Feedback & Surveys, you can't disable them. They're locked to always being on.

Is there a workaround for this? Do I need to submit a ticket with GrapheneOS to maybe get this looked at? Is it simply out of GOS's control because Google sucks?I use Android Auto all the time and this is exhausting. I'm a person who doesn't like unnecessary notifications, only like 4 or 5 apps are allowed to send notifications on my phone. Searching this issue just pulls up r*ddit threads from 5 years ago that have deleted comments or outdated answers or just how to disable AA entirely.

Any guidance or suggestions greatly appreciated 🧡

I'm assuming I'm tethering the tablet to the phone via hotspot. Both devices are running GrapheneOS.

We've published a response with corrections to iFixit article presenting a highly insecure and non-private option as being the best choice for people who care about privacy:

https://discuss.grapheneos.org/d/24134-devices-lacking-standard-privacysecurity-patches-and-protections-arent-private

Not bundling Google Mobile Services doesn't mean a device/OS has good privacy.

Changes in version 138.0.7204.157.0:

• update to Chromium 138.0.7204.157
• change default value for "Protected content" (DRM) site setting to ASK instead of BLOCK (we changed this from ALLOW to BLOCK because ASK wasn't an option at the time we changed it)
• stop marking 64-bit-only builds as multiArch to enable installation on devices supporting 32-bit apps such as 6th generation Pixels
• use Vanadium Config version as the subresource filter rules version instead of having a separate version for it

A full list of changes from the previous release (version 138.0.7204.63.0) is available through the Git commit log between the releases.

This update is available to GrapheneOS users via our app repository and will also be bundled into the next OS release. Vanadium isn't yet officially available for users outside GrapheneOS, although we plan to do that eventually. It won't be able to provide the WebView outside GrapheneOS and will have missing hardening and other features.

I know it's on F-Droid but it is very old. I try using Obtainium, but there's no apk for it on GitHub. Not sure it would even work on latest GrapheneOS. Anything similar in free/libre?

Thanks.

I have a lot of Apps on my Android that are essential to me (authenticators, finance management apps, etc.). How can I verify if they will work on Graphene/are even able to be installed?

Tags:

• 2025070800 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, Pixel 9a, emulator, generic, other targets)

Changes since the 2025070700 release:

• update to BP2A.250705.008 vendor files (July 2025 Pixel monthly release)
• disable temporary unconditional system crash notifications since we've gotten the initial feedback we needed since releasing our port to Android 16 (users can enable this themselves via Settings > Security and privacy > More security and privacy > Notify about system process crashes)
• NFC: always show standard confirmation dialog before opening a URL instead of it only being enabled for a small subset of users
• temporarily remove NFC auto-turn-off feature since it can cause NFC HAL or system_server crashes in rare edge cases and we need to entirely reimplement it inside of the NFC APEX module to avoid the problems (there were rare issues reported prior to Android 16 but 1 user reported an NFC HAL crash loop on Android 16 making it clear we need to drop this until we redo it in a better way)

GrapheneOS is currently under a state sponsored attack attempting to misrepresent it as being for criminals, which we covered a bit at https://grapheneos.social/@GrapheneOS/114784469162979608. These poorly researched, biased and inaccurate news stories have led to more harassment towards our community and team.

These attacks are taking a multi pronged approach including pushing existing fabricated stories and harassment towards our team. We'd appreciate if our community was more active than usual in debunking misinformation and attacks on our team. It's a very abnormal wave of attacks.

GrapheneOS based on Android 16 has been through extensive public Alpha/Beta testing and should reach our Stable channel today. We'll continue fixing various upstream Android 16 regressions such as the back button issue impacting the stock Pixel OS we fixed in our latest release.

July Android Security Bulletin will likely be published today. We obtained early access to the signed partner preview and confirmed no additional patches were required, so we set the 2025-07-01 patch level last month after we backported Pixel 2025-06-05 driver/firmware patches.

Tomorrow will likely be the first monthly update of Android 16 with a new Android Open Source Project and Pixel stock OS release. We won't need to backport Pixel driver/firmware patches since we're on Android 16 and can simply incorporate and ship the monthly update within hours.

It can be extraordinarily difficult to backport driver/firmware patches due to dependencies on the new major release. We were only able to backport everything required for the 2025-06-05 security patch level because Android 15 QPR2 is much closer to Android 16 than Android 15.

After our Android 16 port was completed yesterday, we started fixing an Android tapjacking vulnerability disclosed last month:

https://taptrap.click/

We have a fix implemented and it will be included in our next release, likely with the monthly Android 16 update tomorrow.

This vulnerability was disclosed to Google in October 2024 and Android still hasn't fixed it. Security researchers should report vulnerabilities to GrapheneOS in addition to Google. This now joins our many other GrapheneOS exclusive fixes for serious Android vulnerabilities.

We've decided to make another release today with our fix for the Android tapjacking vulnerability because we need to fix a DisplayPort alternate mode regression specific to 8th generation Pixels which doesn't impact 9th generation Pixels.

Tags:

• 2025070600 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, Pixel 9a, emulator, generic, other targets)

Changes since the 2025070500 release:

• backport fix for back button regression in Android 16 from Android 16 QPR1 Beta 2.1
• Pixel 8, Pixel 8 Pro, Pixel 8a: restore using asymmetric MTE mode for userspace instead of the default asynchronous mode
• add back switching to using the Natural display color mode by default
• migrate more device support to adevtool and remove more unused configuration
• improve per-device integration for USB-C port control and pogo pins control to make maintenance easier
• adevtool: remove obsolete overlay handling implementation
• remove Circle to Search feature declaration
• enable Runtime Resource Overlay (RRO) enforcement

Tags:

• 2025070500 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, Pixel 9a, emulator, generic, other targets)

Changes since the 2025070301 release:

• partially revert upstream changes in Android 16 breaking parts of the lockscreen layout including the date and media info
• Pixel 8 Pro, Pixel 9 Pro, Pixel 9 Pro XL: add back feature declaration for Pixel Thermometer support lost in our Android 16 device port migration which prevented fresh installs of the app
• Terminal (virtual machine management app): disable VM console feature since it isn't supported by the stable release of Android 16 outside of debug builds and trying to use it breaks installing the new images (the feature can be enabled once the core OS supports it in production builds)
• update Pixel HAL compatibility matrix version numbers for Android 16
• add lockscreen synchronization failsafe to protect against unknown vulnerabilities
• improve code quality and add unit tests for our strict CVE-2024-50089 protection
• kernel (6.6): update to latest GKI LTS branch revision including update to 6.6.94
• fix port of our 2-factor fingerprint authentication tests to Android 16

GrapheneOS based on Android 16 is now available in our Beta channel. There are 2 main known issues which will be fixed in the next release: lockscreen date and media info are not properly displayed due to an upstream AOSP bug and Pixel Thermometer doesn't appear in our App Store.

Last month, we provided the 2025-06-01 Android/Pixel security patch level early in the month before the stock OS release as preparation and then backported Android 16 firmware and kernel/userspace driver patches to provide the 2025-06-05 Android and then Pixel patch levels.

Our 2025062700 release raised the overall patch level to 2025-07-01 since we got early access to it with a verifiable signature and know we already provide the patches. We usually do an early Android Security Bulletin release before the stock OS but it was done for July in June.

Android Security Bulletins are backports of High/Critical severity patches to older Android. Starting this month, the initial release of Android 16 is one of those older releases. It's split into AOSP userspace patches (YYYY-MM-01) and driver/firmware/Linux patches (YYYY-MM-05)

YYYY-MM-05 patch level has a device-specific portion with more driver/firmware patches. For Pixels, it's the Pixel Update Bulletin. Most Pixel Update Bulletin patches aren't specific to Pixels but the Android Security Bulletin doesn't cover Samsung cellular, Broadcom Wi-Fi, etc.

Pixel Update Bulletin patches are what we had to backport to Android 15 QPR2:

https://source.android.com/docs/security/bulletin/pixel/2025-06-01

These were for firmware/drivers/services for Samsung cellular (including the Radio Interface Layer), Broadcom/Qualcomm Wi-Fi/Bluetooth, NVT touchscreen, fingerprint and TPU.

The only part truly specific to Pixels was the TPU patch. Bear that in mind when you look at those Pixel Update Bulletins. Other devices are meant to have their own bulletins covering the same things if they use those components and also further patches. It's fully up to OEMs.

Android Security Bulletin (ASB) is published on the first Monday of the month unless it's a US/Google holiday in which case it gets pushed ahead a day or two. The Android release for the month is a separate thing from the ASB backports, usually published the day after the ASB.

ASB is likely July 7 and the Android OS release is likely July 8. Our aim is to have Android 16 in our Stable channel prior to July 8 so we can ship the initial monthly update to Android 16 instead of needing to backport Pixel Update Bulletin patches which could be infeasible.

Each month, Android has a new stable OS release. It's a monthly, quarterly or yearly release. Quarterly and yearly releases move along the development branch about the same amount and have a similar amount of changes. Those have months of public Developer Previews / Betas first.

Pixels ship the latest monthly, quarterly and yearly release each month. Non-Pixels ship an initial yearly Android release and then only Android Security Bulletin backports until they ship the next yearly release. ASB backports are a subset of the AOSP patches, not all of them.

GrapheneOS needs to follow the stable releases in order to provide the full AOSP privacy/security patches. It also needs to keep up with them in order to ship Pixel driver/firmware patches which are made for the latest stable release, but we'd still need to do this on non-Pixels.

Tags:

• 2025070301 (Pixel 6, Pixel 6 Pro, Pixel 6a, Pixel 7, Pixel 7 Pro, Pixel 7a, Pixel Tablet, Pixel Fold, Pixel 8, Pixel 8 Pro, Pixel 8a, Pixel 9, Pixel 9 Pro, Pixel 9 Pro XL, Pixel 9 Pro Fold, Pixel 9a, emulator, generic, other targets)

Changes since the 2025070300 release:

• fix upstream Android 16 issue causing very large Binder transactions due to the size scaling based on the number of apps installed across all users including base OS apps
• reduce virtual memory reserved for Binder buffers back to 1MiB now that we have a direct fix for the upstream issue causing more to be required and using a larger virtual memory reservation size appears to have a small chance of failing
• revert our fix for a screenshot process crash that's now fixed upstream in Android 16

Android regularly adds and splits permissions for new API levels. Legacy apps are handled by treating them as requesting the permission to provide a toggle for it. For example, Android 13 converted the existing toggle for disabling notifications for an app into a new POST_NOTIFICATIONS permission.

The Android Open Source Project has infrastructure for this since it's a regular part of the app sandbox and permission model improving. We add Network and Sensors permission toggles in GrapheneOS where Network is based on the existing low-level INTERNET permission and Sensors is entirely new.

Nearly all apps are unaware of these non-standard permissions just as they're unaware of new permissions added by Android before they get upgraded. Therefore, we enable them by default for compatibility but provide the ability for users to disable them at install time like the standard permissions.

For Network, apps request INTERNET, so we provide a toggle for rejecting that request in the initial app install dialog. If it's added in an upgrade, it's disabled by default. For Sensors, apps don't request it so we handle it similarly to how Android handled POST_NOTIFICATIONS for existing apps.

When Network is disabled, we act as if the network is down for compatibility. We won't run network-dependent jobs, various APIs will report it as down and we give errors matching it being down. When Sensors is disabled, sensors not covered by standard permissions give zeroed data and no events.

For usability, apps trying to use those sensors when Sensors is disabled will trigger a notification from the OS which can be disabled on a per-app basis. This informs users about what's going on so they'll know the app is either doing something sketchy or that it may actually require it.

F-Droid has an incorrect approach to installing apps which wrongly warns users about the standard Android POST_NOTIFICATIONS permission, our OTHER_SENSORS permission and previous Android permission additions/splits. They wrongly blamed GrapheneOS and didn't fix it:

https://archive.ph/MtB2J

They're now realizing that it happens with standard Android permissions added / split in new releases. Their approach to installing apps has been incorrect in multiple ways for many years and this is one of them. Their approach to listing which permissions are used by apps is also very incorrect.

F-Droid has a long history of denying issues including covering up serious security flaws. In some cases they eventually ship a fix but still deny it. It's a major factor in why F-Droid is not a safe or trustworthy source of apps due to major security issues not being acknowledged or addressed.

Multiple of the F-Droid developers wrongly blaming their app bug on GrapheneOS in that issue are Calyx contractors. They prioritize attacking GrapheneOS with inaccurate claims and fabricated stories about our team over fixing a bug in their app impacting both GrapheneOS and non-GrapheneOS users.

We've repeatedly brought up F-Droid not properly listing permissions or checking for them. Their understanding of Android's permission model is wrong. The way they list permissions misleads and misinforms users. It's one of many major F-Droid flaws they consistently don't acknowledge or fix.

Due to F-Droid deliberately causing friction and annoyances for GrapheneOS users, we'll be implementing a feature similar to our sandboxed Google Play compatibility layer for it. We'll can resolve deliberate issues created for GrapheneOS users ourselves as we did with Revolut.