I actually want Play Store apps to be equally configurable. Apps like Truecaller refuse to work without so many permissions. Being Android you'd expect some way to provide a dummy contact book, location & other accesses that apps need.
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.
In Developer options you can select a mock location app like Private Location[1], and there is an app named Shelter[2] that allows you to freeze and unfreeze (depending on what you mean by the terms, you may want the last mentioned app, see [3]) applications in your personal and work profile (and to isolate and run multiple instances of apps using Work Profiles). Additionally, you might find SuperFreezZ App stopper[3] useful and it might be what you are looking for. It allows you to entirely freeze all background activities of apps (unused apps, too, automatically). All of the apps mentioned work without root, and are worth checking out.
Wasn't Private Location removed from the store though? If it's the app that I'm thinking about I used it before but it stopped working because the map API changed which broke the app and it never got updated, so it was removed. There should be a github issue about that somewhere.
My concern with apps like Shelter, Insular and Island is: who guards the guards? How confident can I be that an xz-type attack hasn’t been made on them? Who are the individuals behind such projects, and what nation-states and influences are they subject to?
I can't find private location in the f droid app and the APK downloads don't work. I tried fake traveler but it was crashing constantly and was not able to fool organic maps
> Apps like Truecaller refuse to work without so many permissions.
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.
Do a CTRL-F (or CMD-F) through these comments and look for the word "refuse". It comes up way too often. This seems to be a huge problem: Apps taking it upon themselves to "refuse to work" until the user gives in to their demands. It's like a hostage negotiation. Developers really shouldn't have the power to say "well I'm in charge, user, not you, so fuck off."
I'm a big fan of how iOS lets you decide which images are available from the camera roll. So the app can have "access" to the camera roll but there is that intermediate stage where I can scope down which images are in it.
Some iOS apps like Google Photos refuse to work unless you give them full access to the camera roll. I don’t know how they detect the limited access scope, but it is a fundamental design flaw that it is possible at all for an app to do this.
GraphenOS offers that, since the Playstore/Google Applications are non privileged applications.
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.
As others have mentioned GrapheneOS does give some control back to the user. You can set up contact scopes and file access scopes, you can remove the Internet permission as easily as any other permission.
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.
> 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.
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.
The way I do it to freeze apps is using focus mode. You can flag these apps as "distracting" and enter "focus mode". Their icons will turn gray, only run when explicitly opened, and auto-freeze in 5 minutes. After 4 minutes a notification appears to extend this run time. This works for me for most of the cases.
It's up to app maker to ensure it will work without permissions granted.
...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...
Dummy/empty data is already a thing in Android if I'm not mistaken. It just needs ADB/App Ops to activate it.
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.
Android already does something like this for location services. For example, give precise location vs approximate location. And then for other permissions, there's a popup for whether to give permissions only this time, always, or to not. I guess there could be a 4th option for "mock" permissions. I wonder if an OEM could provide something like this because at the end of the day, the OEM has control over the sensors that are providing the data that's consumed by these apps.
Providing dummy data would also diminish the value of Android users to Google itself, unless they give themselves an exemption from such a setting which would mean they would be dragged to court by the competition.
The question you need to ask, how would this profit Google? It's an advanced setting that would need user interaction, a fraction of them would do this. This "Enhanced Confirmation" is also about automatic restriction.
> Being Android you'd expect some way to provide a dummy contact book, location & other accesses that apps need.
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.
Afaik disabling apps is built into Android but not directly accessible. I think there's a way to do it with ADB. SwiftBackup can also freeze & unfreeze
If i have an app I installed once and forgot about it i probably dont need it to run in the background either. This is for those situations. Apps that I use, won't be frozen.
Less and less my phone. I want the small apps which I develop for myself to have all the access without any restrictions. It's getting worse and worse and I wish they'd allow me to whitelist my apps somehow so that they get the same access as system apps do. And if this would mean that I can't use Google Wallet, then at least all the permissions which don't affect apps like Google Wallet.
> Malicious Android apps, no matter where they’re sourced from, commonly try to trick users into granting them access to the Accessibility and Notification Listener APIs because of their power.
So does Gadgetbridge. I've had devices where Android wouldn't allow me to give it access to the Notification Listener resulting in me not being able to forward the messages to my Mi Band. In the end this was solvable by using ADB, but this is not ok.
cut the "sideloading" term. It's downloading. Exactly the same we download any other file. It's not some obscure feature. This kind of terminology is word games to make it sound like somebody doing this is inherent using it wrong or must be up to no good.
Its one thing to make it harder to enable stuff. But there absolutely should be ways to say "yes I know what I'm doing".
I'd prefer if we used sideloading for the appstore / playstore. The main location is the website of the developer and the mobile store is a side channel.
Hmm I hope there's still a way to bypass this. I sideload all my apps using aurora store (so I don't have to sign in with a Google account) and I don't want them limited in functionality.
Yes, if you're willing to jump through scare dialogs and search for where in the UI to find "hidden" settings, you can manually override it per app as before.
Aurora isn't an official third party store. There isn't much chance that Google will whitelist it because it's a privacy alternative for the play store itself. Google has been all over it trying to block it so I doubt it will select it as an exception.
> Apps installed from alternative stores (using APIs made for those) aren't subject to those restrictions
These restrictions already exist for in call audio accessibility APIs. At least one call recorder app has gone as far as making their own app store to bypass these restrictions.
Increased restrictions on which programs may run and what they can do are the future of computing. We really can't afford the risks of letting everybody just run arbitrary code. Windows and macOS are next.
It didn't mention apps installed with 'adb install'. I think you might be able to run those with no restrictions. And LineageOS, GrapheneOS, and so forth may give you the option of disabling this feature or making it more configurable.
As far as desktop OSes go, I think the much larger problem is how to let users control the degree of sandboxing an application has. On mobile we're broadly used to each application asking for permissions (and whether we've trained users to just hammer 'allow' until it proceeds) and each is largely independent.
Windows also has its legacy software that wouldn't know about new restrictions, so would need dummy access until allowed, and UI for the user to gain understanding about why their newly downloaded utility can't access their webcam and all their files yet, and how to rectify that. Windows already has something like this through controlled folder access, but I've yet to hear of someone who turns it on. Part of the biggest strength of desktops is how all the software/hardware parts combine, so I think this is high stakes in terms of not pissing people off so the feature actually gets used.
'So today we have marketing departments who say things like "we don't need computers, we need... appliances. Make me a computer that doesn't run every program, just a program that does this specialized task, like streaming audio, or routing packets, or playing Xbox games, and make sure it doesn't run programs that I haven't authorized that might undermine our profits". And on the surface, this seems like a reasonable idea -- just a program that does one specialized task -- after all, we can put an electric motor in a blender, and we can install a motor in a dishwasher, and we don't worry if it's still possible to run a dishwashing program in a blender. But that's not what we do when we turn a computer into an appliance. We're not making a computer that runs only the "appliance" app; we're making a computer that can run every program, but which uses some combination of rootkits, spyware, and code-signing to prevent the user from knowing which processes are running, from installing her own software, and from terminating processes that she doesn't want. In other words, an appliance is not a stripped-down computer -- it is a fully functional computer with spyware on it out of the box.'
The Digital Markets Act (DMA), presumably: the law that forced Apple to allow installing apps from third party sources (though I doubt their current solution is compliant).
Large vendors (gatekeepers) are not allowed to give themselves benefits that their competitors don't have. A third party alternative must have the ability to compete with the gatekeepers, which means Google isn't allows to treat Google Maps specially, Apple isn't allowed to treat Safari specially, and so on.
They can still comply with these laws if they have a quick and accessible method of getting your app store listed in the exemption list (which would quickly run into edge cases from apps like Aurora and the abusive shitstains that install stalkerware), especially if they show their willingness by pre-populating the list with common Play Store alternatives. They could also just disable the feature in EU phones (the way Apple chose to comply with the law) so they don't break the law. Or they could leave the list unpopulated inside the EU, making the OS harder to use for EU users but not exempting themselves as a middle finger to the EU lawmakers (the way Apple tends to comply with these laws).
> Digital Markets Act, a 2022 law that requires Apple to open iPhones in the bloc to competing app marketplaces and alternative payment systems for in-app sales.
Readit News
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.
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...
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.
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.
Deleted Comment
> Malicious Android apps, no matter where they’re sourced from, commonly try to trick users into granting them access to the Accessibility and Notification Listener APIs because of their power.
So does Gadgetbridge. I've had devices where Android wouldn't allow me to give it access to the Notification Listener resulting in me not being able to forward the messages to my Mi Band. In the end this was solvable by using ADB, but this is not ok.
Its one thing to make it harder to enable stuff. But there absolutely should be ways to say "yes I know what I'm doing".
It's explicilty restricted only to apps that don't use the new "app store" APIs in Android.
These restrictions already exist for in call audio accessibility APIs. At least one call recorder app has gone as far as making their own app store to bypass these restrictions.
It didn't mention apps installed with 'adb install'. I think you might be able to run those with no restrictions. And LineageOS, GrapheneOS, and so forth may give you the option of disabling this feature or making it more configurable.
Windows also has its legacy software that wouldn't know about new restrictions, so would need dummy access until allowed, and UI for the user to gain understanding about why their newly downloaded utility can't access their webcam and all their files yet, and how to rectify that. Windows already has something like this through controlled folder access, but I've yet to hear of someone who turns it on. Part of the biggest strength of desktops is how all the software/hardware parts combine, so I think this is high stakes in terms of not pissing people off so the feature actually gets used.
https://en.wikisource.org/wiki/The_Coming_War_on_General_Com...
The pleb running applications they want on the device they own? Madness!
You are, of course, talking about JavaShit right?
Large vendors (gatekeepers) are not allowed to give themselves benefits that their competitors don't have. A third party alternative must have the ability to compete with the gatekeepers, which means Google isn't allows to treat Google Maps specially, Apple isn't allowed to treat Safari specially, and so on.
They can still comply with these laws if they have a quick and accessible method of getting your app store listed in the exemption list (which would quickly run into edge cases from apps like Aurora and the abusive shitstains that install stalkerware), especially if they show their willingness by pre-populating the list with common Play Store alternatives. They could also just disable the feature in EU phones (the way Apple chose to comply with the law) so they don't break the law. Or they could leave the list unpopulated inside the EU, making the OS harder to use for EU users but not exempting themselves as a middle finger to the EU lawmakers (the way Apple tends to comply with these laws).
> Digital Markets Act, a 2022 law that requires Apple to open iPhones in the bloc to competing app marketplaces and alternative payment systems for in-app sales.
I’m always on the fence with this stuff. As an engineer I like having access to my device, and the freedom to tinker.
But on the flip side. It’s obvious to me that these devices that people’s lives revolve around are absolutely critical targets.
Bank accounts, location, 2fa apps/sms, crypto apps, scam calls, literally all the user’s communications are on offer.