Android app permissions overview

1. Overview

The purpose of the permission is to protect the privacy of Android users. Android applications must request sensitive user access (such as contacts and sms), as well as certain system features (such as camera and internet). Depending on the feature, the system may either provide automatic permissions or may prompt the user to approve the request.

A key design point of Android security is that, by default, no application has the right to perform any activity that could adversely affect other applications, operating systems, or users. This includes reading or writing user data (contacts and emails), reading or writing files of other applications, making internet connections, keeping the phone active, etc.

Through this article, I want to provide an overview of how Android permissions work, including: how to make permissions displayed to users, the differences between permission requests of install_time and runtime, permissions enforced. how? permissions types and their groups.

2. Permission approval (permission approval)

The application must publish the permissions that it requires with the <uses-permission> tag in the manifest file. For example, an application that needs to send an SMS message will have this line in Manifest

If our application only has a list of normal permissions in its manifest file (that is, permissions that do not pose a lot of risk to user privacy or device activity), the system automatically grants permissions. That for your application

If the application has dangerous permissions in the manifest (rights that affect user privacy or affect the normal operation of the device), such as the SEND_SMS permission above, the user must explicitly agree to grant those rights.

Request a reminder for dangerous permissions

The way that Android requires users to grant dangerous permissions depends on the Android version running on the device and the system version target on our application.

Runtime requests (Android 6.0 and higher)

If the device is running Android 6.0 (API level 23) or higher and the application’s taretSdkVersion is 23 or higher, users are not notified of any application permissions when installing. Our application must require users to grant dangerous permissions at runtime. When our application requests permission, the user will see a system dialog showing which permission group the application is trying to access. Dialog includes 2 buttons, Deny and Allow button.

If the user does not agree, the next time our application will appear the dialog and continue to request. However, if the user ticks the never ask again checkbox, the next time the system will not show the dialog to request permission again.

If the user gives us the permissions that we have requested but later they can optionally turn on or off each permission in the system settings. We must always check and request permission at runtime to prevent errors (SecurityException)

Request install-time (Android 5.1 and smaller)

With these devices, the system automatically asks the user to grant all dangerous permissions to your application when installing.

If the user accepts, all required application permissions are granted. If the user refuses, the system will cancel the application installation.

3. Permission for hardware features

Access to some hardware features (such as Buletooth or Camera) requires application permission. However, not all Android devices actually have these hardware features. So if your application requires camera permissions, you also declare it in the manifest to declare whether it is an important feature or not.

If you declare additional android: required = “false” attribute, Google Play allows your application to be installed on devices that do not have this feature. So you should check that at runtime, if the device has any features by calling PackageManager.hasSystemFeature (), the application will gently disable that feature if it is not available.

If we don’t provide the <uses-feature> tag, when Google Play sees that the application requests a permission, it assumes the application requires this feature. So it filters out apps that don’t have this feature, just like you remove the android: required = “true” attribute.

4. Execute Permission

Permission does not just request system functionality. Services provided by the application can enforce a custom permission to restrict who uses it.

Activity permission

Permission is applied by using the android: allow attribute in the <activity> tag in manifest to restrict who can start the Activity. Permission is checked in Context.startActivity () and Activity.startActivityForResult (). If there is an error then throws a SecurityException.

Service Permission

Used by using the android: permission attribute in the <service> tag in manifest to restrict the user from starting a bind to the Service. Permissions are checked in Context.startService (), Context.stopService () and Context.bindService (). If the call doesn’t require permission, the SecurityException exception will be thrown.

Broadcast Permission

Similarly, the <receiver> tag will declare the android: permission attribute who can send broadcasts to the relevant BroadcastReceiver. Permission has been checked after Context.sendBroadcast return

ContentProvider Permission

The provider tag is similar to the above components and also has the android: permission attribute to restrict access. But there is one more difference: there are two separate licensing properties that you can set: android: readPermission restricts who can read from the provider and android: writePermission restricts who can write for it. .

Permission URI

Standard permissions are often not enough for ContentProvider, a ContentProvider may want to protect itself with read and write permissions, while clients also need to exchange specific URIs for other applications to function.

An example is an email application with files, email access should be protected by permissions. However, if a URI for image attachments is provided to the image viewer, then this image viewer also has no reason to access all emails.

To solve this problem we can use URI-Permission. When starting an Activity and returning a result in another Activity, the call can set Intent.FLAG_GRANT_READ_URI_PERMISSION and / or Intent.FLAG_GRANT_WRITE_URI_PERMISSION.

Other Permission

Detailed permissions can be enforced at any call to the Service. This is done by the Context.checkCallingPermission () method. There are also some rights that have not been mentioned here, you can refer to more.

5. Adjust permissions automatically

Over time, new restrictions can be added to the platform so that in order to use certain APIs, your application must request permissions that it previously did not need. Because current applications assume access to those APIs is free. Android can apply new license permissions to the app’s manifest to avoid app crashes on the new platform version. Android determines whether an application may need permission based on the value provided to the targetSdkVersion attribute.

6. Protection level

Permisson is divided into several levels of protection. The level of protection affecting runtime permissions or not.

There are three levels of protection that affect third-party applications: normal, signature and dangerous permission.

7. Special permission

There are some permissions that do not work as normal and dangerous. SYSTEM_ALERT_WINDOW and WRITE_SETTING are particularly sensitive, so most applications should not use them. If an application needs one of these permissions, it must declare the permissions in the manifest and send an intent that requests the user authorization.

8. Group permission

Permission is organized into groups related to device capabilities or features. In this system, permission requests are handled at the group level and a single group of permissions corresponds to a number of permission declarations in the manifest. For example, SMS group includes READ_SMS and RECEIVE_SMS declarations. Permission grouping in this way allows users to make more meaningful and informed choices without being overwhelmed by complicated and technical licensing requirements.

9. View application permissions

We can view all the rights currently defined in the system using the Setting app and the command

Select Setting -> Apps. Select an app and scroll down to see the permissions it uses. For developer mode, the adb ‘-s’ option displays permissions in a similar way to how users see them:

You can also use the adb -g option to automatically grant all rights when installing the application on an emulator or test device.

10. Summary

Through this article, I introduced an overview of Android app permission. Certainly there are many limitations and shortcomings. Thank you for watching.

To make this article I have consulted the google doc