GrapheneOS

Open source privacy and security focused mobile OS with Android app compatibility.

Public Key

npub1235tem4hfn34edqh8hxfja9amty73998f0eagnuu4zm423s9e8ksdg0ht5

NIP-05 Address

Profile Code

nprofile1qqs9g69ua6m5ec6ukstnmnyewj7a4j0gjjn5hu75f7w23d64gczunmgppamhxue69uhkummnw3ezumt0d5q32amnwvaz7tmjv4kxz7fwv35hgar09ec82csp0mrg7

Publishing to

nostr.mom

relay.ditto.pub

Author Public Key

npub1235tem4hfn34edqh8hxfja9amty73998f0eagnuu4zm423s9e8ksdg0ht5

Show more details

Last Notes

2026-07-25 21:48:10 GMT

- reply

@nprofile…3kzl Apps can be installed on GrapheneOS via CLI using the package manager.
It has a desktop mode and can handle a mouse, keyboard, game controller and other accessories alongside USB-C digital audio and DisplayPort output. It is a desktop OS itself in a sense. It will likely eventually run on a small number of laptops meeting the hardware security requirements.
It has hardware-based virtualization including opt-in GPU acceleration via gfxstream. It can run a desktop OS as a VM guest.

2026-07-25 20:01:15 GMT

- reply

@nprofile…3wl0 Android may have used pipewire and wayland if those existed many years ago but they didn't so it has audioflinger and surfaceflinger among other examples.
There are many components beyond the Linux kernel which are shared. There are many which aren't including most of the fd.o projects, systemd, glibc and other GNU components. Android uses LLVM to build the Linux kernel and everything else. It completely avoids GCC and binutils. A desktop distro could too even if one doesn't yet.

2026-07-25 19:59:11 GMT

- reply

@nprofile…3wl0 We're just listing systemd as an example of a component used by most desktop distributions but not AOSP. AOSP does use many of the same GPLv2-licensed Linux kernel tied userspace projects such as the userspace libraries/tools for SELinux, netfilter, iproute2, iputils, etc. It doesn't use the ones which aren't really tied to Linux and use different licensing including glibc. systemd was made much later than Android so it couldn't have really used that and doesn't have a use for it now.

2026-07-25 19:51:23 GMT

- reply

@nprofile…3wl0 We mentioned systemd in response to people saying GrapheneOS isn't a Linux distribution with no clear reasoning for why that's the case. We said using glibc, systemd and GNOME isn't what makes it Linux. A distribution using musl, OpenRC and BusyBox such as regular Alpine shows exactly why considering other userspace software to be what makes it Linux doesn't make sense. Server and embedded Linux don't use the fd.o desktop stack. More than AOSP alternatives exist to it too.

2026-07-25 19:35:35 GMT

- reply

@nprofile…3wl0 To clarify something, we do not have an active conflict with PostmarketOS itself. A couple people involved in the project made posts linking to harassment content and with personal insults which were later taken down and it was eventually settled this year. We considered it essentially closed but people keep attacking us who support it and there's a GNOME project member who keeps bringing it up referencing it as if it's an active conflict claiming we're doing stuff we never have.

2026-07-25 19:31:59 GMT

- reply

@nprofile…3wl0 The 2nd link above was meant to be https://eattherich.club/@kiefac/116976545439189720.
This is a core GNOME project member:
https://mastodon.com.pl/@tragivictoria/116834713496471432
She has been posting attacks on us for at least a couple weeks including on Reddit repeatedly claiming we're insane and delusional along with false claims about us. That includes extraordinarily false claims that we're the ones engaging in harassment with no basis, spinning us saying we're being targeted into being doing it:
https://mastodon.com.pl/@tragivictoria/116837805200349592

2026-07-25 19:28:21 GMT

- reply

@nprofile…3wl0 Those aren't nearly as bad as many of the things said about us in the past several weeks including from a couple GNOME project members. The norm is claiming we're insane, delusional and schizophrenic with those words. There's ongoing harassment from Kiwi Farms and a prominent influencer who uses it. Many people who are part of open source projects and communities engage in it. From our perspective what makes those 2 posts above awful is that they are nearly certainly aware of all this.

2026-07-25 19:21:51 GMT

- reply

@nprofile…3wl0 Our community members aren't posting personal attacks and false claims about projects/people opposed to us in this thread. We aren't doing it either. It's only your projects and communities doing it towards us, as is nearly always the case. We're falsely accused of things we've never done and which our community never does but which are ongoing on a daily basis from your projects and communities towards us. If we hadn't blocked several people doing it they'd have done more of it here.

