This tutorial is about the Android runtime permission model that changed in the Android Marshmallow release:

"Google Play will require that new apps target at least Android 8.0 (API level 26) from August 1, 2018, and that app updates target Android 8.0 from November 1, 2018." - Android Docs

Google’s decision led developers to change development priorities for their applications. Now, a huge number of apps need to be updated and change their permission model. This tutorial guides developers on how to change their current permission model into the new one.

New Runtime Permissions vs. Old Model

Android application permission handling has changed to another dimension with API level 23. In the old model, all permissions were asked to be accepted during installation. But now, after Marshmallow non-normal permissions are asked to be granted during runtime.

Permissions are divided into four protection levels :

Normal

Signature

Dangerous

Special

We will look through normal and dangerous levels. If you are interested, you can jump to the Bonus Section for Special and Signature levels. Here are the differences between normal and dangerous permissions.

Normal Permissions

Normal permissions have nearly no risk to user privacy or to the operation of other applications. For example, permission for connection to the Internet or setting the alarms.

These types of permissions are automatically granted by the system during installation, and the user will not be prompted explicitly to grant the permission. As well users cannot revoke these permissions.

Dangerous Permissions

Dangerous permissions can cause data leaks that involve the user’s private information, change the user’s saved data, or put the operation of other applications at risk. For example, permissions for opening the camera and taking pictures, sending SMS, or recording through the microphone.

To use a dangerous permission, the user should grant the permission vi aa prompt shown at runtime or from system settings. The user can also revoke this type of permissions any time.

The parameter REQUEST_CODEis the identifier of our request action. It will help us to locate our action in the onRequestPermissionsResult function.

In this stage, if the app is not pre-granted permissions, the application should show a prompt to the user. Here in the code, two separate permissions are requested, but only one prompt with the group-generic “make and manage phone calls” text is shown. The reason behind this is that Google has grouped dangerous permissions by in themselves.

In this block, the shouldShowRequestPermissionRationale()method helps us to determine the denial reason. If the user selected the “Don’t ask again” choice, the application should explicitly help the user to understand why the permission is needed; i.e. some graphics, explanation text, or UI changes.

Bonus Section

We need to think of these signature and special permission groups together. Because special permissions are also considered signature permissions by Google.

Signature Permissions

Signature permissions are automatically granted to the application by the system during installation like normal permissions. However, the difference here is that not every application can get these permissions. If the application is signed by the same certificate which signs the permission, then the application can use the permission.

When you define a custom permission in one of your applications, and you set its protection level to “signature” only, the application, which is signed by the same certificate that's been used in permission-defined-application, can grant and use that permission.

Special Permissions

Some of the signature permissions are above the dangerous permissions, which means they can effect and change the user’s whole use of the phone. These permissions are not used by most of the applications. But, in rare cases, you need to use them. Your application can not grant these, but it does ask the user to manually add the permissions to the app via the system settings.

Here is two of the special permissoins:

SYSTEM_ALERT_WINDOW

This permission allows the application to “draw over screen” like Facebook chat heads and Truecaller’s caller card. If your application needs this special permission, you can not use the regular request flow. Here, you should call with the intent to open the system permission management screen so the user can grant permission.

This permission allows the application to “change system settings,” like admin applications and bluetooth manager applications. It is handled in the same way as other special permissions. But, you should use ACTION_MANAGE_WRITE_SETTINGS and Settings.System.canWrite() instead of ACTION_MANAGE_OVERLAY_PERMISSION and Settings.canDrawOverlays().