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