The specific use of the permission authority mechanism in Android _android

With the introduction of the Android permission privilege mechanism, we know that Android uses permissions to limit the ability to install applications by enforcing a rights-based security policy on each device to handle security issues. This article continues to explore topics related to Android permissions, focusing on two aspects of privilege level, ICC (inter-component communication) rights protection.

Permission levels protection level

Each permission permission has a permission level (protection levels), as follows:

Copy Code code as follows:

"Normal"
The default value. A Lower-risk permission that gives requesting applications access to isolated Application-level-features, with minimal RIS K to other applications, the system, or the user. The system automatically grants this type of permission to a requesting application in installation, without asking for th E user ' s explicit approval (though the user always has the option to review this permissions before).

The normal level is some of the less risky permissions, and when we install a new app to the phone, the permissions that are usually folded up are normal.

Copy Code code as follows:

"Dangerous"
A higher-risk permission that would give a requesting application access to private user data or control over the device T Hat can negatively impact the user. Because this type of permission introduces potential risk, the system could not automatically grant it to the requesting app Lication. For example, no dangerous permissions requested by a application may is displayed to the user and require confirmation b Efore proceeding, or some approach may is taken to avoid the user automatically allowing the use of such facilities.

Dangerous are those that are more risky, and are clearly prompted at installation to have these permissions, and require a user's consent to confirm that the app is installed correctly.

Copy Code code as follows:

"Signature"
A permission that's system grants only if the requesting application are signed with the same certificate as the Applicat Ion that declared the permission. If the Certificates match, the system automatically grants the permission without notifying the user or asking for the R ' s explicit approval.

Signature will be used when we customize the custom permission custom, which I will do in another blog post: Android customization permissions, here's a brief summary:

When a user customizes permission in one app (first called Permisson app) and specifies that some components require that custom permission to open, this is a prerequisite, and then the user develops another app (called the permission client), This permission client if you want to access a component that has custom permissions specified in the Permisson app, then these two apps must have the same signature, which is what signature level means.

Copy Code code as follows:

"Signatureorsystem"
A permission that "system grants only to applications" are in the "Android system image" or "are signed with the" Same certificates as those in the system image. Please avoid using this option, as the signature protection level should is sufficient for most needs and works regardless of exactly where applications are installed. The "Signatureorsystem" permission is used for certain special situations where multiple vendors have applications I Nto a system image and need to share specific features explicitly because they are being and built together.

This ditto, but a or,or is to mean in addition to the same signature can also be designated as the same Android IMG can also be accessed, this IMG is actually system-level customization, generally used very little.

ICC (inter-component communication) rights protection

<application> elements and component elements have android:permission attributes, where we call this property the permissions tag for the application and the component respectively. A component within an application can inherit the permission label set by the application element. When a component starts ICC, the associated access controller looks at the set of permission tags for the application that contains the components and components, such as the Access Rights tab of the target component in the above set, allowing the ICC to be established, or it will be rejected. Even if the two components are within the same application.

The diagram describes the process of the logic: whether component A can access Components B and C, depending on the results of the comparison between the Access Rights tab in B and C and the collection of tags within application 1. B and Application 1 have i1 tags, so component A can access component B, instead of the label i2 in Application 1, component A does not have access to component B.