2026-07-25 19:20:27 GMT

- reply

@nprofile…3wl0
> Also, on the attacks thing. Every time I ever respond to anything to do with GrapheneOS, even if it isn't a debate, I get hit with that. Why? What have I done to deserve that?
This thread has a bunch of it. Here are 2 examples:
https://eattherich.club/@kiefac/116976391060397637
https://eattherich.club/@kiefac/116976
Multiple of the accounts doing it including that one moved on to making top-level posts attacking us with false claims about what we said and did.
It is ongoing and relevant to any discussion here.

2026-07-25 19:17:12 GMT

- reply

@nprofile…3wl0 GrapheneOS was started as a mobile Linux hardening project. We've contributed to upstream Linux kernel privacy and security.
We stopped making substantial upstream contributions due to attacks on the project from people using our upstream code. Each of these threads where people claim we aren't working on what we are, making disingenuous arguments and false claims about our project/team including personal attacks further discourage going back to doing more of it again.

2026-07-25 19:14:16 GMT

- reply

@nprofile…3wl0 Android is an operating systems rather than a Linux distribution. AOSP is the reference implementation of Android and the upstream open source project for the overall operating systems family.
GrapheneOS is a Linux distribution. It can be called an AOSP-based OS or an Android-based OS too. It's Android-based rather than Android itself because we do not follow the official Android definition. OEM forks of AOSP including Google Play supposedly follow the official Android definition.

2026-07-25 19:03:50 GMT

- reply

@nprofile…3wl0 GrapheneOS is objectively a Linux distribution. It is your projects and communities attacking us with false claims and personal attacks for making an accurate statement. It isn't us claiming your projects aren't Linux and don't have a right to use the term.
The project and community you list yourself as being involved in has a long history of attacks on the GrapheneOS project including personal attacks visible throughout the other threads branching from the post mentioning us above.

2026-07-25 18:54:08 GMT

- reply

@nprofile…3wl0 Claiming Android isn't Linux is a revisionist claim for marketing purposes. The amount of people buying into it in these echo chambers does not reflect a broad consensus as you're implying.
Linus Torvalds, the Linux project and the Linux Foundation have been saying Android is Linux from early on. There's a broad consensus among people without vested interest in promoting certain products and projects that it's Linux. It was quite uncontroversial that it was Linux until more recently.

2026-07-25 18:52:55 GMT

- reply

@nprofile…3wl0 It is you who holds the fringe position despite trying to portray it the other way around. You shouldn't mistake the echo chamber you're posting in for a broad consensus beyond it.
Linus Torvalds, the Linux project and the Linux Foundation have been saying Android is Linux from early on. There's a broad consensus among people without vested interest in promoting certain products and projects that it's Linux. It was quite uncontroversial that it was Linux until more recently.

2026-07-25 18:50:17 GMT

- reply

@nprofile…3wl0 Android was mobile Linux before these products and projects began claiming exclusive rights the term. What's convenient to them for marketing their products is not the same thing as what is reality or consensus. They're very niche products and the extensive promotion of those including by attacking the GrapheneOS project on the fediverse is not representative of a broader consensus. The hostility towards GrapheneOS and level of false claims about it on this platform is highly unusual.

2026-07-25 18:47:20 GMT

- reply

@nprofile…3wl0 In practice, every Linux distribution uses a fork of the Linux kernel in production. Android works with a mainline kernel similarly to Debian working with a mainline kernel. Neither uses a mainline kernel without patches in in production in practice, but neither requires those changes.
These companies, projects and their supporters do not speak for the Linux kernel project or the broader public. The consensus you and others claim exist does not exist. It is a marketing approach.

2026-07-25 18:45:57 GMT

- reply

@nprofile…3wl0 @nprofile…c8pt @nprofile…dey5 Android was mobile Linux and broadly accepted as such long before those products existed.
Arbitrarily claiming Android isn't Linux is very convenient to them for marketing reasons because Linux phone sounds better than the alternatives. However, they do not own or define the term Linux.
Linus Torvalds has repeatedly clearly said Android is Linux long before it could work with mainline kernels as it can today. It's not up to Pine64 and their fans if it is.

2026-07-25 18:41:54 GMT

- reply

