Graphene OS Questions, comments, concerns, etc

Does any one have any suggestions, tips, or experiences for dealing with F Droid apps while using Graphene OS?

Update (as of 2024/04/26): I sent a PM to the user who closed this post " While I do understand your well meaning intentions for closing the topic, I think it is counter productive to what the intent of “posting” is for:
Dialogue & Information Sharing.
This post (as “unattractive” as it seemed to others) actually produced helpful information to me (and I assume other newbies as well), especially since Tryptamine’s follow up. It is incorrect to shut down a topic because of the temperature; maybe put a user response timer on, but not shut down. "

1 Like

Nothing should be needed, it should work just fine.

1 Like

I keep having a few apps either freeze up or have that message that says something like “app is not responding, do you want to : wait, close app, app details”. I would have this with my previous Android, but not as much with this new one that happens to have Graphene on it.

what does “app details” offer you?

What if you disable for that app, in Android app details, their “memory harden” thing?

1 Like

GrapheneOS user here.

I personally have not had issue with any f-droid app on grapheneOS. Every single one I have tried works just as I’d expect on a stock android device. Might be good to mention what apps you are using that are affected

However it could also be some of the exploit protection features in GrapheneOS. The exploit protections can cause issues in certain applications most notably memory tagging and blocking native code debugging.

If you think it may be one of these issues you can simply go to the specific apps in question in the settings app and turn off certain exploit protections accordingly. If you don’t know which one may be causing it then no worries! Just toggle the exploit protection compatibility mode on the same page!


