In-depth experience and explanation of various permissions in Android

1. Permission (permission)

Permission is used to describe whether you have the right to do something. In Android, permissions are classified into normal, dangerous, signature, and signature or system ). All predefined permissions in the system belong to different levels based on their roles.
For general and dangerous permissions, we call them low-level permissions. An application is granted. The other two levels of permissions are called Advanced permissions or system permissions. An application can apply for a platform-level authentication. When an application attempts to perform restricted operations without permission, the application will be killed by the system for warning.
System Applications can use any permissions. You can use this permission unconditionally.
Currently, the android system defines many permissions. You can use the SDK documentation to find the permissions required for operations and then apply for permissions as needed.
To execute your own permissions, you must first use one or more <permission> label declarations in your androidmanifest. xml file. For example, if an application wants to control who can start a activities, it can declare a license for doing this, as shown below:

<Manifest xmlns: Android = "http: // schemas. Android. COM/APK/RES/android "package =" com. me. app. myApp "> <permission Android: Name =" com. me. app. myApp. permission. deadly_activity "Android: Label =" @ string/permlab_deadlyactivity "Android: Description =" @ string/permdesc_deadlyactivity"
Android: permissiongroup = "android. permission-group.COST_MONEY" Android: protectionlevel = "dangerous"/> </manifest>

Ii. Permission

The permissions required by the application should be applied in the users-Permission attribute. The applied permissions should be defined by the system or an application. Otherwise, the application is deemed invalid. In addition, applications that use permissions must follow the permission granting conditions. applications that do not use platform authentication cannot apply for advanced permissions.

Therefore, inter-program access permissions are roughly divided into two types:
For the first low-level vertex (the protectlevel attribute of permission is normal or dangerous), the caller APK only needs to declare that <uses-Permission> can have its permission.
(The protectlevel attribute of permission is signature or signatureorsystem). The called APK must have the same signature as the called APK.

During application installation, the permissions requested by the application is approved by the package installer. Package installer checks the signature of the application to determine whether to grant the request permission to the application. The permission is not checked during user use, that is, the permission is either approved during installation so that it can be used according to the design; or the permission is not approved, in this way, the user cannot use the feature at all, and there is no prompt to inform the user of the attempt failure.
For example, to use an API with system-level permissions for advanced permissions, you must grant the APK the system permission. For example, the android API provides the systemclock. setcurrenttimemillis () function to modify the system time. There are two methods:

The first method is simple, but you need to use make to compile the Android system source code:
1. intervene in the Android: shareduserid = "android. uid. System" attribute in the manifest node of androidmanifest. xml of the application.
2. Modify the Android. mk file and intervene in the local_certificate: = platform line.
3. Use the MM command to compile the generated APK. The generated APK has the permission to modify the system time.

2nd methods are troublesome, but it is not necessary to run the virtual machine to the source code and use make to compile:
1. Act on the Android: shareduserid = "android. uid. System" attribute.
2. Compile the APK file using eclipse, but this APK file cannot be used.
3. Use the platform Password Key of the needle system to sign the APK file from the beginning. Signapk platform. x509.pem platform. pk8 input.apk output.apk

3. Custom permission

Permissions defined by the Android system can be found in manifest. permission. Any program can define and enforce its own unique permissions. Therefore, the permissions defined in manifest. permission is not a complete list (custom permissions can be defined ).
A specific permission may be enforced in many aspects of program operations:
When the system calls, it is used to prevent the program from executing other functions.
When an activity is started, it will prevent the application from starting the acitivity of other applications.
When sending and receiving broadcasts, you can control who can receive your broadcasts or who can send broadcasts to you.
When entering and operating a content provider.
When binding or starting a service.

Iv. Component Permissions

