Using exact alarms is already exposed to users in special app access. Users can disable it. It's currently granted at install time and it's not a privacy related feature but rather a battery saving one which is perfectly fine and matches other things like background restrictions.
Conversation
If an app can query all user installed apps and you don't show it as having QUERY_ALL_PACKAGES but you show other apps as having it, you are misleading users into thinking app without it can't do what they can do via explicitly listed queries. Can also detect apps without either.
1
5
That is part of why simply the existing "All permissions" view is harmful. It should only be there if you enable developer options. They should also either remove the highly misleading user facing strings entirely and only show the permission names or give actual descriptions.
1
3
The actual descriptions would be for developers. At most the low-level INTERNET permission is something that should be a user facing runtime permission, and one day QUERY_ALL_PACKAGES + queries could be user facing but not as a permission toggle since it's more complex.
1
3
Aside from that, they are entirely missing any kind of permission for most sensors access. They have restrictions on what can be done in the background, but that's it. There is absolutely no low level permission for stuff that can be used to record movement / direction or speech.
1
2
We add Network and Sensors permission toggles in GrapheneOS. It would be nice to at least get Sensors in Android itself, especially since the lack of even a low-level permission for it means we have to mark all apps as requesting Sensors with a Sensors toggle for all of them.
1
4
The only way to make QUERY_ALL_PACKAGES + queries work as a user facing permission would having a permission which fully disables BOTH of them and draws no distinction between intent-based queries and QUERY_ALL_PACKAGES because there is really no actual difference in practice.
1
3
These are some pretty good points. They all seem based on the viewpoint that permissions = privacy/security feature though. Is that ALWAYS the case? I can't think of anything off the top of my head, but I imagine some permissions could be used for controlling device behavior, etc
1
I'm also generally averse to the idea of hiding things from users. I'd much rather have an explainer for things and expose it to users than hide it simply because a user might not understand it.
1
The vast majority of this is already user facing. The low level permissions enable the user facing toggles. That's how it works for all the runtime permissions and also most of the supposedly install time ones despite them actually requiring consent and having toggles.
1
2
The user-facing functionality is not only for privacy, security and battery life. It covers control over the device too. Also, the simple fact is that listing stuff an app can do at install time is wrong since the user should be able to deny it and still use the app.
Android knows it is wrong and has completely stopped listing things at install time itself since instead of gives runtime controls over everything that has been deemed to matter with INTERNET being essentially the only exception that's very questionable (and not just incomplete).
1
2
Which low-level permission is there that is actually relevant in some way to users due to actually controlling whether something can be done but is not already user facing with a toggle to either opt-in (most of them) or opt-out (a few like exact alarms / restricted battery use)?
1
2
Show replies
That's a really good point about denials and still functioning. Looking at you, .
I'd still like to see all the bitty gritty details though. Maybe have an advanced toggle to show everything in the app info page or something, for nerds doing nerd stuff. ¯\_(ツ)_/¯