My apologies, it will say “SHOW details”, and it’s just a bunch of matrix code looking stuff(I would copy and paste it here (as an example for ONE of the apps I use, but I don’t think you guys want that).

I have not tried that, because I am still able to limp my way through some of these crashes by resetting phone, and then not repeating the things it doesn’t like.

I don’t know what that is :slightly_smiling_face:

I think we had an Update this week (or at least I did), and things have a little more smooth eve since; but I was just trying to other users feel of it, so far.

Yea, I just don’t know where to turn here, because I don’t wan to risk posting things here and then later get :poop: on because i’m “violating” forum rules or something.
But yes, I will start to make a list of names & occurrences for the problem childs.

Yea, I have no idea what most of that means; but yes, I will try toggling that on said app, when/if it happens again, and see what the results are.

1 Like

Please use the Graphene communication channels to report these issue, with full stacktraces and whatever they need.

Maybe there’s an app issue, an app issue with their hardened_malloc (pretty please look at Android - Apps - app-that-crashes → find something about memory or hardening or security whatever)

I suppose I could, and will when I get around to it; but that’s not what I made this post for.

Yes, I will.

I’m still not sure why you did

Apps crash? Report to their devs

Apps crash ONLY ON ONE OS? Report to the OS devs (too)

F-Droid should not be in the middle of those reports (unless the app is NOT reproducible, and the app installed from F-Droid has the issue BUT the app installed from the dev does not)

If you reread the first QUESTION (OP), you should see why.

Well no where in this post did I say it should, but if you want to include it here, ok.
It was merely a question to see if anyone (which sounds like an official F NO, from your replies and everyone’s silence) agreed to the logic that it should, since it is the platform the hosts these apps, and would be helpful to both the users & the developers? to do so ( in my trivial opinion) for reasons I mentioned in another post.
That’s all.

Grapheneos? Love it!


How do you like it’s interface with F-Droid?
Any details you like/dislike?

My main suggestion is: stay away from GrapheneOS.

Here is one example, their Gmscompat feature, which, they claim, prevents Gapps from exercising high level permissions. The feature allows to install Gapps into data partition where 3rd party apps also reside. The claim is, Graphene ‘sand boxing’ doesn’t allow System level permission, if the app sits in Data partition.

Some references to AOSP code:

  1. Gapps are built as System apps, i.e., with system_uid flag. That’s a fact. No third party app can be built with even a single system-level permision: the build WILL stop with an error - ‘system level permissions not allowed in third party apps’.

  2. Gapps also built with a root_uid flag, as otherwise, Google services framework etc., won’t be able to have the full control over your device, which it does.

  3. AOSP code automatically grants permissions to anything with system_uid and root_uid flags. Here are just 2 examples from the code:

Look at lines #1065 through 1069. The java code is this:

if (uid == Process.ROOT_UID || uid == Process.SYSTEM_UID) {

// Root and system server always pass permission checks, so don't touch their app // ops to keep compatibility.

return; }

Look at lines 8388 through 8391. The same flags and same granting of permissions:

private boolean verifyPackage(String packageName, int uid) {

if (uid == ROOT_UID || uid == SYSTEM_UID) {

//System and Root are always allowed

return true; }

Note AOSP dev’s comments: Root and system server always pass permission checks’ and ‘System and Root are always allowed’. That tells you all. In addition, location of the app doesn’t matter. You can have any root app in Data and yet it would still be able to exercise Root. The only difference between root apps and Gapps/GSF is that the latter acquires those permissions silently.

So, Gmscompat isn’t just a failure, it’s a dangerous failure, because users get a false sense of security, while in reality, they have NONE.

MOD EDIT: These are personal opinions. Also post edited to clear off the heat.

EDIT: I had no idea opinions were forbidden, but I guess mods can do whatever they want. Also, AOSP code is not a bunch of opinions, but hard facts, and so is the fact that Gapps are built as System apps with high level permissions.


Huh. To tell you the truth honestly even though I am a grapheneOS user I never trusted the compat layer anyways. Or them for that matter

Cause even if it wasn’t for that I do still believe that the google services can still grab way too much sensitive information as it is which the devs have openly admitted to being a issue still.

Then you get to the issue of requiring a google account for the play store is problematic as it can be troubling if there’s a app you want to use that uses the playstore install as a anti tampering mechanism. I don’t really have any of these apps but still.

One of the extra benefits that comes with a microG installation ofc. The main takeaway here is that sadly no matter what you do installing google play services or microG in any form is going to bring a big decrease in both privacy and security. No “solution” or “reimplementation” should be trusted whatsoever

1 Like

The purpose of my post was not the failed Gmscompat, which was just an example, but to show credibility or lack of it in the development.

Gmscompat is one of the main advertising puffs. GOS claim they can literally ‘teach’ Gapps to behave well. You saw the proof to the contrary above.

So, if GOS developers don’t know that Android grants permissions automatically to System and Root Uids, then they don’t know much about Android at all and can’t be trusted. If they do know about permissions, then they are misleading users, i.e., their claims are false, You pick which one is worse.

There isn’t a third option here… .


I am not very familiar with Android, or general phone, code; but I know a thing or two about statement/scripted text code, and it seems you are correct about the couple of lines you provided.

Assuming you are also correct about your observations of GOS; what is a user with a Pixel7 to do?
What other practical, user install (and F-Droid) friendly OS is there available for Android (pixel 7 specifically) users?


You’d be better off with CalyxOS or even Lineage, and if you need Gapps, you can use MicroG.


I personally am wanting to switch to divestOS as I am very much fond of the developer and their works. But sadly I don’t think there is a release for a pixel 8 pro yet provided there will eventually be a release that is.

CalyxOS is good but I’m not really sure how much of a incentive it would be for me to switch to that apart from the obvious. Will have to do some research

Until then I guess I will wait. Gives me time think about how to backup my data too as I am still looking for a effective way to backup data locally and effectively. Preferably without a computer

1 Like

Not a fan for various reasons.

The first thing I noticed about GOS was how they go around literally everywhere and bash other developments. Here is a typical GOS quote: ‘Others just pretend to have security’. Next, they shamelessly insert links to their own development. They even do that in other developers’ threads. That is, in my view, a reprehensible behavior.

Divest dev is known for doing the same.

But it is your choice, of course.