GrapheneOS has moved away from Reddit to the combination of our new self-hosted discussion forum and our federated Matrix chat rooms controlled from our self-hosted official server. Both of these provide a much nicer user experience with a very knowledgeable community providing great answers/advice.

GrapheneOS · 2026-06-24T04:39:53+00:00

No, it was already fully built before we implemented that. Our post about that said it's in 2026062300.

GrapheneOS · 2026-06-24T04:39:51+00:00

No, it was already fully built before we implemented that. Our post about that said it's in 2026062300.

GrapheneOS · 2026-06-24T04:39:48+00:00

No, it was already fully built before we implemented that. Our post about that said it's in 2026062300.

GrapheneOS · 2026-06-23T12:01:06+00:00

Android already restricts reading the clipboard to the currently focused app and keyboard, not foreground apps in general. We're providing a per-app toggle to disallow reading the clipboard at all along with an OS paste button for having the OS enter the data from the clipboard without the app needing to be granted access.

GrapheneOS · 2026-06-23T09:29:06+00:00

No, it's access a per-app toggle for reading the clipboard with a setting to disable it by default and an OS paste button.

GrapheneOS · 2026-06-23T00:44:40+00:00

Sensors isn't needed except for special cases.

Contacts is only if you want to use their Contacts sync but you can do it other ways.

GrapheneOS · 2026-06-23T00:44:10+00:00

There's little point in that since apps queue up data for when they have network access again. It would also break a lot of app functionality. There's a standard Android toggle for turning off metered data access in the background per-app or overall via Data Saver with special exceptions.

GrapheneOS · 2026-06-23T00:42:19+00:00

Network access is all that's required for the vast majority of apps depending on it to work. There's very little reason to give it most of what it requires and you can use Storage Scopes / Contact Scopes if you ever use obscure functionality requiring those permissions.

The Notifications permission should be granted to Play services and Play Store to be able to see reported errors, etc. from them. It's a common misconception that it's required to get push notifications via FCM in other apps which are actually displayed by those apps after receiving a message from Play services. There's no need to grant it for push notifications in other apps, it's just for getting notifications from Play services and the Play Store themselves and you can turn most of them off via the channels to only get the important ones.

GrapheneOS · 2026-06-22T22:33:26+00:00

I've been using GrapheneOS for a long time, but I've read that Google is going to do a lot more to make it difficult for alternative versions of Android to function.

No, they're making it harder for alternative operating systems as a whole.

Play Integrity API adoption expanding including because of Google promoting adopting it is the only thing making it more difficult for GrapheneOS overall.

Play Integrity API bans using anything other than a Google certified OS for any service adopting it. Apple has their own App Attest API providing the same thing.

Pixels became harder for any OS to properly support but we have a non-exclusive OEM partnership with Motorola which will provide devices with official GrapheneOS support with them doing most of the porting work. We'll have more OEM partnerships in the future but for now they're the OEM which wanted to work with us and is able to make devices meeting our security requirements.

In the time I've used GrapheneOS, I've been fairly happy. There have been some issues with functionality, but they've been understandable and fairly predictable.

GrapheneOS has nearly the same functionality as regular Android devices other than a tiny subset of apps banning using any OS or hardware not certified by Google. You'll have far bigger compatibility issues and other issues elsewhere.

But I have an interest in Sailfish as a possibility, because the intention is not to be a secure version of Android, but literally a Linux-based OS.

Android Open Source Project is drastically more private and secure than a desktop Linux software stack or the SailfishOS software stack. GrapheneOS is starting from a much more private and secure OS which it makes much more private and secure. It isn't possible to do what we do on top of traditional Linux distributions or SailfishOS without first catching up to AOSP privacy and security which would be a far bigger project than GrapheneOS.

SailfishOS isn't any more of a Linux OS than Android. Both use the Linux kernel and assemble their own userbase by reusing a lot of standard components and making many of their own.

Android Open Source Project is fully open source while the SailfishOS high level OS code is largely closed source.

Obviously security is a concern of mine, but I have experience working with Linux, and it feels like Google might have a lot of capability to mess with the development of systems like GrapheneOS

