Heck I'd want an option to freeze apps once I'm logged in & only unfreeze them when I need to use them. Would absolutely improve battery life.
[1] Private Location - https://redplanet.gitlab.io/fdroid-website/en/packages/com.w...
[2] Shelter - https://f-droid.org/packages/net.typeblog.shelter/
[3] SuperFreezZ App stopper - https://f-droid.org/en/packages/superfreeze.tool.android/
---
EDIT: According to https://f-droid.org/pl/2023/10/19/twif-client-alpha-kde-remo...,
> Private Location was also removed as was no longer functioning and development has stopped years ago, as reported in #3096 (https://gitlab.com/fdroid/fdroiddata/-/issues/3096).
That is a shame. The other applications are fine, at least.
The best answer is to make the sensitive parts open source. Then anyone can review it themselves if they're so inclined, including you. And since some software developers and large organizations actually do this, it's difficult to get backdoors into popular projects without anybody noticing.
Notice that the xz attack was detected before it made it into e.g. Debian Stable or the distributions based on it.
The best answer to "who watches the watchers" is everybody. The prerequisite for which is for everybody to be able to see what's going on in the places where there could be something fishy happening.
Android apps have had bad habits for a very long time because Android didn’t have the granular runtime permissions system like iOS did (Android had only install time permissions that was either grant all or no install allowed). Even though Android brought granular runtime permissions from version 6 (?), apps have continued to badger users for every permission that allows them to collect more data. Android users have also been conditioned from the beginning to provide all permissions. So apps expect them to provide what they ask or refuse to work.
On iOS, Apple has stated in its policies for a long time that apps should continue to work even when permissions are denied (with obvious caveats, like for example camera not working if camera permission is not granted).
It’s a stark and disturbing contrast when comparing how Android apps refuse to work whereas the same app by the same developer on iOS would be a lot better behaved even when various permissions are denied.
BTW, Truecaller on iOS will work without getting permissions to access contacts. It will also work if it’s not given access to SMS.
Big Plus for being easy installable from the Graphenos Appstore Applications. It currently offers 8 applications and 4 of them are GraphenOS own applications.
If you give SuperFreezZ App stopper permissions (it needs to be registered as an accessibility service, and requires usage access as well) to check for usage of applications, then it will freeze unused applications automatically. You can even specify after how many days of not having used them you want to freeze them.
Requests for access to files, location, mic, and camera usually give me the option of allowing them all of the time or only when the app is open.
I've also noticed system notifications stating that permissions will be used from unused apps.
Greater configurability is always nice though.
Managing running apps is still a nightmare though.
I regularly go through the battery history of the previous night, to see if any apps were running while I slept.
So far I've, for example, found my banking app running something called a telemetry service, in the background, even if I set its battery profile to restricted. No way to stop that other than to uninstall the app.
GrapheneOS has one more feature that almost solves this called "Disable app". The downside is that it will remove the app from your home screen and it is a pain to re-enable it.
My current workaround is this:
I use a custom home screen shortcut app to create a shortcut to the settings page of the app I want to disable. Then each time I want to use it, I tap it on the home screen, tap "Enable", tap "Open" and after I'm done I tap "Disable" one more time and close the settings.
However now I've found a new culprit eating my battery. I use Google Meet through a browser, since the app won't work without Play Services. The browser I use for this is Brave. Now every time I leave a meeting, Brave will be listed as using most of my battery when idle. Nothing will remove it. Force stop, nope. Running services list, not listed. Only restarting the phone will stop it.
With all the rabbit holes I've gone through, I've only come out with one response to all this: "This is how Android is designed to work." so I'm not hopeful this will ever get better.
Have you considered creating a new 'banking' user account that you only log in to when you need to access that app? Its incredibly easy with Graphene.
...but ofc most app makers are lazy and just throw up error whenever they don't get what their wont, forcing users to give up.
I guess google could introduce a dummy system for every single service and feed that to the apps when the permission is not granted, but I imagine that would be a lot of work. Maybe some day...
It’s just another layer of crap that moves smartphones one step closer to being as ridiculously complex as Windows PCs.
So, useful computing devices? I'm for anything that pushes this plastic toy towards being a real tool.
Even stuff like weather apps.
Everything weather related, I uninstall, and if it is bloatware I "pm disable-user" in shell
There's three states of permissions in android land from a permission request perspective:
* Granted. Just full access to all things behind the permission, no questions asked.
* Ignore. Returns no rejection, but all permission-restricted functions will return no/default data. This can technically be checked for by the app but usually isn't.
* Deny. No data, return an explicit error to the app to tell them the permission isn't granted.
For some reason that second one isn't available for the default UX; you need to manually set it with ADB or use App Ops to do it.
You can just activate it, change the settings and disable it afterwards. Pretty annoying but it is what it is.
This doesn't require root either, although enabling USB debugging is an important step towards rooting, which is probably why you think it's related.
I have this on Android 13, it's called "pause app" and seems to do just this. Might not be available on all variants tho, I'm running crDroid.
Yeah, definitely. It would be so nice to have that built in. With LSPosed and XPrivacyLua, you can block/give garbage data to a lot of permissions, including contacts, though unfortunately it only works by sharing your favourites, with no way to configure a per-app list.
If the user doesn't want that happening for a particular application, the user should be able to turn it off. Mobile OSes have given way too much control over to developers. Whose device is it anyway? The user's or the app developer's?
If you ask most senior citizens or simply most users of computing devices to explain what they think about "background services", most won't know what you are talking about. Just because a functionality has been present in a system for a while does not mean that everyone will know about it. Ask people about dual booting, most won't know about it. Ask most people about "SSL", most won't know about it. Ask users about the command line, most won't know about it. And so on. Even the abstract concept of a search engine (separate from the concept of Google Search) is likely to fly over the head of many people. You vastly overestimate your audience. Let's put it this way: most computing devices nowadays are mobile phones and for many people this is their first and main interaction with computation. The modern ubiquity of phones is bigger than that of personal computers by an order of magnitude imo. Personal computers were huge but mobile phones have a level of penetration PCs could never reach.
When you buy a device, you agree to the terms of service. Most manufacturers like Apple have something along the lines of "don't interfere with the proper working of the system". Freezing apps sound like it breaks the ToS.
Buying a device is less like buying a toothbrush and more like buying a tractor. You don't own it inconditially. You own it under certain terms. Those terms give the manufacturers lots of power.
Have you personally asked them? I think you'd be surprised. The #1 end user smartphone concern is around battery life, and end users, across all ages and technical sophistication are at least vaguely aware that their phones "do things" that they can't visibly see and that it's often what drains their batteries. Senior citizens aren't fools. They might not know the technical details of what exactly is happening on their phones, but they are absolutely aware of battery-draining things going on unseen in the background.
And even if they weren't aware--that doesn't address my main point: The end user should ultimately be in control of their device's function, not the app developer. If there is a conflict between what the end user wants to do and what the developer wants to limit them to, the end user should win.
You can desire all you want. Doesn't change the reality. You can't truly have control without understanding. All it means is that users will get some user defaults (and the device will function exactly as it does now) or worse, they will be compelled to change the user defaults to their detriment (and to the benefit of a third party). There's a fundamental information asymmetry. This is the source of the power imbalance and giving more "control" to users (who already struggle to understand the one they already have) won't fix it.
It's not too different from consumer protection laws. Consumers have a limited understanding of their power while companies have a wider understanding. This means that overall companies win and there needs to be a knowledgeable third party constantly watching and advocating over the interests of the consumer.
Techies have this tendency of trying to fix every problem with tech, even when it doesn't work (looking at every problem like a nail that can be hammered). You can't fix this with more tech. A better solution (by no means an optimal one) is to have public free phone tech knowledgeable advocates that people can see in person to talk about their problems and desires regarding their device.
If there's an app that I only need when I open and don't care for it bg service then I should be able to tell it f off. devs might think their widget phoning home everytime is worth my battery time, I might think otherwise.
Not every app needs to be a web app or use internet yet most apps nowadays do. Either you allow ALL apps to have it or you don't. You will think that devs would make apps that don't need background services. It won't happen. What will happen is that every time you open the app, you will be nagged to allow background services to run. The only thing that would stop it is for that feature to not be available at the application level.