Detailed explanation of Android custom permission use summary

1. How to declare custom permissions

Use the Permission tag in the Manifest file to define your own permissions:

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
 package="com.bright.permission">

 <permission
 android:name="com.bright.permission.TEST"
 android:description=""
 android:permissionGroup="com.bright.permission-group.TEST"
 android:protectionLevel="signature" />
 ...
</manifest>

Explain each attribute:

name, which is the name of the permission. description, which is the introduction of permissions. permissionGroup, which specifies the group for this permission. protectionLevel, which specifies the protection level.

Android divides permissions into several protection levels, such as normal, dangerous, signature, etc. normal is a normal permission, which does not bring risks to the privacy of users or devices; dangerous is a dangerous permission, and this level of permission usually brings risks to the privacy of users' data or devices; signature means that only applications with the same signature can use this permission. For more information, please refer to protectionLevel.

2. Use scenarios

Custom permissions 1 are generally used for exposed components to improve security. Android allows one application (client) to invoke the components of another application (server). Then the application as the server must expose the corresponding components before the client application can access them. Of course, at the time of exposure, permission is not necessary. If the exposed component does not have permission, then any other application can call the component; If the component has applied for permission, only the application with the permission can call the component.

<activity
 android:name=".TestA_Activity"
 android:exported="true"
 ... />

The exported attribute represents whether it is exposed or not. This example does not require the caller to apply for permission, that is, any application can call only a component. If every application can call our components, it is obviously unsafe. We hope that only applications that use our permissions can call our exposed components. We can add permission attributes to activity.

<activity
 android:name=".TestA_Activity"
 android:exported="true"
 ... />

Intent intent = new Intent();
intent.setClassName("com.bright.permission", "com.bright.permission.TestA_Activity");
startActivity(intent);

In addition to the above, you can start implicitly through intent-filter:

<activity
 android:name=".TestA_Activity"
 android:exported="true"
 ... >
 <intent-filter>
  <action android:name="com.bright.permission.action.TEST"/>
  <category android:name="android.intent.category.DEFAULT"/>
 </intent-filter>
</activity>

Intent intent = new Intent();
intent.setAction("com.bright.permission.action.TEST");
startActivity(intent);

3. Custom Permission Points for Attention

3.1. Both applications declare the same permissions

Android does not allow two different applications to define the right to have the same name (unless the two applications have the same signature), so special care should be taken when naming. Software with the same custom permissions must use the same signature, otherwise the last 1 programs cannot be installed.

3.2. Relationship with application installation sequence.

Scenario: Permission PermissionA is declared in App A, and permission PermissionA is used in App B.

Scenario 1: The protection level of PermissionA is normal or dangerous

App B is installed first, App A is installed later, and App B does not get permission to PermissionA at this time.

That is, in this case, the permission must be declared before being used. Even though App A and App B are the same signature.

Case 2: The protection level of PermissionA is signature or signatureOrSystem

App B is installed first, and App A is installed later. If App A and App B have the same signature, App B can obtain the permission of PermissionA. If App A and App B have different signatures, App B cannot obtain PermissionA permissions.

That is, for app with the same signature, regardless of the installation sequence, as long as the permission is declared, the app requesting the permission will obtain the permission.

This also shows that for app, a system with the same signature, the installation process does not consider permission dependencies. When installing the system app, install it in a certain order (such as name sorting, directory location sorting, etc.). When all app are installed, all app with permissions will get permissions.

3.3. Access to permissions and version compatibility

Android 6.0 introduces dynamic permissions, which everyone knows. The security level of the user-defined permissions mentioned above, android: protectionLevel, will affect the use of permissions on Android 6.0 + systems

android: protectionLevel= "normal", dynamic application is not required android: protectionLevel= "dangerous", dynamic application is required