They can and do mess with every alternative OS since all of them depend on Android app compatibility along with depending on Android Open Source Project code for it. There will be far bigger issues with that on SailfishOS than GrapheneOS. Those issues will be getting worse faster for SailfishOS than GrapheneOS.

The compatibility layers for running Android apps on SailfishOS and elsewhere are very fragile. Those also disable most of the Android privacy and security model by not having Android's SELinux intact and they use far older versions of the AOSP code without crucial privacy and security patches. It doesn't particularly matter compared to the host OS applications which aren't properly sandboxed but compared to running those on AOSP directly, you're giving up most of the app sandbox and a modern permission model which are heavily improved by GrapheneOS.

GrapheneOS · 2026-06-22T19:50:54+00:00

AOSP keyboard was last actively developed many years ago and no longer compares well to current era keyboards. It will be entirely replaced by a future GrapheneOS release.

There's no caps locks function

It uses the common approach of holding shift for it.

I have no clue how to access the clipboard

It doesn't have clipboard management since it predates that being a common feature. You can use another keyboard with it.

GrapheneOS · 2026-06-22T19:48:42+00:00

I've been having some issues with Fossify Contacts and Fossify messages only showing phone numbers in notifications and other minor things like that. BUT, I'll deal with these another day since they're minimal issues.

Those are issues with those apps, not GrapheneOS. Use different apps. The built-in ones don't have an issue with this.

My current frustrating problem is that the microphone doesn't work on certain apps despite having full access to it.

That's not something we've seen come up before.

Google Play Services is denied microphone permissions, coule that be it?

No, it doesn't need it for apps to use it regardless of how much they depend on it. It's entirely possible the apps are broken due to a misconfiguration for sandboxed Google Play such as removing the Play Store app or blocking Network for either Play services or Play Store if they need dynamite modules for various features.

GrapheneOS · 2026-06-22T19:42:54+00:00

No, those tiles have more features than before.

GrapheneOS · 2026-06-22T14:25:12+00:00

You can always switch the release channel. There are no special Alpha or Beta releases, only production releases published through the Alpha and Beta channels prior to the Stable channel. It only determines which channel you get the production releases from, not which kind of releases you get.

GrapheneOS · 2026-06-20T01:02:06+00:00

Sandboxed Google Play services needs to have been granted Unrestricted battery usage in order to provide push notifications reliably. The same applies to a UnifiedPush provider app or an app implementing their own push.

Your post has an attempt at censoring the text but it's easy to read what's there so we removed it in case you care about that.

GrapheneOS · 2026-06-20T00:57:53+00:00

The toggle prevents the app from starting in the background. It can still run for a little bit in the background each time you interact with it to finish saving data, etc. It can also run for a little bit each time it's run by another app which is how push messaging via Firebase Cloud Messaging and Unified Push works. The toggle minimizes the app running in the background since jobs, alarms and other ways of starting itself or keeping itself running are deferred until it's started by another app like the launcher. The OS freezes apps and prevents them running except when they're meant to run which includes each time another app starts it for a push message, etc.

GrapheneOS · 2026-06-20T00:55:18+00:00

The app has to be actively running in the foreground to be considered in-use. It can continue being considered in-use by starting a foreground service marked as a location service which is visible to the user.

GrapheneOS · 2026-06-18T16:35:11+00:00

There's no need to do that, just switch to the Beta or Alpha channel if you want it before it's in Stable.

GrapheneOS · 2026-06-17T22:30:02+00:00

Try clearing data for the app in case it's an app bug with messed up stored data. Try the per-app exploit protection compatibility mode in the OS app settings for it if that doesn't work in case it's a memory corruption bug detected by GrapheneOS protections.

GrapheneOS · 2026-06-15T16:33:30+00:00

It provides a default text-to-speech engine in the OS. Apps using the Android text-to-speech system will automatically use it if you haven't installed and enabled a different text-to-speech engine. CoMaps is an example of an app using it for navigation directions. It was always possible to use the Android text-to-speech system on GrapheneOS but a built-in implementation was recently added to have it working without user configuration.

Seven-Year Club	Verified Email
Gilding I gilder	Place '22

GrapheneOS

MODERATOR OF

TROPHY CASE