You can set advanced permissions through the androidmanifest. xml file to restrict access to all components of the system or use applications. All these requests are included in the Android: Permission attribute of the required component. You can control access to this component by naming this permission.
1.The activity permission (using the <activity> label) restricts the ability to start components or applications associated with the activity permission. Check during context. startactivity () and activity. startactivityforresult;
2The. Service permission (application <service> tag) restricts the start, bind, or start and bind of components or applications of the associated service. This permission must be checked during context. startservice (), context. stopservice (), and context. bindservice;
3The. broadcastreceiver permission (application <receiver ER> label) limits the components or applications that can send broadcasts to the associated recipients. After context. sendbroadcast () returns, this permission will be checked and the system will try to deliver the broadcast to the recipient. Therefore, a permission failure will result in an exception thrown back to the caller; it cannot be delivered to the destination. In the same way, context. registerreceiver () can support a permission to control components or applications that can deliver broadcasts to registered program recipients. Otherwise, when context. sendbroadcast () is called ()
To restrict the permission of a broadcast receiver object that can be allowed to receive broadcasts (see below ).
4. Contentprovider permission (use the <provider> tag) to restrict components or applications that can access data in contentprovider.
If the caller does not have the request permission, a security exception (securityexception) is thrown for the call ). In all these cases, a securityexception thrown from a caller does not store the request permission results.

5. Support permissions for sending broadcasts

When sending a broadcast, you can always specify a request permission. In addition to permission execution, you can grant intent permission to a registered broadcastreceiver. By calling context. sendbroadcast () and some permission strings, you must have that permission to request a receiver application to receive your broadcast. Note that both the receiver and the broadcaster can request a permission. When this happens, for intent, both permission checks must pass in order to deliver to a common destination.

6. Support for other Permissions

You can set any fine-grained permissions (more refined permissions) when calling the service ). This is done through the context. checkcallingpermission () method. Use a desired permission string for the call. Then, when the permission is approved, an integer can be returned to the caller (an integer will be returned if the permission is not approved ). It should be noted that this situation can only happen in calls from another process. It is usually an IDL Interface published by a service or provided to other processes in other ways.
Android provides many other methods for checking permissions. If you have another PID of the process, you can use the context method context. checkpermission (string, Int, INT) to check the permission for that PID. If you have another application package name, you can use packagemanager's method packagemanager. checkpermission (string, string) to determine whether the package has the corresponding permissions.

VII. Uri permission

The standard permission system we have discussed so far is not enough for the content provider. A content provider may want to protect its read and write permissions, and its direct clients also need to pass specific URIs to other applications, so that other applications can operate on the URI. A typical example is that the email program processes emails with attachments. Permission must be used to protect incoming emails because these are sensitive user data. However, if a URI pointing to an Image Attachment needs to be passed to the image browser, the image browser will not have the right to access the attachment, because it cannot have the access permission for all emails.
The solution to this problem is per-Uri permission: when an activity is started or a result is returned to the activity, the caller can set intent. flag_grant_read_uri_permission and/or intent. flag_grant_write_uri_permission. this allows the activity that receives the intent to obtain the permission to enter the URI specified by the intent, regardless of whether it has the permission to access the content provider corresponding to the intent.

This mechanism allows a common capability-style model, which is driven by user interaction (such as opening an attachment and selecting a contact from the list, obtain fine-grained permissions (more fine-grained permissions ). This is an important way to reduce unnecessary permissions. This method mainly targets the permissions directly related to program behavior.
The acquisition of these Uris permission requires the combination of content providers (including those URIs. We strongly recommend that you provide this capability in the content provider and declare it using the Android: granturipermissions or <grant-Uri-permissions> tag.

8. Summary

1. can I access data or functions with normal or dangerous permissions without declaring <uses-Permission>?

As long as the signature is the same, even if you do not explicitly declare <ues-Permission>, you can also access data or functions that have been set with the normal or dangerous permission.

2. If you need system-level permissions to use the system API (that is, using the system-level signature), how can you use other APK functions of other signature permission settings (that is, using the signature-level signature) at the same time?
Users with system-level permissions can access other functions set by the general signature permission statement.
Therefore, set it to have system-level permissions.