AnubisProductions

joined 1 week ago
 

I wrote this, so disclosure first.

It measures per-app mobile data against your billing cycle rather than the calendar month, splits what you spent using an app from what the app spent on its own while the screen was off, and blocks apps per network, so something can be dead on mobile data and completely normal on Wi-Fi.

The part I think actually belongs in this community is the permission. There is no INTERNET permission in the manifest. Not a privacy policy promise, it is simply absent, so Android will not let the process open a socket at all.

What interests me is that you do not have to read the source to verify that. One command on the APK prints six lines and INTERNET is not among them:

aapt dump permissions DataSaver-v0.8.apk

The source being public is good for plenty of reasons, but it is not what makes this particular claim checkable, and I think those two things get conflated a lot. Most people who install a FOSS app never read a line of it. A claim you can check from the artifact itself is worth more than one you can only check by trusting that somebody else read the repo.

Under the hood it reads NetworkStatsManager for the figures and uses VpnService in package-list mode with no packet forwarding for the blocking. Both plain AOSP, no Play Services dependency. The only library it pulls is androidx.core-ktx.

GPL-3.0, free, no ads, nothing to buy, no accounts, no analytics, no servers. Android 7 and up.

The honest gap: right now it is only distributed through Play. The F-Droid request has been open at fdroid/rfp#4520 since 8 October, which as far as I can tell is normal queue time rather than anything wrong. Until then it builds from a clean clone.

https://github.com/anubisproductions/data-saver-usage-blocker

 

Disclosure first, I wrote this, and I'll keep it short since the rule here is justified or not at all.

It measures per-app mobile data for your billing cycle rather than the calendar month, splits foreground from background, and blocks apps per network so something can be dead on mobile and fine on Wi-Fi.

Why it's relevant here rather than just another utility. It has no INTERNET permission in the manifest, so it cannot phone home at all, and it has no Play Services dependency. The only library it pulls is androidx.core-ktx and there is no com/google/android/play anywhere in the release dex. It reads NetworkStatsManager and uses VpnService in package-list mode with no packet forwarding, both plain AOSP, so nothing about it needs Google on the device.

The one part that sounds wrong for this community is the protected-apps list, so I'll explain it rather than let someone find it. There's a fixed list of push carriers the app refuses to block, because blocking the thing that carries push silences every notification on the phone and people do that to themselves without realising. It includes Play Services, but also Samsung, Xiaomi, Huawei, Honor, OPPO, vivo and Meizu push, since those matter more in the markets this is aimed at. Matching is by package name and anything not installed is skipped, so on a degoogled phone with no Play Services there is simply nothing there to protect and you lose nothing. The Play Store itself is deliberately not protected, you can block it, which on my test phone was the single biggest consumer at 444 MB a cycle of background auto-updates.

The honest gap: right now it's only distributed through Play. The F-Droid request is open at fdroid/rfp#4520 and has been waiting since 8 October, which from what I can see is normal queue time rather than anything wrong. Until then it builds from a clean clone if you'd rather do that.

GPL-3.0, free, no ads, no purchases, no accounts, no analytics. Android 7 and up.

https://github.com/anubisproductions/data-saver-usage-blocker

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.

[–] AnubisProductions@lemmy.world 2 points 1 week ago (1 children)

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.

[–] AnubisProductions@lemmy.world 3 points 1 week ago (1 children)

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.