Android 6.0's Runtime Permissions System
The Classic Permission UX
- You request permissions in the manifest
- At install time, the user is presented with the list of permission groups for those permissions
-
The user can then...
- ...accept the permissions and install the app
- ...or reject the permissions and not install the app
Users' Permission Angst
- All or nothing (IOW, no means to accept some and reject others)
- No means to revoke granted permissions, except by uninstalling the app
- Net: privacy and security concerns
Developers' Permission Angst
- Have to be requested in the manifest (IOW, no means ask for permission only based on user input)
- No concept of optional permissions
- Net: have to request everything up front, resulting in scary list
Runtime Permissions
Legacy Apps
(targetSdkVersion
< 23)
- No code changes
- User can revoke
dangerous
permissions at runtime
- Affected APIs return bogus results
- Behavior akin to "app ops" from Android 4.3/4.4
Runtime Permissions
Modern Apps
(targetSdkVersion
>= 23)
- Same
uses-permission
elements
-
Must request
dangerous
permissions
- Modal dialog-style UI
- User can accept, deny, or deny forever
Runtime Permission Mechanics
checkSelfPermission()
- Given name of permission, tells you if you have it
Context
and ContextCompat
Runtime Permission Mechanics
requestPermissions()
Activity
and ActivityCompat
- Given array of permission names, prompts user to accept/deny them
- One "pane" to dialog per permission group
- Get result in
onRequestPermissionsResult()
Runtime Permission Mechanics
shouldShowRequestPermissionRationale()
Activity
and ActivityCompat
- Given permission name, returns
true
if you asked for the permission previously, the user denied it, but the user has not blocked further requests
- Use: educate user about upcoming permission request
Android 6.0-Only Permissions
<uses-permission-sdk23>
- Use this instead of
uses-permission
for permissions you do not want to ask for prior to Android 6.0
- Use case: permissions you avoided originally (too scary!) that are OK for runtime opt-in
Other Key Considerations
- Must request permissions from an activity (use
Theme.Translucent.NoTitleBar
activity if needed)
- Android terminates your process when user revokes a permission in Settings, but not when user grants a permission in Settings
- If user clears app's data, granted permissions cleared as well
Double-Opt-In Permissions
WRITE_SETTINGS
SYSTEM_ALERT_WINDOW