The reason microG didn’t help is that it’s solving a different problem. It reimplements the Play Services APIs, so push notifications and maps come back, but it can’t produce a Play Integrity verdict — that needs an attestation signed by Google and tied to a locked bootloader and the device’s hardware keystore. Banks almost always check MEETS_DEVICE_INTEGRITY, and nothing running in userspace can fake it.

So “a bank whose app works without Play Services” really means “a bank that doesn’t call Play Integrity”. Annoyingly that’s the question to ask them and nobody in support will know what you’re talking about.

On the 2027 verification thing driving this: from what’s been written about it, it applies to certified devices, which means ones shipping GMS, and non-certified ROMs sit outside it. If that holds then degoogling removes that worry rather than racing it. I haven’t seen Google state it in their own words though, so I wouldn’t plan around it yet.

The empty permissions page is weaker evidence than people in here are taking it for. That screen only lists runtime permissions, so INTERNET, ACCESS_NETWORK_STATE, FOREGROUND_SERVICE and the rest never show up there whether or not an app has them. Plenty of apps with a blank page can still open sockets.

The manifest line is the actual claim, and it’s a much stronger one. Anyone who wants to check it without taking your word or mine: on the Play listing, About this app → App permissions → See more is extracted from the uploaded build, not written by the developer. Or aapt2 dump permissions on the apk. Both show the normal permissions that the on-device page hides.

The answer depends on which switch you actually used, and the two that look alike behave very differently.

If it was “Background data” (or Data Saver’s per-app restriction), that only blocks the app on metered networks while it is in the background. The moment you open the app it is foreground and the restriction no longer applies — Android exposes this to developers as getRestrictBackgroundStatus(), precisely so an app can tell when it is allowed to transmit again. So anything it banked while restricted goes out the next time you open it. For a data-collecting app that is not a meaningful barrier, because opening it is the normal case.

If your OEM gives a genuine per-app “Allow network access” toggle covering both Wi-Fi and mobile — Samsung and Xiaomi do, stock Pixel does not — that one is enforced on the UID and does block properly, foreground included.

Worth separating the two things in your question, because they are not the same:

• Transmission is what blocking stops. That part works, with the caveat above.
• Collection continues regardless. The app keeps reading whatever it has permission to read and writes it to its own storage. Nothing about network blocking touches that, and it is all still there when access comes back or when you uninstall and the data has already synced through something else.

So “do I need to worry” — yes, but about a narrower thing than it first looks. A blocked app cannot phone home while blocked. It can collect the whole time, and it transmits on the first opportunity. If the goal is that it never has the data at all, the permission screen is the lever, not the network one.

On the VPN-slot problem further up: Android permits exactly one VpnService at a time, which is a hard OS limit rather than something NetGuard chose. The only real ways around it are a firewall that carries your VPN inside it, as suggested with Rethink, or going at it from the DNS side instead.

I shipped an app under a hard rule that android.permission.INTERNET must not appear in the released manifest, so I went looking for this systematically. Answering your actual question, and then the part of this thread I think is wrong.

I checked a handful of library manifests directly rather than going from memory, and got two of my own guesses wrong, which turned out to be the useful result:

• Firebase declares it per module. firebase-crashlytics, firebase-config, firebase-perf, firebase-firestore, firebase-storage, firebase-database and firebase-functions each declare INTERNET in their own src/main/AndroidManifest.xml. Crashlytics on its own is enough. Most people expect Analytics to be the culprit and add Crashlytics without thinking.
• Glide does not, and neither does Coil. I was fairly sure they did. In both repos INTERNET appears only in the sample apps and instrumentation tests — Glide expects you to declare it.
• ExoPlayer / media3 does not either, same pattern: demos and androidTest only.

So the honest answer to “which libraries are the common offenders” is that you cannot predict it, and the two I would have warned people about were clean. That is the argument against the “you should have checked your merged manifest” line in this thread — not that checking is wrong, but that it is a one-time read of a build artifact. Six weeks later someone bumps a version, the permission comes back, and nobody reopens manifest-merger-release-report.txt.

What holds is a check on the shipped artifact, in CI:

aapt2 dump permissions app-release.apk

That reflects what the store is actually serving rather than what your source says. Fail the build if INTERNET appears and the question stops depending on anyone remembering. It has caught a reintroduction for me once already.

One trap if you go that way: tools:node="remove" will strip the permission from the merged manifest, and if the library genuinely needs the network you have turned a build error into a runtime crash on a path you may not test. Dropping the dependency is the real fix, as you did with ZXing.

Your first takeaway deserves underlining. Exodus is signature matching against known trackers, so “0 trackers” means “none it recognises”. The permission list is extracted from the binary. Different kind of evidence entirely.

Worth flagging a catch with the per-app rule approach: blocking the app on Wi-Fi isn’t the same as forcing it onto 5G.

Android routes an app over whatever the default network is, and that’s Wi-Fi whenever Wi-Fi is up. A per-app firewall rule denies the app on Wi-Fi — it doesn’t reroute it to cellular. So the likely result is the app has no connectivity at all while you’re on Wi-Fi, rather than quietly using 5G. Only the app itself can pin to a transport, by requesting a network with TRANSPORT_CELLULAR, and almost none do.

For the lag you’re actually describing — commands dropped during the 5G/Wi-Fi handover — the thing that usually helps is stopping the handover happening at the moment you press the button, rather than per-app routing. Worth checking whether your smart home app has a local/LAN mode that talks to the hub directly instead of round-tripping through its cloud, since that removes the problem instead of working around it.

Happy to be wrong if someone’s got Rethink actually moving an app onto cellular while Wi-Fi is connected — that’d be useful to know.