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
That is because
checkSelfPermission()
checks permissions, not permission groups.That is because
requestPermissions()
works with permissions, not permission groups.Yes.
No.
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.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.