Which GrapheneOS toggles break banking apps, and which can stay on?

Sandboxed Google Play has to be installed, and the bank app has to be allowed on the network. Those two are the toggles that decide whether a banking app on GrapheneOS even gets to a login. Sensors, microphone, camera, and a Google account can stay off. There is no switch that turns Play Integrity’s strong check into a stock Pixel, and flipping random exploit-protection options will not invent one.

I use a Pixel on GrapheneOS for the phone I actually carry, and I keep a second, stock Pixel for the two apps that refuse this one. The split is not mystical. It is a short list of permissions plus one attestation the bank may demand and GrapheneOS will not fake.

Which toggles have to be on for the app to open?

Install sandboxed Google Play from the GrapheneOS Apps store: Play services and the Play Store, as GrapheneOS ships them, not a random GApps package. A lot of bank apps crash, spin, or say the device is unsupported when those are missing, before they have checked anything clever. They were built assuming Play is part of the phone.

Then grant that specific app the network permission. GrapheneOS asks. Stock Android lets the app talk and shows you a chart later. If network is denied, the app can look installed and still be unable to log in, load a balance, or send the approval ping. This permission stays on for the bank. It can stay off for everything else you installed out of curiosity.

Notifications for that app are the third practical on-switch, and only if the bank’s “approve this login” or card-present prompt arrives as a push. Deny notifications and the login page will sit there while the approval lives in a banner you will never see. If the bank still does SMS or a hardware key, notifications can stay off. Read the prompt the app actually uses before you decide you are being private. You might just be hiding the yes button.

Which toggles can stay off?

Sensors can stay denied. A bank does not need the accelerometer to show a balance. A few apps use motion as a lazy integrity hint or for a “shake to confirm” gimmick. If the app explicitly fails a step that says it cannot see the device move, grant sensors for that app only, then revoke them if you do not use that step. Do not grant sensors globally because one screen looked sad.

Microphone and camera stay off until the day you deposit a check or do a video identity check. Grant them for the session if the flow demands it, and turn them off after. Storage scopes beat “allow all files.” The check image is a photo you picked, not a reason for the app to browse the library.

Location stays off unless a branch finder or a card-control feature you actually use refuses to load without it. Login and transfers do not need GPS. Nearby devices and Bluetooth stay off. The bank is not your headphones.

You do not need to sign the phone into the Google account you use for mail. Sandboxed Play can exist without that account, and a bank app can be installed from the Play Store UI once, or sideloaded if you trust the file, without turning the phone into your Gmail inbox. A separate GrapheneOS user profile is the cleaner version: Play and the two stubborn apps in one profile, the daily profile without them. Profiles are not a toggle inside the bank. They are how you stop the bank’s process from sitting next to your messages.

What looks like a toggle and is actually attestation?

Play Integrity is the part people try to flip and cannot. Some banks only need the app to run and a login to succeed. Sandboxed Play is enough, and I have used official apps that way. Other banks ask for a device integrity verdict GrapheneOS does not claim to pass, because this is not a Google-certified OS and the project does not ship a way to pretend otherwise. When that happens the app opens, lets you type, and then refuses. No compatibility checkbox fixes a policy on the bank’s server.

Do not go looking for a module, a patched services build, or a “make it look stock” switch. That is not a GrapheneOS setting. It is an attempt to lie to the check the bank is using, and it breaks the reason you installed this OS. If the app will not negotiate, it belongs on the stock phone in the drawer, or in the browser if the bank’s site works in Vanadium. Vanadium is enough for a surprising number of logins. It is not enough when the bank has decided the only client is the attested app.

When does exploit protection actually crash a bank app?

GrapheneOS hardens memory allocation for every app. Most banks survive it. A few, usually older ones with sloppy native code, die on launch or die when you open the check scanner. The per-app fix is the exploit-protection compatibility mode for that app, not a global disable. Turn it on for the one package that crashes, confirm the crash is gone, and leave every other app on the strict default.

That mode is a compatibility shim. It is not a privacy feature you score points for leaving off, and it is not something you enable for the whole phone because a forum post said banking is fragile. If the app still crashes with compatibility mode on, and sandboxed Play is installed, and network is granted, you are probably looking at attestation or at an app that detects the OS and exits. Compatibility mode will not talk it out of that.

Secure app spawning and the other global exploit settings should stay where GrapheneOS put them. Turning them off to “help banks” widens the hole for every app, and the banks that were going to refuse you will still refuse you.

Which failures are permissions you will misread?

A blank balance is often network, or a VPN, or a private DNS resolver the bank’s certificate pinning does not like. Test once with the VPN off before you reinstall Play. A push that never arrives is notifications, or battery treatment if you also forbade background use so hard the app cannot wake. GrapheneOS will let you restrict that. The approval ping is the feature you restricted.

A camera error on a check deposit is the camera permission, not Integrity. An app that cannot see the PDF you just downloaded is storage scopes. Fix the permission the screen is actually complaining about. Reinstalling the OS because a file picker failed is how an afternoon disappears.

Updates matter more than people admit. A bank app update that suddenly demands a newer Play services, or a GrapheneOS update that changes a compatibility edge, shows up as “it worked last week.” Pin the failure to the date. If it broke the morning after an app update and the error mentions the device or security, that is attestation or a new requirement. If it broke and the error mentions connection, that is the network toggle, the VPN, or their outage.

What about the SIM, SMS codes, and a second profile?

GrapheneOS does not change which radio holds your number. If the bank texts a code, the code arrives on the SIM that receives SMS, whether or not you denied every permission in the app. People debug the OS for an hour because a code went to the other line, the travel eSIM, or a message app that is not the default SMS app. That failure is the line, not exploit protection.

A second user profile keeps Play and the bank off your daily profile. It also means the notification for an approval only exists in the profile that is logged in, or on the lock screen if you allowed it to show across profiles. Test an approval after you switch back to the daily profile. If the prompt vanished with the switch, you will miss a card check while you are reading mail. Either allow that notification on the lock screen, or accept that banking happens when that profile is in front.

Who should not run the bank on this phone?

Do not put your only salary account on GrapheneOS if you have already watched the app refuse a transfer once and you have no second device. The day it refuses will be the day you need the transfer. The stock phone in a drawer is annoying. It is also the plan. I hate the drawer. I use it for the apps that want a certified device, and I do not keep inventing toggles to avoid it.

Do run the bank here if the app logs in, shows the balance, and approves a small transfer while sensors and the camera stay denied. That is a successful test. Leave Play installed, leave network on for that app, leave notifications on only if pushes are the approval, and stop toggling exploit protection because a blog said banking is special.

The toggles that break banking apps are the ones that remove Play, remove network, hide the approval notification, or crash that one app until compatibility mode is on. The toggles that can stay on, meaning stay strict, are sensors, microphone, camera, location, and the absence of your everyday Google account. Integrity is not in that list. If the bank requires a verdict this OS will not give, the setting you are looking for is the other phone, not a switch you have not found yet.