@nprofile…3wl0 @nprofile…c8pt @nprofile…dey5 Android does not require a fork of the Linux kernel. It has worked with regular mainline, stable and longterm kernels for many years. All of the Android kernel features required to run it have been included upstream. Android replaced the features which weren't included upstream with standard ones including reimplementation features with eBPF. It does not require a single Linux kernel change to function. What you're saying is a misconception since years ago.

2026-07-25 18:41:02 GMT

- reply

2026-07-25 18:37:20 GMT

- reply

@nprofile…nltl @nprofile…c8pt @nprofile…dey5 @nprofile…ppje @nprofile…gun3 Android is Linux according to Linus Torvalds, Greg KH, the Linux Foundation and broad consensus.
Android doesn't stop being Linux because companies and projects want to market phones with glibc, systemd and GNOME as being Linux as opposed to the mainstream mobile Linux.
There are products listed above which do not have a typical desktop Linux environment including SailfishOS with their own closed source UI and application layer.

2026-07-25 18:35:30 GMT

- reply

@nprofile…glgc @nprofile…c8pt @nprofile…ppje @nprofile…dey5 We're using the Linux name in the same way it has been used for years including by Linus Torvalds and the Linux Foundation. Linux does not mean what is currently convenient to you based on which Linux userspace approach you want to be successful. Android is not arbitrarily excluded from being Linux because you prefer a different userspace approach. You don't own the term Linux and it's not up to you what it means. Linus Torvalds says Android is Linux.

2026-07-25 18:30:19 GMT

- reply

@nprofile…glgc @nprofile…c8pt @nprofile…ppje @nprofile…dey5 Android is objectively Linux. Linus Torvalds, Greg KH and other core members of the Linux project regularly confirm Android is Linux.
Android is Linux and has been called Linux since long before the products you're claiming have exclusive rights to the term Linux Phone existed.
Linux doesn't mean systemd, GNU and XDG desktop standards. It doesn't mean using GNOME or KDE. Server and embedded Linux is Linux, as is another kind of desktop userspace.

2026-07-25 04:22:07 GMT

Vanadium version 151.0.7922.47.1 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/151.0.7922.47.1
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/40679-vanadium-version-15107922471-released
#GrapheneOS #privacy #security #browser

2026-07-25 04:10:09 GMT

- reply

@nprofile…fupw @nprofile…re8h Pixels are initially going to remain the budget option for countries where those are available. Pixel 'a' series devices get the regular 7 years of support from launch and end up being an extremely good deal as used devices after a couple years. It's not easy to compete with that, but Pixels aren't sold everywhere and they're very expensive in a lot of countries where they're not sold. The initial Motorola flagships will be expensive too but there will be more.

2026-07-25 04:08:18 GMT

- reply

@nprofile…fupw @nprofile…re8h It will only be future Motorola devices providing what we need. The initial ones will be flagships because those will be the first with the updates and security features we need. It will be able to expand to more devices from there. We need to carefully choose devices but we do want to include some more budget devices. It likely won't go below equivalents to the Pixel 'a' series range because it's unlikely low end devices will provide what we need any time soon.

2026-07-25 01:34:16 GMT

- reply

@nprofile…re8h The Motorola devices will be more internationally available especially once there are lower priced ones providing official GrapheneOS support. It 's starting with the flagships because Qualcomm rolls out security features to those first and it will likely be a while before even the high end non-flagship ones have what we need.

2026-07-25 00:27:16 GMT

- reply

@nprofile…re8h We have a non-exclusive partnership with Motorola Mobility (Lenovo) to bring GrapheneOS to future devices from them providing all of our hardware requirements and official GrapheneOS support.
They'll provide us with the driver and firmware support we need without us needing to reverse engineer stock OS code and extract firmware, configurations, driver libraries, etc. from factory images.
It will start with flagships since they'll be the first with what we need but will expand.

2026-07-25 00:25:37 GMT

- reply

@nprofile…re8h Most smartphones don't allow using another OS. Most of the ones permitting it cripple functionality including security if one is used.
Most computers including a large portion of smartphones lack of ongoing firmware security updates which we can't solve for those. It's quite important to have security updates for GPU, Wi-Fi, Bluetooth, cellular, NFC and UWB radio firmware along with other components exposed to attacks.
Most smartphones lack features we use to protect users too.

2026-07-24 23:46:51 GMT

- reply

