19

The Android M Preview docs shows us how to check and request permissions with the new permissions model. In the chart below that it shows us a group of Permission Groups and their associated Permissions.

When I try to to checkSelfPermission with a permission_group (ie Manifest.permission_group.CAMERA) on first start, predictably I get PackageManager.PERMISSION_DENIED.

Then try to requestPermissions for that same permission_group and i don't get any type of dialog to pop up. 'onRequestPermissionsResult' returns immediately with -1.

When i try the same sequence with Manifest.permission.Camera - things seem to work as normal. But for a simple app that I'm making, I need to record video with audio, and requesting the two separate permissions, CAMERA and MICROPHONE (aka RECORD_AUDIO) seems like poor design.

The question: Is checkSelfPermission and requestPermission supposed to work with Manifest.permission.* and Manifest.permission_group.* but there's a bug that I should file since it won't show request? Or was this intentional design?

*Note - I understand that I can create a requestPermissions(String[], int) string array with multiple permissions in it myself, but id still have plenty of if statements to check the combinations of permissions i need and to request them as a group, when i should only need to request a permission_group

trippedout
  • 1,561
  • 13
  • 20

1 Answers1

24

When I try to to checkSelfPermission with a permission_group (ie Manifest.permission_group.CAMERA) on first start, predictably I get PackageManager.PERMISSION_DENIED.

That is because checkSelfPermission() checks permissions, not permission groups.

Then try to requestPermissions for that same permission_group and i don't get any type of dialog to pop up. 'onRequestPermissionsResult' returns immediately with -1.

That is because requestPermissions() works with permissions, not permission groups.

Is checkSelfPermission and requestPermission supposed to work with Manifest.permission.*

Yes.

and Manifest.permission_group.*

No.

Or was this intentional design?

Presumably, yes. At least on the checkSelfPermission(), it layers atop other pre-existing methods that date back to API Level 1 and work on permissions, not permission groups.

when i should only need to request a permission_group

You are making assumptions about the future of Android that may not be accurate. Right now, pre-M, permission groups are not especially important, and permissions are what matter. In M, permission groups climb in importance, as that is what M uses in its presentation to end users regarding what the user can control. However, versions of Android after that might offer finer granularity on this, whether to individual users or to enterprises via policies, and that would likely go back to permissions.

The API suggests that Google is leaving the door open for those sorts of moves. In effect, the permission group stuff is a UX decision, more so than a technical one.

CommonsWare
  • 986,068
  • 189
  • 2,389
  • 2,491
  • was unaware about the checkSelf layering on top of older api methods, thats good to know. i might just try and make a helper utility that allows people to pass in permission_groups and see if it makes sense to me, and potentially others :) thanks for the response cw – trippedout Jun 09 '15 at 15:03
  • but then, what is the known usage of `Manifest.permission_group.class`? – Hendra Anggrian Oct 11 '16 at 10:01
  • @HendraAnggrian: For example, you could use it with [`getPermissionGroupInfo()` on `PackageManager`](https://developer.android.com/reference/android/content/pm/PackageManager.html#getPermissionGroupInfo(java.lang.String,%20int)). – CommonsWare Oct 11 '16 at 12:18
  • 1
    This is quite a worrisome development (or lack of?) Especially as non-hello-world apps now often needed access to GPS (fine-location), SMS, Camera, external SD card, and make/receive phone calls (e.g. 2FA). Why should a developer have to add extensive permission checking code for, let's say 13 different permissions, when 4 would suffice? – not2qubit Jan 18 '17 at 10:23