Android M使用permission_groups请求权限

tri*_*out 19 permissions android android-6.0-marshmallow

版本的Android M预览文档向我们展示了如何检查和请求的权限与新的权限模型.在下面的图表中,它向我们显示了一组权限组及其相关的权限.

当我第一次尝试checkSelfPermission使用permission_group(即Manifest.permission_group.CAMERA)时,我可以预见到PackageManager.PERMISSION_DENIED.

然后尝试requestPermissions相同permission_group,我不会弹出任何类型的对话框.'onRequestPermissionsResult'立即返回-1.

当我尝试相同的序列Manifest.permission.Camera- 事情似乎正常.但对于我正在制作的一个简单的应用程序,我需要录制带有音频的视频,并请求两个单独的权限,CAMERA并且MICROPHONE(又称RECORD_AUDIO)看起来很糟糕的设计.

问题:是checkSelfPermissionrequestPermission应该一起工作Manifest.permission.*Manifest.permission_group.*,但有因为它使我的文件将不会显示要求的错误?或者这是故意的设计?

*注-我知道我可以创建一个requestPermissions(String[], int)与它自己的多个权限字符串数组,但ID仍然有大量的if语句来检查的权限,我需要的组合,对他们要求为一组,当我应该只需要申请permission_group

Com*_*are 24

当我在第一次启动时尝试使用permission_group(即Manifest.permission_group.CAMERA)检查SelfPermission时,可以预见我得到PackageManager.PERMISSION_DENIED.

这是因为checkSelfPermission()检查权限,而不是权限组.

然后尝试为同一permission_group请求权限,我不会弹出任何类型的对话框.'onRequestPermissionsResult'立即返回-1.

这是因为requestPermissions()使用权限,而不是权限组.

checkSelfPermission和requestPermission应该与Manifest.permission一起使用.*

是.

和Manifest.permission_group.*

没有.

或者这是故意的设计?

据推测,是的.至少在checkSelfPermission()它上面,它覆盖了其他预先存在的方法,这些方法可以追溯到API级别1并处理权限,而不是权限组.

当我只需要一个permission_group时

您正在假设Android的未来可能不准确.现在,前M,权限组并不是特别重要,权限是重要的.在M中,权限组的重要性越来越高,因为这是M在向最终用户呈现用户可以控制的内容时所使用的.但是,之后的Android版本可能会为此提供更精细的粒度,无论是个人用户还是企业通过策略,这可能会回到权限.

该API表明谷歌正在为这些行动敞开大门.实际上,权限组的内容是UX的决定,而不是技术决定.