@nprofile…z3n8
> If Google moves Android behind contracts, everybody will happily sign.
Many Android OEMs are already very unhappy with Google's oppressive behavior towards them. South Korea determined it was illegal and Samsung is now largely freed from the same constraints placed on other OEMs. Most Android OEMs clearly want to have the same freedom. Android OEMs do care about AOSP being open source and didn't sign up for how Google seized control and walked back promises to OEMs.

2026-07-24 23:45:42 GMT

- reply

@nprofile…z3n8
> If Google moves Android behind contracts, everybody will happily sign.
Many Android OEMs are already very unhappy with Google's oppressive behavior towards them and several have filed lawsuits against them. South Korea determined it was illegal and Samsung is now largely freed from the same constraints placed on other OEMs. They want to have the same freedom. Android OEMs care about AOSP and didn't sign up for what Google gradually ended up doing with GMS, etc.

2026-07-24 01:36:06 GMT

- reply

@nprofile…dwjp @nprofile…hpz0 You can wipe the device via recovery without this though, but not quickly since you have to reboot into fastboot mode and then go to recovery or use another method.

2026-07-23 19:51:12 GMT

- reply

@nprofile…trls It's very likely caused by your apps and/or networks. You should follow the advice in https://discuss.grapheneos.org/d/35721-grapheneos-power-usage-recommendations.

2026-07-23 19:50:24 GMT

- reply

@nprofile…hpz0 We're not aware of any jurisdiction where it would be illegal to set a duress PIN/password. Enabling it doesn't at all imply giving it to law enforcement when asked for a PIN/password. It can be used without explicitly giving it to someone else and isn't in any way specific to law enforcement. For example, the duress PIN/password can be written down on paper kept in the phone case and/or wallet marking it as a PIN/password. GrapheneOS also doesn't depend on this to protect data at all.

2026-07-23 19:50:11 GMT

- reply

2026-07-23 19:43:44 GMT

- reply

@nprofile…hpz0 We're not aware of any jurisdiction where it would be illegal to enable the feature. Using the feature doesn't at all imply giving it to law enforcement when asked for a PIN/password. It's not in any way specific to law enforcement and it can be used in different ways than giving it to someone else.
Whether or not it's legal to give it to law enforcement in response to a request for the PIN/password depends on the jurisdiction and circumstances. This case hasn't been decided yet.

2026-07-23 19:41:43 GMT

- reply

@nprofile…hpz0 We're not aware of any jurisdiction where it would be illegal to enable the feature. Whether or not it's legal to provide it to law enforcement when the PIN/password is requested by them is a much different topic. The feature can be used in different ways and doesn't imply doing that.
It can also depend a lot on the circumstances. We think it's likely the person in this case is going to win. That doesn't mean it would be legal to provide it in significantly different circumstances.

2026-07-23 16:17:38 GMT

https://www.theguardian.com/us-news/2026/jul/23/cop-city-protester-phone

2026-07-22 20:57:08 GMT

GrapheneOS Info app version 7 released:
https://github.com/GrapheneOS/Info/releases/tag/7
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/40606-grapheneos-info-app-version-7-released
#GrapheneOS #privacy #security

2026-07-22 20:57:04 GMT

Vanadium version 151.0.7922.47.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/151.0.7922.47.0
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/40605-vanadium-version-15107922470-released
#GrapheneOS #privacy #security #browser

2026-07-22 20:40:38 GMT

- reply

@nprofile…yw9y Hopefully under 6 months. It would probably take around a week to implement and depends on what we prioritize over the next several months.

2026-07-22 20:40:04 GMT

- reply

@nprofile…yw9y Hopefully under 6 months.

2026-07-22 20:10:40 GMT

- reply

@nprofile…yw9y Mock Location via developer options is a standard Android feature but we're developing per-app Location Scopes as a better alternative. It will be able to spoof a different location on a per-app basis. We can also make our own API for detecting it's active to avoid apps banning Mock Location banning using it while also avoiding apps banning GrapheneOS as a whole for it since they can use the API for detecting it's active. That will maximize compatibility.

2026-07-22 17:32:31 GMT

- reply

@nprofile…7a7m Device and strong integrity require a Google certified device running the unmodified stock OS. Basic is expected to pass when logged into a Google account which can be a purpose-specific throwaway but those won't.
GrapheneOS has a feature intercepting Play Integrity API requests and it uses that to show a notice when an app uses it so you would know if the app was using Play Integrity API. If there isn't a notification, it isn't.

2026-07-22 13:21:51 GMT

