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

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.