4 ms·

The first thing I do when I start a new Android app project is copy and paste this list-of-all-permissions into the project. This way I don't have to deal with

by desdiv 10y ago

The first thing I do when I start a new Android app project is copy and paste this list-of-all-permissions into the project. This way I don't have to deal with any of the permissions related stuff until I have a working MVP. Once you have a MVP it's pretty easy to pin down the exact list of all the permissions you actually need in one go. On a related note, there's some research[0] into parsing the Android OS source code and coming up with a mapping of "API call => required permission", and by apply this mapping to the source code of your own app the list of required permissions can be generated automatically. What do you guys think of this approach? [0] http://pscout.csl.toronto.edu/ http://pscout.csl.toronto.edu/

BHSPitMonkey 10y ago
Seems like Android Studio should do exactly that kind of static analysis and warn you if your manifest specifies too many or too few permissions. There have been a few cases of companies releasing apps with catch-all permission requests like you recommend, and then facing a minor PR crisis as reports of the app's suspiciousness go viral. This should be less relevant for apps using post-marshmallow-style permissions which don't need to be granted on install.
- barrkel 10y ago
  Static analysis will require too many permissions because of limitations on the tractability of the analysis (the Halting problem). Instrumenting is more reliable for a minimal set but isn't necessarily complete.
- ungzd 10y ago
  Another reason to add Effect system to future versions of Java.
- BoorishBears 10y ago
  It does warn you for some permissions.
- deleted 10y ago
  [deleted]
justinpombrio 10y ago
> coming up with a mapping of "API call => required permission" Surely that must be part of the documentation of each API call, right? Like, "You must enable android.permission.X or this call will fail"? If it is, why not just scrape the documentation, and if it's not, how does anyone develop for Android? Disclaimer: I only read the abstract.
- yincrash 10y ago
  It's rarely on a per method call basis. In the documentation, it's usually on a package or class basis such as https://developer.android.com/reference/android/bluetooth/package-summary.html https://developer.android.com/reference/android/bluetooth/pa...
- BoorishBears 10y ago
  The linter will give you warnings on some permissions. But some of the permissions listed can't even be used without system permission, meaning your app has to be signed with the same keys the OS was (iirc more recently I've seen a device that didn't need this) and installed in a special system directory. Permissions like getting the users local MAC address...
fattire 10y ago
I don't get the logic of doing this. For one thing, with the new runtime permissions model, introduced in Android 6, you need to request the permission from the user at runtime rather than in advance (in the play store when the app is installed). https://source.android.com/devices/tech/config/runtime_perms.html https://source.android.com/devices/tech/config/runtime_perms... So starting with Android 6, the user can say "no way" to granting a permission when asked, or at any time after installation (via the app settings menu), and the app has to gracefully notice and/or handle the lack of permission without crashing or otherwise screwing up. This means the app must be designed where the permissions-related stuff can be called asynchronously. I wrote a bit about this in my question here: https://stackoverflow.com/questions/32134299/can-you-request-permissions-synchronously-in-android-marshmallow-api-23s-runt https://stackoverflow.com/questions/32134299/can-you-request... If just you start writing the app with every permission granted you're potentially going to have a huge headache when you go back to pin down the permissions you'll actually need-- now you need to go back and revise the logic so it can handle possible denials. Probably wiser to do that as you go, no? And that's just the base functionality-- there's a UI question too that would benefit some advance-thinking. Do you want to hit the user with a huge list of permissions the first time they launch the app? Or maybe only in groups when they do key operations. Or perhaps individually. This is a question that may be informed by an early understanding of what permissions will be needed, so you know when to ask and what to do if denied.

by desdiv 10y ago

BHSPitMonkey 10y ago

Seems like Android Studio should do exactly that kind of static analysis and warn you if your manifest specifies too many or too few permissions. There have been a few cases of companies releasing apps with catch-all permission requests like you recommend, and then facing a minor PR crisis as reports of the app's suspiciousness go viral. This should be less relevant for apps using post-marshmallow-style permissions which don't need to be granted on install.

barrkel 10y ago
Static analysis will require too many permissions because of limitations on the tractability of the analysis (the Halting problem). Instrumenting is more reliable for a minimal set but isn't necessarily complete.
ungzd 10y ago
Another reason to add Effect system to future versions of Java.
BoorishBears 10y ago
It does warn you for some permissions.
deleted 10y ago
[deleted]

justinpombrio 10y ago

> coming up with a mapping of "API call => required permission" Surely that must be part of the documentation of each API call, right? Like, "You must enable android.permission.X or this call will fail"? If it is, why not just scrape the documentation, and if it's not, how does anyone develop for Android? Disclaimer: I only read the abstract.

yincrash 10y ago
It's rarely on a per method call basis. In the documentation, it's usually on a package or class basis such as https://developer.android.com/reference/android/bluetooth/package-summary.html https://developer.android.com/reference/android/bluetooth/pa...
BoorishBears 10y ago
The linter will give you warnings on some permissions. But some of the permissions listed can't even be used without system permission, meaning your app has to be signed with the same keys the OS was (iirc more recently I've seen a device that didn't need this) and installed in a special system directory. Permissions like getting the users local MAC address...

fattire 10y ago

I don't get the logic of doing this. For one thing, with the new runtime permissions model, introduced in Android 6, you need to request the permission from the user at runtime rather than in advance (in the play store when the app is installed). https://source.android.com/devices/tech/config/runtime_perms.html https://source.android.com/devices/tech/config/runtime_perms... So starting with Android 6, the user can say "no way" to granting a permission when asked, or at any time after installation (via the app settings menu), and the app has to gracefully notice and/or handle the lack of permission without crashing or otherwise screwing up. This means the app must be designed where the permissions-related stuff can be called asynchronously. I wrote a bit about this in my question here: https://stackoverflow.com/questions/32134299/can-you-request-permissions-synchronously-in-android-marshmallow-api-23s-runt https://stackoverflow.com/questions/32134299/can-you-request... If just you start writing the app with every permission granted you're potentially going to have a huge headache when you go back to pin down the permissions you'll actually need-- now you need to go back and revise the logic so it can handle possible denials. Probably wiser to do that as you go, no? And that's just the base functionality-- there's a UI question too that would benefit some advance-thinking. Do you want to hit the user with a huge list of permissions the first time they launch the app? Or maybe only in groups when they do key operations. Or perhaps individually. This is a question that may be informed by an early understanding of what permissions will be needed, so you know when to ask and what to do if denied.