- reply

@nprofile…t9a9 GrapheneOS greatly improves both privacy and security compared to the Android Open Source Project while CalyxOS does the opposite by lagging far behind standard patches and protections. They're not in the same space.
Nearly every Android app is compatible with GrapheneOS. It has our sandboxed Google Play compatibility layer to run apps depending Google Play. Banking apps are a special case but most work. App compatibility is much work on operating systems using microG including CalyxOS.

2026-07-20 17:30:15 GMT

- reply

@nprofile…5yuq We arem't affiliated. He's someone with no official involvement with us doing an interview with our community manager.

2026-07-20 17:29:49 GMT

- reply

@nprofile…5yuq We arem't affiliated but rather he's doing an interview with our community manager.

2026-07-20 05:36:45 GMT

- reply

@nprofile…a6cc Seems you either left out the text or didn't meant to reply.

2026-07-20 05:36:33 GMT

- reply

@nprofile…a6cc Seems you either left out the text or didn't meant to reply.

2026-07-20 03:08:31 GMT

GmsCompatConfig version 172 released:
https://github.com/GrapheneOS/platform_packages_apps_GmsCompat/releases/tag/config-172
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/40515-gmscompatconfig-version-172-released
#GrapheneOS #privacy #security #gmscompat

2026-07-19 23:25:39 GMT

- reply

@nprofile…lalv We're partnered with Motorola Mobility rather than Motorola solutions. They're entirely separate companies since the split in 2011. Motorola Mobility was acquired by Google in 2012 and then sold to Lenovo inn 2014.
Motorola Mobility is the successor of the consumer hardware division while Motorola Solutions makes much more niche products focused on government contracts.
Motorola Mobility wants to get into the enterprise and government markets so they're focusing on improving security.

2026-07-19 13:00:29 GMT

Join Josh from Side Of Burritos and our Community Manager spring-onion in a live conversation about everything GrapheneOS on July 20th!
PDT - 10:00 / 10:00 AM
EDT - 13:00 / 1:00 PM
UTC - 17:00 / 5:00 PM
BST - 18:00 / 6:00 PM
CEST - 19:00 / 7:00 PM
AEST - 03:00 / 03:00 AM / July 21st
To accommodate for different preferences the stream will be available simultaneously on both YouTube and a self-hosted instance of Owncast.
https://www.youtube.com/watch?v=56-DCAHU29Y
https://sideofburritos.com/live/

2026-07-16 19:16:54 GMT

- reply

We already have a notification for apps using the Play Integrity API and can start detecting these libraries consistently causing compatibility issues to warn users about it. These notifications can have a shortcut for leaving a Play Store review for users with the sandboxed Play Store installed.

2026-07-16 19:12:12 GMT

V-Key's libraries depend on private APIs and implementation details. This causes compatibility issues with new Android releases, OEM changes and GrapheneOS security protections. We're now aware of it and worked around the known compatibility issues. However, they need to start fixing it themselves.

2026-07-16 16:29:00 GMT

GrapheneOS version 2026071500 released:
https://grapheneos.org/releases#2026071500
See the linked release notes for a summary of the improvements over the previous release.
Forum discussion thread:
https://discuss.grapheneos.org/d/40416-grapheneos-version-2026071500-released
#GrapheneOS #privacy #security

2026-07-15 18:54:05 GMT

- reply

We've resolved the new compatibility issues with anti-tampering code in banking apps. We're in the process of making a new release with the workarounds. We posted a new thread about it:
https://grapheneos.social/@GrapheneOS/116925427491681935

2026-07-15 18:50:18 GMT

- reply

Our new secure spawning improved overall app compatibility despite these 2 anti-tampering SDKs causing new issues with it. We've solved the regressiond and are currently building a new release with the improvements. It will be available in around 12 hours. App compatibility will be better than ever.

2026-07-15 18:46:12 GMT

- reply

Our new secure spawning implementation has better app compatibility. This made it possible for the V-KEY V-OS Mobile App Protection anti-tampering SDK to run instead of crashing and it began blocking GrapheneOS. We've solved this problem by simply blocking their code from running for the time being.

2026-07-15 18:43:10 GMT

- reply

Our new secure spawning also added a per-app toggle. Alongside this, we made is possible to disable secure spawning and hardened_malloc at the same time. This requires an extra zygote with hardened_malloc disabled which we spawned on-demand. It has to be spawned at boot instead for low mount IDs.

