Android 6 Essentials

When using Android platform as an app, you have restrictions preventing access to some hardware, system APIs, private user data, and application data.

Permission is needed in order to allow access to a specific API, data, or hardware; it was asked upon the installation of your app up until Android Marshmallow. Most permissions are used to restrict access. When a permission is granted, you then have access to that specific restricted area. A feature can be protected by one permission at most.

The uses-permission element takes a name attribute, android:name, which is the name of the permission your application requires:

<uses-permission android:name="string" android:maxSdkVersion="integer" />

Did you know that the android:maxSdkVersion attribute, added in API level 19, is used to notify the version of the API from which this permission should not be granted? This is useful if a permission is no longer needed on higher versions of the API. For example, take a look at the following:

<uses-permission
  android:name="android.permission.READ_EXTERNAL_STORAGE"
  android:maxSdkVersion="18" />

In API 19, your app doesn't need to ask for this permission—it's granted to you.

Your application can also protect its own components, such as activities, services, broadcast receivers, and content providers with permissions.

It can employ any of the permissions defined by Android and declared by other applications, or it can define its own.

For more information on permissions, you can read http://developer.android.com/reference/android/Manifest.permission.html.

Permissions are divided into groups. According to Google, we can say that a permission group puts together related permissions in a single name/tag. You can group permissions together using the permissionGroup attribute inside the <permission> element.

Permissions grouped in the same permission group are shown as one group when approving permissions or when checking an app for its permissions.

The permission group is what you see when installing an application from the Play Store; for example, take a look at the following screenshot:

Let's take a look at the structure of the permission-group tag:

<permission-group android:description="string resource"
                  android:icon="drawable resource"
                  android:label="string resource"
                  android:name="string" />

The elements of the preceding structure can be explained as follows:

The following table shows you the various categories of permissions that are there in a permissions group:

Some permissions are implied by feature requirements; we will cover this next.

When declaring a feature in the manifest, we must also request the permissions that we need.

Let's say, for example, that we want to have a feature that sets pictures for our contacts. If we want to take a picture via the Camera API, then we must request a Camera permission.

The <users-feature> tag makes sure we declare that we need devices that support the required feature for our application to work and use that feature. If this feature is not a required feature and our app can work without it but with fewer features, we can use android:required="false", keeping it in mind that this feature is optional.

The <uses-feature> declarations always take precedence over features implied by permissions. The complete list of permission categories that imply feature requirements can be found at http://developer.android.com/guide/topics/manifest/uses-feature-element.html#permissions.

You can look at the permissions for each app using the settings app or the adb shell command.

To use the settings app, go to Settings | Apps. Pick an app and scroll down to see the permissions that the app uses You can see the Lollipop version in the following screenshot:

In Android Marshmallow, the UI is different.

The second option is to use the adb shell commands with the aapt command:

Using an adb command, you can print all known permissions on the device. The package manager (pm) command inside the adb command looks something like the following:

$ adb shell pm list permissions [options] <GROUP>

List permissions get the [options] and <GROUP> arguments (both optional).

Here, options can be as follows:

With the Android Marshmallow version, a new application permissions model has been introduced.

Let's review it a bit more thoroughly:

When working with permissions, we divide them into groups. This division is done for fast user interaction when reviewing and approving permissions. Granting is done only once per permission group. If you add a new permission or request a new permission from the same permission group and the user has already approved that group, the system will grant you the added permission without bothering the user about the approval.

For more information on this, visit https://developer.android.com/reference/android/content/pm/PermissionInfo.html#constants.

When the user installs an app, the app is granted only those permissions that are listed in the manifest that belongs to the PROTECTION_NORMAL group.

Requesting permissions from the PROTECTION_SIGNATURE group will be granted only if the application is signed with the same certificate as the app with the declared permission.

System components automatically receive all the permissions listed in their manifests.

Android Marshmallow showcased a new permissions model where users were able to directly manage app permissions at application runtime. Google has altered the old permissions model, mostly to enable easier and frictionless installations and auto-updates for users as well as for app developers. This allows users to install the app without the need to preapprove each permission the application needs. The user can install the app without going through the phase of checking each permission and declining the installation due to a single permission.

Users can grant or revoke permissions for installed apps, leaving the tweaking and the freedom of choice in the users' hands.

Most of the applications will need to address these issues when updating the target API to 23.

In the Android Marshmallow permissions model, your app must ask the user for individual permissions at runtime. There is limited compatibility support for legacy apps, and you should test your app and also test a version to make sure it's supported.

You can use the following test guide and conduct app testing with the new behavior:

The adb command shell can be quite helpful to check for permissions:

When we want to adjust our application to the new model, we need to make sure that we organize our steps and leave no permission stranded:

The following sample code checks whether the app has permission to read the user's contacts. It requests the permission if required, and the result callback returns to onRequestPermissionsResult:

if (checkSelfPermission(Manifest.permission.READ_CONTACTS) != PackageManager.PERMISSION_GRANTED) {
  requestPermissions(new String[]{Manifest.permission.READ_CONTACTS}, SAMPLE_MATRIXY_READ_CONTACTS);
}
//Now this is our callback
@Override
public void onRequestPermissionsResult(int requestCode, String permissions[], int[] grantResults) {
  switch (requestCode) {
  case SAMPLE_MATRIXY_READ_CONTACTS:
    if (grantResults[0] == PackageManager.PERMISSION_GRANTED) {
      // permission granted - we can continue the feature flow.
    } else {
      // permission denied! - we should disable the functionality that depends on this permission.
    }
  }
}

Just to make sure we all know the constants used, here's the explanation:

If the user denies your permission request, your app should take the appropriate action, such as notifying the user why this permission is required or explaining that the feature can't work without it.

The new permissions model has brought to life a smoother experience for users and a bit more code-handling for developers. It makes it easier to install and update apps and feel comfortable with what the apps are doing.

The Android system flags permissions according to their protection levels. The levels are describes at http://developer.android.com/reference/android/content/pm/PermissionInfo.html.

The level that is relevant to our discussion is PROTECTION_NORMAL, in which permissions are considered to have little or no risk when applications have them.

Let's say you want to build a flashlight app; allowing your app to turn on the flash is not considered a huge risk to privacy or security, and this is why flashlight permission is flagged PROTECTION_NORMAL.

When you declare normal permissions in the manifest, the system grants these permissions automatically at the time of installation. There is no prompt to grant permissions for a normal permissions group, and these permissions can't be revoked by users.

This means that you can be sure that normal permissions are granted at the time of installation.

Currently, the permissions classified as PROTECTION_NORMAL are as follows: