How To Integrate The New Permissions In Android 6.0 Marshmallow

How To Integrate The New Permissions In Android 6.0 Marshmallow

Android 6.0 brings a new level of granularity to app permissions. Users will now be allowed to turn individual permissions—camera, calendar, contacts etc.—on and off depending on their preferences.

  1. Granular Permissions For Android Users
  2. Key Components Of Permissions
  3. Permission Groups
  4. Normal Permissions
  5. Permissions Or Android Intents?
  6. Best Practices For Permissions

Granular Permissions For Android Users

For app developers and publishers, the biggest change they will need to integrate and test is how Android will now handle app permissions. If you are unfamiliar with permissions in Android, when an app is downloaded from Google Play, the user can see what that app is allowed to do with the phone. Some apps request permission to access user’s contacts or calendar, Wi-Fi and cellular data, camera access and so forth.

Users of Android Marshmallow will now be allowed to turn individual permissions on and off within an app. Google was rumored to bring this feature to Android 5.0 Lollipop at one point, but developers were concerned that giving users granular access to app permissions would cause massive headaches in how an app performed and increase the need to test any and all viable app combinations.

Android Marshmallow apps will now ask for permissions (through a dialogue box) as they need them. The user can toggle those permissions on and off.

The new permissions capability in Android 6.0 only works with Android API version 23 (Marshmallow). If a user has an Android device running API version 22 (Lollipop) and below, Android’s old permission model will take effect.

This card deck will give app developers what they need to know to handle how permissions will be handled in Android 6.0 Marshmallow to use them in the most effective way possible.

Key Components Of Permissions

Not every permission that an app requests requires the user to say yes or no to it. Some permissions fall into the category of “normal” permissions that will be automatically allowed (and are considered safe and non-invasive) when a user installs an app.

Here is the overview for how permissions will work in Android 6.0:

Declaring Permissions: An app will declare all the permissions it needs in the app’s manifest. This is no different from how previous versions of Android handled permissions when an app was submitted to Google Play.

Groups: Permissions have different levels of groups. Some of those groups, such as normal permissions, do not need user agreement. Other groups are based on functionality.

Limited & Normal Permissions: Apps that have “Protection_Normal” app permissions will have all of those permissions allowed when a user downloads the app. Normal permissions include noting a device’s Wi-Fi state or allowing a notification to vibrate the device.

User Granted Permissions: In Marshmallow, a permission that needs user agreement. Once the user grants the app permission, the app’s callback will notify it that the user has granted the permission.

Permission Groups

Different types of permissions are separated into groups. Once an permission from a group has been granted, other permissions within that group do not need to be agreed to again. For instance, the permission group for the calendar can read or write to the calendar. Those are two different permissions, but the user only needs to agree once.

Apps should always check to see if a particular permission is granted by the user, even if the user has already agreed to it in the past since users now have the ability to revoke non-normal permissions in an app’s settings.

Android 6.0 Marshmallow has nine primary groups of permissions:

  • Calendar: read and/or write to the calendar.
  • Camera: give the app the ability to access the camera on a smartphone or tablet.
  • Location: access fine or coarse location.
  • Microphone: the ability to record audio.
  • Phone: includes phone state, the ability to make calls, read and write to the call log, and voicemail.
  • Sensors: the ability to use various sensors in the device, like the gyroscope.
  • SMS: similar to how the phone is handled including sending and receiving texts, MMS and cell broadcasts.
  • Storage: read and write to a device’s external storage.

Normal Permissions

Normal permissions do not represent a great risk to user privacy or security. App developers do not need to request or check for these permissions and they will be automatically allowed when a user downloads and app.

Most of the normal permissions are fairly innocuous and are necessary for an app to perform some of the most basic tasks on a smartphone.

Some of the most common normal permissions include:

  • Check and change data connections: includes network state, Wi-Fi or WiMax permission, Bluetooth, NFC etc.
  • Flashlight access
  • Internet/browser access
  • Audio levels and settings
  • Fingerprint access
  • Wallpaper access (for placing icons)
  • Alarms and notification status
  • Permission to access the launcher to install or uninstall a shortcut

Apps can request “signature” permissions that are not included as “normal.” For instance, camera access is not a normal permission, but an app like Instagram would not work without camera access, to it can request a signature permission and it will be automatically granted when a user downloads the app.

Permissions Or Android Intents?

One of the most powerful aspects of Android since its inception has been Android Intents. The Intents system let’s one app use the a capability of another app to perform a function. For instance, if you have ever used an Android app and clicked a link, you may have got a dialogue box asking you to “perform function with” and a few app icons. If I am attaching a photo to a text message, I get a dialogue box asking me if I want to complete the action using Google Photos or the phones primary gallery app.

In Android Marshmallow, developers can choose whether they want to ask the user for a permission or just use that same capability in another app (which the user has presumably granted permission access to).

The camera is a good example of how this works in Marshmallow. A developer can either directly access Android’s camera APIs and control the full experience, including building a user interface for the camera portion of the app. If the developer does not want to build their own camera functionality, they can let a different app (or the device’s default camera app) handle the function through an Android Intent.

Advantages and disadvantages for requesting permissions:

  • Full control over the user experience and ability to customize the experience and user interface.
  • User gives permission once and then does not need to be asked again. But if the user revokes the permission, that portion of the app becomes useless.

Advantages and disadvantages of using permissions:

  • Cut down on design work by letting a different app handle the user interaction.
  • The app loses control over the process.
  • If there is no default app for the function, the user is going to be prompted every time they need to perform the action from your app.

Best Practices For Permissions

Now that users can grant or revoke access to permissions, testing the app before it is published requires a bit more work. Developers will need to test all the different permutations of the app with various permissions granted or revoked.

Google has provided a new Android Debug Bridge (ADB) for the purpose of testing different permission parameters. The ADB package manager can help with automated testing of the app with different permissions granted or revoked.

As for when and how developers ask users for permissions, a little of common sense goes a long way. Only ask for the permissions you need for the app to run and do not add extraneous permissions that you think you may need later. If you are not sure if you should add a permission, try adding an Android Intent instead.

Google states in its developer documentation:

Every time you ask for a permission, you force the user to make a decision. If the user turns down the request, that reduces your app’s functionality. You should minimize the number of times you make these requests.

Google also suggests to try and not overwhelm users over and over again by making them constantly choose whether or not to allow a permission. Developers should also explain why the app is requesting a permission, such as when a photo app is requesting location data access.

Google also suggests using the support libraries that have been revised for Android API Level 23. The libraries can help manage permissions without having to perform a lot of manual coding work.