2026-07-15 18:39:42 GMT

- reply

Our new secure spawning implementations runs the same code run by the Zygote after exec to improve compatibility. Many apps which didn't work before are now compatible. However, that tripped this mount ID check by recreating a mount namespace. It doesn't need that part so we've simply removed it.

2026-07-15 18:33:54 GMT

We solved the recent regression in compatibility with a small subset of banking apps. It was caused by a Zimperium anti-tampering SDK checking the Linux kernel mount ID for /system/framework/framework.jar and banning it being above 900. Our new secure spawning was tripping it.

2026-07-15 18:28:44 GMT

- reply

We've resolved the issue. See our new thread about it:
https://grapheneos.social/@GrapheneOS/116925334629738010

2026-07-15 18:28:11 GMT

- reply

This SDK checks the mount ID for /system/framework/framework.jar and disallows the ID being above 900. They use this to detect mounts created by Magisk and similar software. We've changed our new secure spawning related code to always create this mount namespace in early boot.

2026-07-15 18:21:06 GMT

- reply

This SDK checks the mount ID for /system/framework/framework.jar and blocks using the apps if it's above 900. They use this to detect mounts created by Magisk and similar software. We don't need mount namespaces for sandboxing due to SELinux so it can be easily worked around.

2026-07-15 18:20:37 GMT

- reply

2026-07-15 18:14:12 GMT

- reply

We solved the recent regression in compatibility with a small subset of banking apps. It was caused by the V-KEY V-OS Mobile App Protection SDK. It checks Linux mount IDs and breaks if mount namespaces are created after early boot. We've started builds for a new release already.

2026-07-15 18:10:17 GMT

2026-07-15 14:55:50 GMT

- reply

@nprofile…y26f Motorola flagships with GrapheneOS support will likely be available in 2027, hopefully within 12 months. It will take longer for lower end devices to be supported. The initial devices will be more expensive than most Pixels but it will end up supporting devices in a similar price range as Pixels including the 'a' series devices over time.

2026-07-15 13:35:07 GMT

- reply

@nprofile…kj8p Revolut should currently work fine on GrapheneOS but they may ban it in the future with the Play Integrity API. We'll have to do a pressure campaign to get them to unban it if that happens. We suspect it will happen because we had to work around an SDK in the Revolut app which was explicitly banning using GrapheneOS. It was even detecting the string "grapheneos" as the build user for the OS which we had set for reproducible builds. We had to change that and other things it checked.

2026-07-15 00:42:41 GMT

- reply

@nprofile…quyq We're going to be completely replacing the legacy AOSP Gallery with a much more modern app in the near future. Our Camera app will also get a major overhaul with many new features and a new user interface. The current Gallery isn't our own app but rather a legacy AOSP sample app and is awful but it's going to be gone soon.

2026-07-14 22:16:13 GMT

- reply

@nprofile…06ud The system would be fine if it was open sourced after a week instead of typically taking 2-4 months and sometimes longer.
It's worth noting security preview patches include patches to external projects. These patches aren't only for things Android uses. Some are publicly disclosed elsewhere already while others are not. There have been patches from Android security previews for projects used outside Android shipped in GrapheneOS according to the rules prior to disclosure elsewhere.

2026-07-14 22:13:47 GMT

- reply

@nprofile…06ud It's done because OEMs are so terrible at shipping patches. They started off giving them 30 days of early embargoed access but it wasn't enough and OEMs found it too difficult to ship patches each month. It also put users at risk from having it broadly disclosed for 30 days.
The new system allows every OEM to ship the patches without an embargo as GrapheneOS does while papering over OEMs taking many months to ship it. It's more secure when used well and covers up the failures.

2026-07-14 22:09:44 GMT

Vanadium version 150.0.7871.124.0 released:
https://github.com/GrapheneOS/Vanadium/releases/tag/150.0.7871.124.0
See the linked release notes for a summary of the improvements over the previous release and a link to the full changelog.
Forum discussion thread:
https://discuss.grapheneos.org/d/40347-vanadium-version-150078711240-released
#GrapheneOS #privacy #security #browser

2026-07-14 20:14:38 GMT

- reply

@nprofile…a4ar NFC payments work in apps not using the Play Integrity API to ban alternatives to Google Mobile Services Android.
Tap-to-pay works in Curve Pay, PayPal and many European banking apps. We aren't currently aware of an option available outside of Europe.

2026-07-14 19:01:24 GMT

