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.

Not on the concept, but on one of the features you listed: “a cap on how many times you open something” is harder than it looks on Android, and it’s worth knowing before users start reporting wrong numbers.

If you’re counting with UsageStatsManager.queryEvents, ACTIVITY_RESUMED fires more often than a person would call “opening the app”. It fires again when you come back from a second activity inside the same app, and on configuration changes — rotation, theme switch, font size — because the activity is recreated. Counting raw resume events overcounts, and worst for exactly the apps people want to limit, since those tend to be multi-activity.

What holds up better is tracking foreground package transitions: only count when the newly resumed package differs from the previously resumed one, and debounce a few seconds so bouncing out to a notification and straight back doesn’t register as a second open.

The other thing, if you haven’t hit it yet: there is no supported way for a third-party app to actually block another app. Digital Wellbeing uses privileged APIs that aren’t available to us. Everything else ends up on an AccessibilityService or a draw-over overlay, and both carry real costs — accessibility use is restricted on the Play Store and needs justification, and polling the foreground app aggressively shows up in battery stats, which is its own kind of uninstall.

Worth separating two things that get collapsed: blocking network access stops transmission, not collection.

With the toggle off, the app still reads everything its permissions allow and can cache it locally. Nothing leaves while the block holds — that part works, it’s enforced by the OS. But the data is sitting there, and the moment network comes back it can be flushed: you toggle it on to use a feature, you restore a backup, an update or a ROM change resets the setting. You’ve deferred the upload rather than prevented the collection.

Two gaps that toggle doesn’t cover either: a blocked app can still hand data to another app on the device via shared storage or a content provider, and that app can send it. And blocking app A does nothing about the same analytics SDK sitting inside app B.

For icon packs and launchers specifically there’s a stronger check than blocking — look at whether the app declares the INTERNET permission at all. An app without it cannot open a socket; the kernel refuses, no matter what the code wants. That’s enforced rather than configured, so there’s no setting to forget. Most icon packs are just resource bundles and need no permissions at all, so a launcher or icon pack asking for INTERNET is worth a second look.

One catch: INTERNET is an install-time permission, so it doesn’t show in the runtime permissions screen on your phone. You’ll see the full list on the Play listing under About this app → App permissions → See more, or with aapt dump permissions if you have the APK.

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.