It's problematic that they expose those directly. They either require user consent on a case-by-case or one-time basis despite not being runtime permissions or they have no real privacy model. Low-level permissions exist for static analysis of what apps can request at runtime.
Conversation
For example, request install packages allows the user to allow it as an app source and then approve app installations on a case-by-case update. Only thing that can be done without case-by-case consent is updating an app again after the user authorized an install initial/update.
1
2
Another example is that QUERY_ALL_PACKAGES has no actual privacy model at this point. It would mislead users into thinking that apps without it can't query all the user installed apps when they can if they list queries for common intents like the one used for launcher activities.
1
1
3
Or as another example, the low-level permission for starting at boot is completely meaningless. It only controls being able to listen for the boot completed broadcast and register persistent jobs. You can listen for locked boot completed instead or start countless other ways.
1
2
There's a working background restriction toggle which disables all the ways an app can start itself without another app in the same profile starting it, such as FCM via Play services. Could go through every single low-level permissions this way. They should not be user-facing.
1
3
The ONLY low-level permission that would make sense as a user facing one with the current status of them is the INTERNET permission, and it's important to note that many apps allow other apps to access the network through them to an extent, including every single browser app.
1
4
There's more work to do beyond just exposing INTERNET as a user-facing permission with a toggle and compatibility support for existing apps as we do in GrapheneOS with the Network toggle. It is not adopted / enforced in a lot of the app ecosystem. We're working on that ourselves.
1
4
Listing runtime permissions misleads users into thinking they are granted at install time and punishes apps which make them optional and get as much working as possible without them. For example, GrapheneOS Camera only requests Location if you explicitly enable geotagging.
1
5
It only requires Microphone access if you start recording in video mode without disabling Include audio. The only permission it requires to function at all and requests on launch is Camera. Android stopped listing them at install time once they stopped being granted then.
1
3
Play Store continued listing them at install time for a long time. It still hasn't been updated to stop listing them at install time for legacy apps despite the fact that on first launch on modern Android, there's a permission review screen for legacy < API 23 (Android 6) apps.
1
2
Listing the low-level ones is more harmful since it misleads users in 2 different directions: they wrongly think apps can't do what those permission descriptions say without the low-level permissions (like start at boot) or they'll think the app can do it without runtime consent.
API level would make sense to show at install time in an abstracted way, unlike the low-level permissions, since it impacts how the privacy model works. They could also extend the permissions review screen for API < 23 to certain new special access toggles, among other changes.
2
4
Totally agreed! Came across many baseless accusations misrepresenting things based on that list Play used to expose earlier.
Just posted an alternate way to look at it if someone still wants to have an idea over permissions like you mentioned 'Internet' for non GrapheneOS users.
1