- reply

We found one anti-tampering SDK was crashing due to being incompatible with secure (exec-based) spawning and therefore permitting having any OS. By fixing compatibility with it, we enabled it to detect and ban GrapheneOS. We'll fix that too. Banking app code is ultra low quality.

2026-07-14 18:59:05 GMT

- reply

In some cases, we've found the issue is that the anti-tampering code was previously crashing due to being incompatible with the previous secure spawning implementation so it wasn't banning GrapheneOS. By improving compatibility with it, we enabled it to ban GrapheneOS. We'll fix that problem too.

2026-07-14 18:57:04 GMT

- reply

@nprofile…3jn2 Their anti-tampering code is very broken. It started banning GrapheneOS due to some kind of change tied to the new secure spawning implementation but it can be stopped by breaking it using a VPN.
It's possible the anti-tampering code was completely broken by using secure spawning with the previous implementation but the new implementation improved compatibility with it which enabled it to ban GrapheneOS.

2026-07-14 18:45:19 GMT

- reply

Our per-app compatibility mode and the finer-grained toggles it uses can be used to work around most broken anti-tampering code. Our new per-app secure spawning toggle made it better. We need to fix the new compatibility issue with another flawed anti-tampering SDK though.

2026-07-14 18:38:10 GMT

- reply

These apps have poor security and instead deploy half-baked anti-tampering mechanisms with memory corruption bugs and many dependencies on implementation details changing between Android releases. It's why these apps usually break on new major Android versions until they upgrade.

2026-07-14 18:36:55 GMT

- reply

The new secure spawning implementation uncovered some more of these strange cases of apps banning GrapheneOS for obscure reasons. Since multiple users are reporting using a VPN set to another country works around it for Chase, that's worth trying as a workaround for others too.

2026-07-14 18:35:48 GMT

- reply

Our new secure spawning implementation improved overall app compatibility but there are still apps detecting differences from the stock OS and banning GrapheneOS. One cause we've discovered are apps counting the number of memory pages considered shared and banning having too few.

2026-07-14 18:34:39 GMT

Our users are reporting the Chase banking app is banning using GrapheneOS but permits it when a VPN is enabled and set to another country:
https://discuss.grapheneos.org/d/40289-chase-app-error-on-latest-graphene-version
We're aware of this compatibility issue with several apps and are actively working on improvements to resolve it.

2026-07-14 13:07:41 GMT

- reply

@nprofile…06ud We aren't happy about it because we want to be able to quickly provide the full set of patches in our regular releases. It's ridiculous having the patches not disclosed as open source for months. It should be a week at most, ideally significantly less than that. Our plan is to start having people reverse engineer patches from binary which can then be merged into the regular releases if it's done correctly. We aren't quite ready to get started on shipping them that way but we plan to.

2026-07-14 13:06:35 GMT

- reply

@nprofile…06ud GrapheneOS is already the only way to get all of the Android security preview patches early. Samsung flagships and Pixels ship a subset early but much more slowly than we do and they don't ship all of them. We get all of the security preview patches integrated and tested quite quickly. It's already a unique feature of GrapheneOS giving it yet another major privacy and security advantage over every other Android variant. We strongly recommend everyone uses the security preview releases.

2026-07-14 13:02:05 GMT

- reply

@nprofile…n6nv We have an unused @nprofile…8d0p account on Instagram to reserve the name. Every other account on Instagram using the GrapheneOS name is impersonating the project. There are many of those accounts impersonating us to sell sketchy devices supposedly running GrapheneOS. It's why we made the placeholder account to reserve the main name.

2026-07-14 13:00:19 GMT

- reply

@nprofile…ud5y No, those EU standards don't require providing reasonable security patches. We've been pointing out how useless the standards are for years. Android was already only backporting High and Critical severity patches to older releases which was in full compliance with the regulations. Further reducing how much gets backported is still in compliance. It requires that OEMs ship the extremely incomplete backports deemed to be the standard ones and slowly update the OS version too.

2026-07-14 03:02:58 GMT

- reply

Google needs to start open sourcing QPR1 and QPR3 releases again along with open sourcing security preview patches shortly after disclosure to OEMs. Otherwise, we'll just hire people to start doing reverse engineering work in an official capacity to start publishing the changes as open source early.

2026-07-14 02:56:37 GMT

- reply

