[Android Development] Permissions classification: Normal permissions and Dangerous permissions

Https://developer.android.com/guide/topics/security/permissions.html#normal-dangerous

System Permissions This content

1. Security architecture
2. Application signing
3. User ID and file access
4. Use permissions
5. Normal permissions and Dangerous permissions
   1. Permission groups
6. Defining and Enforcing permissions
   1. Custom Permission Suggestions
   2. ... In the Androidmanifest.xml
   3. ... When sending a broadcast
   4. Other rights enforcement
7. URI Permissions

Key classes

1. Manifest.permission
2. Manifest.permission_group

See Also

1. Using System permissions

Design Patterns

Permissions

Video

Google I/O 2015-android M permissions: Developer Best Practices

Android is a privilege-delimited operating system in which each app has its own unique system identity (Linux User ID and group ID). The parts of the system are also separated into different identities. Linux isolates different applications and applications from the system.

Other more detailed security features are provided through the permissions mechanism, which restricts the specific actions that a particular process can perform, and temporarily accesses a specific segment of data based on the URI permission authorization.

This document describes how app developers can use the security features provided by Android. The General Android Security Overview is available in the Android Open source project.

Security architecture

The central design point of the Android security architecture is that no app has permission to perform any action that adversely affects other apps, operating systems, or users by default. This includes reading or writing the user's private data (such as Contacts or e-mail messages), reading or writing files to other applications, performing network access, keeping the device awake, and so on.

Because each Android app runs in the process sandbox, the app must explicitly share resources and data. Their approach is to declare what permissions are required to obtain additional functionality not provided by the basic sandbox. Apps statically declare the permissions they need, and then the Android system prompts the user for consent.

The application sandbox does not rely on the technology used to develop the application. In particular, Dalvik VMs are not security boundaries, and any app can run native code (see Android NDK). Various applications-java, native and mixed-in the same way in the sandbox, each other with the same degree of security protection.

Application signing

All APK ( .apk files) must be signed with a certificate and their private key is owned by the developer. This certificate is used to identify the author of the app. The certificate does not need to be signed by a certificate authority, and Android apps ideally can and usually also use self-signed certificates. The role of certificates in Android is to identify the author of the app. This allows the system to grant or deny access to the application for signature-level permissions, and to grant or deny the application access to the same Linux identity as another app.

User ID and file access

At the time of installation, Android provides a unique Linux user ID for each package. This ID remains the same during the lifetime of the package on the device. On different devices, the same package may have different uid, and it is important that the UID of each package on the specified device is unique.

Because security is implemented at the process level, the code for any two packages typically cannot run in the same process because they need to run as different Linux users. You can use attributes in the tags of each package to AndroidManifest.xml manifest sharedUserId assign them the same user ID. After doing so, for security purposes, two packages will be treated as the same application with the same user ID and file permissions. Note that in order to remain secure, only two apps that have signed the same signature (and request the same shareduserid) are assigned the same user ID.

Any data stored by the app is assigned the app's user ID, and other packages typically cannot access the data. When you use getSharedPreferences(String, int) , openFileOutput(String, int) or openOrCreateDatabase(String, int, SQLiteDatabase.CursorFactory) create a new file, you can use MODE_WORLD_READABLE and/or MODE_WORLD_WRITEABLE tag to allow any other package to read/write to the file. When you set these tags, the files are still owned by your app, but their global read and/or write permissions are set appropriately so that any other app can see it.

Use permissions

The basic Android app is not associated with permissions by default, which means it cannot perform any action that adversely affects the user experience or any data on the device. To take advantage of protected device functionality, you must include one or more tags in your app manifest <uses-permission> .

For example, an app that needs to monitor incoming text messages is specified:

<manifestxmlns:android="Http://schemas.android.com/apk/res/android"
Package="Com.android.app.myapp">
<uses-permissionandroid:name="Android.permission.RECEIVE_SMS"/>
...
</manifest>

Permission levels

For more information about the different protection level permissions, see Normal permissions and Dangerous permissions.

