Security and permission (2)

Description and enforcement permission

To enforce your own permissions, you must first use one or more <permission> labels to declare them in the androidmanifest. xml file.

For example, if an application wants to control who can start an activity, it can use the following method to declare a permission for this operation:

<Manifestxmlns: Android = "http://schemas.android.com/apk/res/android"
Package = "com. Me. App. MyApp">
<Permissionandroid: 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>

<Protectionlevel> A property is required. It tells the system how to notify the user of the permissions required by the application, or who is allowed to have this permission.

The <permissiongroup> attribute is optional and is only used to help the system display relevant permissions to users. Standard System groups are usually used to set this attribute. Of course, you can also use a custom group (but this is rare ). We recommend that you use existing groups to simplify the display permission UI for users.

Note the label and description attributes supported by the permission. These are string resources that can be displayed to the user. The Android: Label attribute is used to display the permission list. The Android: description attribute is used for a detailed description of a single permission. The label attribute value should be short. Several key words are used to describe the function of permission protection. The description attribute should be a detailed description of the permission. The Convention is to use two sentences, the first sentence to describe the permission function, and the second sentence to warn the user, if the application obtains this permission, it will bring adverse effects.

The following is an example of setting the label and description attributes for applying for the call_phone permission:

<Stringname = "permlab_callphone"> directly
Call phone numbers </string>
<Stringname = "permdesc_callphone"> allows
The application to call
Phone numbers without your intervention. malicious applications may
Cause unexpected cballs on your phone bill. Note that this does not
Allow the application to call emergency numbers. </string>

Use the system's settings application and shell command: ADB shell PM list permissions to view the permissions currently defined in the system. Use the settings application: settings-> applications. Select an application and scroll down to view the permissions used by the application. For developers, the ADB command with the "-s" option can display permissions in a format similar to the user view format:

$ ADB shell PM list Permissions
-S
Allpermissions:

Network Communication: View
Wi-Fi state, create
Bluetooth connections, full
Internet access, view Network State

Your location: access extra location provider commands,
Fine (GPS) location,
Mock location sources
For testing, coarse
(Network-based)
Location

Services that cost you money: send SMS messages,
Directly call phone numbers

...

Mandatory permission in androidmanifest. xml

Restrict high-level permissions for accessing the entire system or application component, which can be set through the androidmanifest. xml file of the application. All of these require that the expected components contain the Android: Permission attribute and the naming permission used to control access.

The activity permission (applied to the <activity> tag) limits who can start the associated activity. Check this permission during execution of the context. startactivity () method and activity. startactivityforresult () method. If the caller does not have the required permission, a securityexception exception is thrown from the call.

The Service permission (applied to the <service> tag) limits who can start or bind the associated service. In context. startservice () method, context. stopservice () method and context. this permission is checked during bindservice () method execution. If the caller does not have the required permission, a securityexception exception is thrown from the call.

The broadcastreceiver permission (applied to the <receiver ER> label) limits who can send broadcast notifications to the associated receiver. After the context. sendbroadcast () method returns, this permission is checked, that is, when the system tries to send the submitted broadcast notification to the set receiver. When a user fails because he has no permission, the user does not throw an exception to the caller, but does not send an intent object. Similarly, the permission granted to the context. registerreceiver () method is used to control who can send broadcasts to the receivers registered in the program. Another method is to provide a permission when calling the context. sendbroadcast () method to restrict the broadcastreceiver object to receive broadcast notifications.

The contentprovider permission (applied to the <provider> tag) limits who can access the data in the contentprovider object. (The content provides an additional set of important and easy-to-use security permissions called URI permissions, which will be introduced later .) Unlike other components, it has two Independent Permission attributes: Android: readpermission, which is used to restrict who can read data from the provider; Android: writepermission is used to limit who can write data to the provider. Note that if the provider is protected by the read and write permissions, only the write permission does not mean that the provider can read data from the provider. When you obtain the provider and perform operations related to the provider for the first time, the system checks the permissions (if you do not have the permissions, A securityexception exception is thrown ). Use contentresolver. when querying data using the query () method, you must have the read permission and use contentresolver. insert () method, contentresolver. update () method, contentresolver. the write permission is required when the delete () method is used to edit data. In all scenarios, if you do not have the required permissions, this call will cause a securityexception to be thrown.

Mandatory permission for sending broadcasts

In addition to the permission to force the intent object to be sent to a broadcastreceiver object, you can also specify the required permissions when sending a broadcast notification. By calling the context. sendbroadcast () method with the permission string, you can require the receiver to have this permission to receive the broadcast notification.

Note that both the receiver and the broadcaster can require permissions. In this case, the permissions of both parties must be checked before the intent object can be sent to the matching target.

Other Mandatory Permissions

You can set more fine-grained permissions when calling the service. This setting is completed by calling the context. checkcallingpermission () method. When the call is made, the expected permission string is passed in. It returns an integer indicating whether the expected permission is accepted by the currently called process. Note that this method can only be used when a call from another process is executed. Services are usually published through the IDL Interface, or other methods are provided to another process.

There are many useful methods to check permissions. If there is a PID of another process, you can use the context. checkpermission (string, Int, INT) method to check the permission for this PID. If you have another application package name, you can directly use packagemanager. checkpermission (string,
String) to check whether the package has been granted the specified permission.

Uri permission

The standard permission system we have introduced so far does not meet the requirements of the content provider. The content provider may have to protect its own read and write permissions, but for some operations, its client also needs to hand over the specified URI to another application for processing. A typical example is attachments in the mail application. Email access should be protected by permissions, because this user's sensitive data. However, if you want to provide the URI of an image attachment to an image browser, the image browser cannot open the Image Attachment because it has no permission.

The solution to this problem is to assign each URI a permission. When an activity is started or a result is returned to an activity, the caller can set intent. flag_grant_read_uri_permission and (or) intent. flag_grant_write_uri_permission permission. In this way, the activity that accepts the intent object is granted the permission to access the data URI specified in the intent object, regardless of whether it has the permission to access the data permission in the content provider corresponding to the intent object.

This mechanism allows the use of a common capability style model, which uses user interaction (opening an attachment, selecting an address book, etc.) to drive the setting of finer-grained permissions. This mechanism can effectively reduce the permissions required by the application, only those action permissions that are directly related to them.

This method of refining permissions to Uris requires the cooperation of the content providers of these Uris. It is strongly recommended that the content providers implement this mechanism and declare the permissions they provide through the Android: granturipermissions attribute or the <grant-Uri-permissiongs> label.

More information can be found in the Context. granturipermission (), context. revokeuripermission (), and context. checkuripermission () methods.