Android Security and Permissions

Custom Permissions Permission

<permission
Android:name= "Com.android.launcher.permission.INSTALL_SHORTCUT"
android:permissiongroup= "Android.permission-group.system_tools"
Android:protectionlevel= "Normal"
Android:label= "@string/permlab_install_shortcut"
android:description= "@string/permdesc_install_shortcut"/>

The meaning of the statement is as follows;

Android:label: The permission name, displayed to the user, is a string data, such as "Custom Permissions" here.

Android:description: A description of the permission that is longer than the label. The value is obtained through the resource file and cannot be written directly to a string value, such as "@string/test" here.

Android:name: Permission name, if other app refers to this permission need to fill in this name.

Android:protectionlevel: A permission level, divided into 4 levels:

0normal: Low-risk permissions, when installed, the system will automatically grant permissions to application.

0dangerous: High-risk permissions, the system will not automatically grant permissions to the app, when used, will give the user prompt.

0signature: Signing permissions, you need to ensure that the signatures of two apps are consistent when other apps refer to the claimed permissions. This allows the system to automatically grant permissions to third-party apps without prompting the user.

0signatureOrSystem: This permission is the app that refers to the permission to have the same signature as the system to grant permissions, generally not recommended to use.

Declaring and Enforcing permissions

To enforce your own permissions, you must first declare them in the Androidmanifest.xml file by using one or more <permission> tags.

For example, an application that wants to control who can initiate one of its activity 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>

The <protectionLevel> attribute is required, which 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 used only to help the system display the relevant permissions to the user. This property is usually set with a standard system group, but it is also possible to use a group of your own definition (but this is rare). We recommend the use of existing groupings, which simplifies the UI for displaying permissions to the user.

Note the label and description properties that are supported by the permission. They are string resources that can be displayed to the user, the Android:label property is used for the display of the permission list, and the Android:description property is used for a detailed description of a single permission. The Label property value should be short, with several key words describing the function that is protected by the permission. The description attribute should be a detailed description of the permission, the Convention is to use two sentences, the first sentence to describe the function of the permission, the second sentence to warn the user if the application obtains this permission will have the adverse effect.

Here is an example of the label and Description property settings that apply for Call_phone permissions:

<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 calls on your phone bill. Note that this does not
Allow the application-to-call emergency numbers.</string>

Using the system's settings application and Shell command: ADB shell pm List permissions to see the permissions currently defined in the system. The Settings app is used by: settings->applications, select an application, scroll down and see the permissions used by this application. For developers, ADB commands 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-testing, coarse (network-based) location

Services, Money:send SMS messages, directly call phone numbers

...

Mandatory permissions in Androidmanifest.xml

Restricting access to high-level permissions for the entire component of a system or application can be set through the application's Androidmanifest.xml file. All of these require that the Android:permission attribute be included on the desired component, and that the named permission is used to control access.

The activity's permissions (applied to <activity> tags) limit who can initiate the associated activity. This permission is checked during the execution of the Context.startactivity () method and the Activity.startactivityforresult () method, if the caller does not have the required permissions, Then a SecurityException exception is thrown from the call.

The service's permissions (applied to <service> tags) limit who can start or bind the associated services. This permission is checked during the execution of the Context.startservice () method, the Context.stopservice () method, and the Context.bindservice () method, if the caller does not have the required permission. Then a SecurityException exception is thrown from the call.

Broadcastreceiver permissions (applied to <receiver> tags) limit who can send broadcast notifications to the associated receivers. This permission is checked when the Context.sendbroadcast () method returns, that is, when the system attempts to send the submitted broadcast notification to the set receiver. It does not throw an exception to the caller when it fails because there is no permission, it simply does not send the intent object. Similarly, the permissions provided to the Context.registerreceiver () method are used to control who can send broadcasts to receivers registered in the program. Alternatively, when calling the Context.sendbroadcast () method, provide a permission to limit the Broadcastreceiver object to receive broadcast notifications.

ContentProvider permissions (applied to <provider> tags) restrict who has access to the data in the ContentProvider object. (The content provides an additional set of important and easy-to-use security permissions called URI permissions, which are described later.) Unlike other components, it has two separate permission attributes: Android:readpermission is used to restrict who can read data from the provider, and Android:writepermission is used to restrict who can write data to the provider. Note that if the provider is protected by read and write permissions, having only write permissions does not mean that the data can be read from the provider. When the provider and execution provider-related operations are first obtained, a permission check is made (a SecurityException exception is thrown if there is no permission). When querying data using the Contentresolver.query () method, a Read permission is required, using the Contentresolver.insert () method, the Contentresolver.update () method, The Contentresolver.delete () method requires write access when editing data. In all scenarios, this call causes a SecurityException exception to be thrown if there is no required permission.

Mandatory permissions when sending broadcasts

In addition to forcing who can send a intent object to a Broadcastreceiver object, you can also specify the requirement permission when sending a broadcast notification. By invoking the Context.sendbroadcast () method with a permission string, you can require that the sink must have this permission to be able to accept this broadcast notification.

It is important to note that both the receiver and the broadcaster are able to request permissions, and when this happens, 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 finer-grained permissions during the call to service. This setting is done by calling the Context.checkcallingpermission () method. When called to pass the desired permission string to this method, it returns an integer indicating whether the desired permission is accepted by the currently invoked process. It is important to note that this method can only be used when executing from another process call. The service is typically published through the IDL interface, or it is provided to another process in other ways.

There are many useful ways to check permissions. If there is a PID for another process, then you can use the context.checkpermission (String, int, int) method to check permissions against this PID. If you have a package name for another application, you can use the Package Manager's Packagemanager.checkpermission (string, String) method to find out whether the package has been granted the specified permission.

URI permissions

The standard permission system we have introduced so far does not meet the needs of the content provider. The content provider may want to protect its own read and write permissions, but for certain operations, its client also needs to hand over the specified URI to another application for processing. A typical example is an attachment in the mail application. The access to the message should be protected by permissions because of this user-sensitive data. However, if you want to provide an image attachment URI to an image browser, then this image browser will not be able to open the image attachment because of no permissions.

The solution to this problem is to assign a permission to each URI, and when an activity is initiated or a result is returned to an activity, the caller is able to set the Intent.flag_grant_read_uri_ Permission and/or intent.flag_grant_write_uri_permission permissions. This gives the activity that accepts the intent object the right to access the data URI specified in the intent object, regardless of whether it has access to the data permissions in the content provider that corresponds to the intent object.

This mechanism allows the use of a common competency-style model that takes advantage of user interaction (opening an attachment, selecting an address book, and so on) to drive a finer-grained set of permissions. This mechanism can effectively reduce the permissions required by the application, only those directly related to their behavior permissions.

This refinement of permissions to URIs requires the coordination of the content providers that hold these URIs. It is strongly recommended that the content provider implement this mechanism and declare the permissions provided by the Android:granturipermissions properties or <grant-uri-permissiongs> tags.

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

Android Security and Permissions