These permissions are automatically granted if your app lists normal permissions in its manifest (that is, permissions that do not pose a significant risk to user privacy or device operations). If your app lists dangerous permissions in its manifest (that is, permissions that may affect user privacy or the device's normal operation), the user is asked to explicitly grant these permissions. The way Android makes requests depends on the system version, and the system version is the target of the app:

• If the device is running Android 6.0 (API level 23) or later, and the app targetSdkVersion is version 23 or later, the app requests permissions at run time for the user. Users can invoke permissions at any time, so the app needs to check whether it has the required permissions each time it runs. For more information about requesting permissions in your app, see the Using System Permissions training Guide.
• If the device is running Android 5.1 (API level 22) or earlier, and the app targetSdkVersion is 22 or earlier, users will be asked to grant permissions when they install the app. If you add new permissions to an updated version of the app, the system will require that permission to be granted when the user updates the app. Once the user installs the app, the only way they revoke permissions is to uninstall the app.

In general, permissions invalidation can result in the SecurityException application being thrown back. But there is no guarantee that every place is like this. For example, the sendBroadcast(Intent) method checks the permissions when the data is passed to each recipient, and you do not receive an exception after the method call returns, even if the permissions are invalidated. In almost all cases, however, a privilege failure is logged into the system log.

Please refer to the permissions provided by the Android system Manifest.permission . In addition, any app can define and enforce its own permissions, so this is not an exhaustive list of all possible permissions.

Specific permissions may be enforced in multiple locations during the program's run:

• Prevents the app from performing certain functions when the system is called.
• When you start activity, prevent the app from launching other apps ' activity.
• When you send and receive broadcasts, control who can receive your broadcasts, and who can send you broadcasts.
• When the content provider is accessed and manipulated.
• Bind to a service or start a service.

Automatic permission Adjustment

Over time, new restrictions may be added to the platform, and if you want to use a specific API, your app may have to request permissions that were not previously required. Because existing applications assume that access to these API apps is freely available, Android may apply new permission requests to the app manifest to avoid interrupting the app on the new platform version. Android will targetSdkVersion determine whether the app requires permissions based on the value provided for the property. If the value is lower than the version in which the permission is added, Android adds that permission.

For example, permissions are added to API level 4 WRITE_EXTERNAL_STORAGE to restrict access to shared storage space. If you have a targetSdkVersion version of 3 or earlier, this permission is added to the app on the update Android version of your device.

Note : If a permission is automatically added to the app, the app list on Google Play lists them even if your app may not actually need those additional permissions.

To avoid this situation and remove the default permissions that you do not need, always targetSdkVersion update to the highest version. The Build.VERSION_CODES permissions added to each version can be viewed in the document.

Normal permissions and Dangerous permissions

System permissions are divided into several levels of protection. The two most important levels of protection you need to know are normal permissions and dangerous permissions:

• normal permissions cover areas where the app needs to access its sandbox external data or resources, but is less risky for user privacy or other application operations. For example, setting the time zone's permissions is normal permissions. If the app declares that it requires normal permissions, the app is automatically granted that permission. For a complete list of current normal permissions, see normal permissions.
• Dangerous permissions cover the areas where the application needs data or resources that involve user privacy information, or that may affect the operations of the user's stored data or other applications. For example, a contact who is able to read a user is a dangerous permission. If the app declares that it requires dangerous permissions, the user must explicitly grant the permission to the app.

Special permissions

There are many permissions that behave differently from normal permissions and dangerous permissions. SYSTEM_ALERT_WINDOWand are WRITE_SETTINGS particularly sensitive, so most applications should not use them. If an app requires one of these permissions, it must be declared in the manifest and sent to the requesting user's authorized intent. A detailed management screen is displayed to the user in response to the intent.

For more information on how to request these permissions, see SYSTEM_ALERT_WINDOW and refer to the WRITE_SETTINGS entry.

Permission groups

All dangerous Android system permissions belong to the permission group. If the device is running Android 6.0 (API level 23) and the app targetSdkVersion is 23 or later, the following behavior occurs when the user requests dangerous permissions:

• If the app requests the dangerous permissions listed in its manifest, and the app does not currently have any permissions in the permission Group, a dialog box is displayed to the user describing the permission groups to be accessed by the app. The dialog box does not describe specific permissions within the group. For example, if the app requests READ_CONTACTS permissions, the System dialog box shows only the contact information that the app needs to access the device. If the user approves, the system will grant the app its requested permissions.
• If the app requests the dangerous permissions listed in its manifest, and the app already has another dangerous permission in the same permission group, the permission is granted immediately without any interaction with the user. For example, if an app has been requested and granted READ_CONTACTS permission, and then it requests it WRITE_CONTACTS , the permission is granted immediately.

Any permission can belong to a permission group, including normal permissions and app-defined permissions. However, the permissions group affects the user experience only when the permissions are dangerous. Permission groups with normal permissions can be ignored.

If the device is running Android 5.1 (API level 22) or earlier, and the app targetSdkVersion is 22 or earlier, the system will require the user to grant permissions at the time of installation. Again, the system tells the user only the permission groups that the application needs, without informing them of the specific permissions.

table 1. Dangerous permissions and permission groups.

Permission Groups	Permissions
CALENDAR	READ_CALENDAR WRITE_CALENDAR
CAMERA	CAMERA
CONTACTS	READ_CONTACTS WRITE_CONTACTS GET_ACCOUNTS
LOCATION	ACCESS_FINE_LOCATION ACCESS_COARSE_LOCATION
MICROPHONE	RECORD_AUDIO
PHONE	READ_PHONE_STATE CALL_PHONE READ_CALL_LOG WRITE_CALL_LOG ADD_VOICEMAIL USE_SIP PROCESS_OUTGOING_CALLS
SENSORS	BODY_SENSORS
SMS	SEND_SMS RECEIVE_SMS READ_SMS RECEIVE_WAP_PUSH RECEIVE_MMS
STORAGE	READ_EXTERNAL_STORAGE WRITE_EXTERNAL_STORAGE

Defining and Enforcing permissions

To implement your own permissions, you must first declare them in by using one or more <permission> elements AndroidManifest.xml .

For example, an app that wants to control who can start one of the Activity can declare permissions for this action as follows:

<manifest Xmlns:android="Http://schemas.android.com/apk/res/android"
Package="Com.example.myapp" >
<permission Android:name= "Com.example.myapp.permission.DEADLY_ACTIVITY"  
         android:label= "@string/permlab_ Deadlyactivity " 
         android:description = "@string/permdesc_deadlyactivity"  
         android:permissiongroup= 
         android: Protectionlevel= "dangerous"  /> 
     ... 
 </MANIFEST>            

Note : The system does not allow multiple packages to use the same name to claim permissions unless all packages are signed with the same certificate. If the package claims permissions, the system does not allow users to install additional packages with the same permission name unless they are signed with the same certificate as the first package. To avoid naming conflicts, it is recommended that you name the custom permission using the reverse domain name style, for example com.example.myapp.ENGAGE_HYPERSPACE .

protectionLevelA property is a required property that indicates how the system informs the user about an app that requires permissions, or who can have that permission, as described in the linked document.

android:permissionGroupproperty is an optional property and is used only to help the system display permissions to the user. In most cases, you will set this as a standard system group (listed in android.Manifest.permission_group ), but you can also define a group yourself. It is recommended that you use an existing group because it simplifies the permissions UI that is displayed to the user.

You need to provide a label and description for the permission. These are string resources that the user can see when they view the permissions list ( android:label ) or a single permission detail ( android:description ). The label should be brief, with a few words describing the key parts of the privilege-protected function. Describes the actions that the permission allows the holder to perform in a few sentences. Our engagement is described in two sentences: The first sentence describes the permission, the second sentence alerts the user to the type of error that may occur after the app has been granted permissions.

The following are examples of tags and descriptions of Call_phone permissions:

<string name = "Permlab_callphone" >directly call Phone Numbers</string> 
 <string  name= "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>              

You can use the Settings app and Shell commands to adb shell pm list permissions view the permissions currently defined on the system. To use the Settings app, go to Settings > Applications. Select an app and scroll down to see what permissions the app uses. For developers, the ADB '-s ' option displays the permissions in the form similar to what the user will see:

$ adb shell pm List permissions-sall permissions:network Communication:view Wi-Fi state, create Bluetooth connections, F Ullinternet access, view network Stateyour location:access extra location provider commands, fine (GPS) Location,mock Loc ation sources for testing, coarse (network-based) locationservices so cost you money:send SMS messages, directly call P Hone numbers ...

Custom Permission Suggestions

Apps can define their own custom permissions and <uses-permission> request custom permissions from other apps by defining the element. However, you should carefully evaluate whether your application is necessary to do so.

• If you want to design a set of apps that show functionality to each other, design your app to define only once for each permission, if possible. You must do this if all apps are not signed with the same certificate. Even if all apps are signed with the same certificate, the best practice is to define each permission only once.
• If the feature applies only to apps that are signed with the same signature as the provided app, you may be able to use signature checking to avoid defining custom permissions. When an app makes a request to another app, the second app can verify that the two apps are signed with the same certificate before complying with the request.
• If you are developing a set of apps that run only on your own devices, you should develop and install packages that manage all of the app permissions in the suite. This package itself does not provide any services. It simply declares all permissions, and then other apps in the suite <uses-permission> request these permissions through the element.

Implementing Permissions in Androidmanifest.xml

You can AndroidManifest.xml restrict access to all components of your system or app by applying advanced permissions. To do this, include the property on the desired component android:permission , and name the permission to control access to it.

ActivityPermissions (applied to <activity> tags) restrict who can initiate related Activity. The Context.startActivity() permission is checked at and, and the Activity.startActivityForResult() call is thrown if the caller does not have the required permissions SecurityException .

ServicePermissions (applied to <service> tags) restrict who can start or bind to related services. The Context.startService() permissions are checked at, Context.stopService() and, and the call is Context.bindService() thrown if the caller does not have the required permissions SecurityException .

BroadcastReceiverPermissions (applied to <receiver> tags) restrict who can send broadcasts to the relevant receiver. Context.sendBroadcast()Check permissions After returning because the system tries to pass the submitted broadcast to the specified receiver. Therefore, a permission invalidation does not cause the caller to be thrown back to the exception, but the intent is not passed. Similarly, you can Context.registerReceiver() provide permissions to control who can broadcast to a recipient that is registered programmatically. On the other hand, you can Context.sendBroadcast() provide permissions at invocation to restrict which Broadcastreceiver objects are allowed to receive broadcasts (see below).

ContentProviderPermissions (applied to <provider> tags) restrict who can access ContentProvider the data in. (Content providers have important additional security tools available, called URI permissions, which are described later.) Unlike other components, you can set two separate permission properties: android:readPermission restrict who can read the provider, and android:writePermission restrict who can write to the provider. Note that if the provider has read and write rights protection, only write permissions do not indicate that you can read the provider. The first time the provider is retrieved, the permissions are checked (if no permissions are thrown, SecurityException will be raised), and permissions are also checked on the provider when the operation is performed. ContentResolver.query()you need to have read access ContentResolver.insert() , use, ContentResolver.update() and ContentResolver.delete() require write permissions. In all these cases, no required permissions will cause the call to be thrown SecurityException .

Enforce permissions when sending broadcasts

In addition to enforcing the permissions of who can send intent to the registration BroadcastReceiver (as described above), you can also specify the permissions that are required to send the broadcast. By invoking a permission string Context.sendBroadcast() , you can require the recipient's app to have that permission to receive your broadcast.

Note that recipients and broadcasters may require permissions. At this point, both permission checks must pass before the intent can be passed to the relevant target.

Other rights enforcement

Arbitrary fine-grained permissions can be enforced on any service invocation. This can be Context.checkCallingPermission() done by means of the method. Called with the required permission string, it returns an integer that indicates whether the permission has been granted to the current calling process. Note that you can use this method only if you are performing an incoming call from another process, usually through an IDL interface published from the service or some other way assigned to another process.

There are many other useful ways to check permissions. If you have a PID for another process, you can use the Context method to Context.checkPermission(String, int, int) Check the permissions on that PID. If you have a package name for another app, you can use the direct Packagemanager method to PackageManager.checkPermission(String, String) see if specific permissions have been granted for a particular package.

URI Permissions

What has been described so far is the standard permission system, which is often not enough for content providers to use only this system. Content providers may need to protect themselves with read and write permissions, and their direct clients need to pass specific URIs to other apps for them to run. The attachment in the Mail app is a typical example. Access to the message should be protected through permissions because it is sensitive to user data. However, if you provide the URI of an image attachment to an image viewer, the image Viewer does not have permission to open the attachment because it has no reason to have access to all e-mail messages.

The workaround for this problem is to use the Per-uri permission mechanism: The caller can set and/or when the activity is started or the result is returned to the activity Intent.FLAG_GRANT_READ_URI_PERMISSION Intent.FLAG_GRANT_WRITE_URI_PERMISSION . This grants the receive Activity permission to access the specific data URI in intent, regardless of whether it has any permissions to access the data in the intent corresponding content provider.

This mechanism supports a common competency model where user interaction (opening attachments, selecting contacts from a list, and so on) drives temporary grant fine-grained permissions. This is a key feature that reduces the permissions required for your app to only those directly related to its behavior.

However, granting fine-grained URI permissions requires some cooperation with the content provider that owns these URIs. It is strongly recommended that the content provider implement this feature, and that android:grantUriPermissions this feature is supported through property or <grant-uri-permissions> token declarations.

Context.grantUriPermission() Context.revokeUriPermission() Context.checkUriPermission() More information can be found in the, and methods.

[Android Development] Permissions classification: Normal permissions and Dangerous permissions