Google switched to a performative Android Security Bulletin system with vulnerabilities listed 2-4 months after they're shipped. They're pretending as if not open sourcing patches protects people from OEMs not patching them. Our community has people successfully reverse engineering binary patches.

2026-07-14 02:55:01 GMT

- reply

Google is completely overwhelmed by the massive torrent of vulnerabilities discovered by AI models. They've done repeated cycles of layoffs and buyouts crippling their ability to handle it. The change to the schedule for Android Security Bulletins is also extremely at odds with this new reality.

2026-07-14 02:50:52 GMT

- reply

We're going to need to do a lot of work with Motorola and Qualcomm to provide serious patches for GrapheneOS devices. We're going to need more developers. After the launch of the new devices with GrapheneOS support, we want to repeatedly port to the latest Linux LTS branch among other major changes.

2026-07-14 02:44:43 GMT

- reply

Android 17 is the only Android release with the current set of disclosed Moderate and Low severity patches. Android 16, 16 QPR2 and 17 will soon be the only releases with the current set of disclosed Critical and High severity patches too. Once Android 18 is released, it will be the only one.

2026-07-14 02:43:34 GMT

- reply

Bare minimum Android security patches now require being on Android 16, 16 QPR2 or 17 and quickly moving to Android 18 when it's released. Once Android 18 is released, it will be the only release with current High and Critical severity patches. Serious support for older Android releases has ended.

2026-07-14 02:37:55 GMT

- reply

Android Security Bulletins already omit Moderate and Low severity patches. They're already dated 2-4 months after the vulnerabilities were disclosed to OEMs and allowed to be shipped. Only Samsung flagships and Pixels ship any of it 'early' on practice. Only GrapheneOS ships the full set 'early'.

2026-07-14 02:34:05 GMT

- reply

Externally reported vulnerabilities will currently still follow the same policy for backports as before. High and Critical severity vulnerabilities reported to Google by external parties will be backported to releases going back around 3 years (currently 14, 15, 16 and the current latest stable 17).

2026-07-14 02:31:10 GMT

- reply

Google recently informed OEMs of greatly reduced security support for older releases of Android. For the vast majority of discovered vulnerabilities, only Critical severity issues deemed to be an imminent risk will be backported at all and only to the most recent 2 major yearly releases (16 and 17).

2026-07-14 02:26:39 GMT

Android's security policy for the past several years has been to backport patches for Critical and High severity Android vulnerabilities to the past 3 major yearly releases. Moderate and Low severity patches including most fixes for privacy weaknesses have required upgrading to the latest releases.

2026-07-11 20:35:28 GMT

- reply

@nprofile…lezl @nprofile…v43s It even has optional GPU acceleration support via gfxstream and will eventually have support for hardware GPU acceleration support.
Desktop mode and virtualization of other operating systems are both going to get much better. Android is moving towards replacing ChromeOS and that functionality is going to be available in GrapheneOS too. We also plan to improve it.

2026-07-11 20:30:08 GMT

- reply

@nprofile…lezl @nprofile…v43s GrapheneOS has DisplayPort alternate mode and the standard Android 17 desktop mode. It has always been able to use a mouse, keyboard, game controller, etc.
There's also the standard hardware-based virtualization support including the experimental Terminal app for managing virtual machines running other operating systems. That has GUI and audio input/output support.

2026-07-10 19:10:08 GMT

- reply

@nprofile…yu9g It could also potentially remember that the hotspot was previously enabled when switching back to a user which had it enabled before switching away, at least until reboot since we wouldn't want to make it more persistent than it usually is in that regard. That would be harder than making the quick tile work and it's not clear if it's something we actually want to do.

2026-07-10 19:09:13 GMT

- reply

@nprofile…yu9g Wi-Fi settings were moved from device encrypted storage to per-user credential encrypted storage with networks belonging to users with the option to disable sharing those with other users or editing by other users. It has per-user Wi-Fi settings now so it has to turn off Wi-Fi when switching users and then turn it back on with the settings for that user. That's what causes the hotspot to get turned off. We can add the hotspot quick tile to secondary users as they should have though.

2026-07-10 14:23:30 GMT

- reply

@nprofile…yu9g No, it works in every user and can be enabled by secondary users now instead of only the main user. Android 17 moved to per-user Wi-Fi settings. Wi-Fi hotspot quick tile isn't supported in secondary users yet but it can be enabled in the Settings app. We plan to make the Wi-Fi quick tile usable in secondary users as a GrapheneOS enhancement prior to it being done upstream.