android6.0 Permissions(原文)

Android is a privilege-separated operating system, in which each application runs with a distinct system identity (Linux user ID and group ID). Parts of the system are also separated into distinct identities. Linux thereby isolates applications from each other and from the system.


Additional finer-grained security features are provided through a "permission" mechanism that enforces restrictions on the specific operations that a particular process can perform, and per-URI permissions for granting ad hoc access to specific pieces of data.


This document describes how application developers can use the security features provided by Android. A more generalAndroid Security Overview is provided in the Android Open Source Project.


Security Architecture


A central design point of the Android security architecture is that no application, by default, has permission to perform any operations that would adversely impact other applications, the operating system, or the user. This includes reading or writing the user's private data (such as contacts or emails), reading or writing another application's files, performing network access, keeping the device awake, and so on.


Because each Android application operates in a process sandbox, applications must explicitly share resources and data. They do this by declaring the permissions they need for additional capabilities not provided by the basic sandbox. Applications statically declare the permissions they require, and the Android system prompts the user for consent.


The application sandbox does not depend on the technology used to build an application. In particular the Dalvik VM is not a security boundary, and any app can run native code (see the Android NDK). All types of applications — Java, native, and hybrid — are sandboxed in the same way and have the same degree of security from each other.


Application Signing


All APKs (.apk files) must be signed with a certificate whose private key is held by their developer. This certificate identifies the author of the application. The certificate does not need to be signed by a certificate authority; it is perfectly allowable, and typical, for Android applications to use self-signed certificates. The purpose of certificates in Android is to distinguish application authors. This allows the system to grant or deny applications access to signature-level permissions and to grant or deny an application's request to be given the same Linux identity as another application.


User IDs and File Access


At install time, Android gives each package a distinct Linux user ID. The identity remains constant for the duration of the package's life on that device. On a different device, the same package may have a different UID; what matters is that each package has a distinct UID on a given device.


Because security enforcement happens at the process level, the code of any two packages cannot normally run in the same process, since they need to run as different Linux users. You can use the sharedUserId attribute in theAndroidManifest.xml's manifest tag of each package to have them assigned the same user ID. By doing this, for purposes of security the two packages are then treated as being the same application, with the same user ID and file permissions. Note that in order to retain security, only two applications signed with the same signature (and requesting the same sharedUserId) will be given the same user ID.


Any data stored by an application will be assigned that application's user ID, and not normally accessible to other packages. When creating a new file withgetSharedPreferences(String, int),openFileOutput(String, int), oropenOrCreateDatabase(String, int, SQLiteDatabase.CursorFactory), you can use theMODE_WORLD_READABLE and/or MODE_WORLD_WRITEABLEflags to allow any other package to read/write the file. When setting these flags, the file is still owned by your application, but its global read and/or write permissions have been set appropriately so any other application can see it.


Using Permissions


A basic Android application has no permissions associated with it by default, meaning it cannot do anything that would adversely impact the user experience or any data on the device. To make use of protected features of the device, you must include one or more <uses-permission> tags in yourapp manifest.


For example, an application that needs to monitor incoming SMS messages would specify:


<manifest xmlns:android="http://schemas.android.com/apk/res/android"
    package="com.android.app.myapp" >
    <uses-permission android:name="android.permission.RECEIVE_SMS" />
    ...
</manifest>


Permission Levels


For more information about the different protection levels for permissions, see Normal and Dangerous Permissions.


If your app listsnormalpermissions in its manifest (that is, permissions that don't pose much risk to the user's privacy or the device's operation), the system automatically grants those permissions. If your app lists dangerous permissions in its manifest (that is, permissions that could potentially affect the user's privacy or the device's normal operation), the system asks the user to explicitly grant those permissions. The way Android makes the requests depends on the system version, and the system version targeted by your app:


If the device is running Android 6.0 (API level 23) or higher,and the app's targetSdkVersion is 23 or higher, the app requests permissions from the user at run-time. The user can revoke the permissions at any time, so the app needs to check whether it has the permissions every time it runs. For more information about requesting permissions in your app, see the Working with System Permissions training guide.If the device is running Android 5.1 (API level 22) or lower,or the app's targetSdkVersion is 22 or lower, the system asks the user to grant the permissions when the user installs the app. If you add a new permission to an updated version of the app, the system asks the user to grant that permission when the user updates the app. Once the user installs the app, the only way they can revoke the permission is by uninstalling the app.


Often times a permission failure will result in aSecurityException being thrown back to the application. However, this is not guaranteed to occur everywhere. For example, the sendBroadcast(Intent) method checks permissions as data is being delivered to each receiver, after the method call has returned, so you will not receive an exception if there are permission failures. In almost all cases, however, a permission failure will be printed to the system log.


The permissions provided by the Android system can be found at Manifest.permission. Any application may also define and enforce its own permissions, so this is not a comprehensive list of all possible permissions.


A particular permission may be enforced at a number of places during your program's operation:


At the time of a call into the system, to prevent an application from executing certain functions.When starting an activity, to prevent applications from launching activities of other applications.Both sending and receiving broadcasts, to control who can receive your broadcast or who can send a broadcast to you.When accessing and operating on a content provider.Binding to or starting a service.


Automatic permission adjustments


Over time, new restrictions may be added to the platform such that, in order to use certain APIs, your app must request a permission that it previously did not need. Because existing apps assume access to those APIs is freely available, Android may apply the new permission request to the app's manifest to avoid breaking the app on the new platform version. Android makes the decision as to whether an app might need the permission based on the value provided for thetargetSdkVersion attribute. If the value is lower than the version in which the permission was added, then Android adds the permission.


For example, the WRITE_EXTERNAL_STORAGE permission was added in API level 4 to restrict access to the shared storage space. If your targetSdkVersion is 3 or lower, this permission is added to your app on newer versions of Android.


Caution: If a permission is automatically added to your app, your app listing on Google Play lists these additional permissions even though your app might not actually require them.


To avoid this and remove the default permissions you don't need, always update your targetSdkVersion to be as high as possible. You can see which permissions were added with each release in the Build.VERSION_CODES documentation.


Normal and Dangerous Permissions


System permissions are divided into several protection levels. The two most important protection levels to know about arenormal and dangerous permissions:


Normal permissions cover areas where your app needs to access data or resources outside the app's sandbox, but where there's very little risk to the user's privacy or the operation of other apps. For example, permission to set the time zone is a normal permission. If an app declares that it needs a normal permission, the system automatically grants the permission to the app. For a full listing of the current normal permissions, see Normal permissions.Dangerous permissions cover areas where the app wants data or resources that involve the user's private information, or could potentially affect the user's stored data or the operation of other apps. For example, the ability to read the user's contacts is a dangerous permission. If an app declares that it needs a dangerous permission, the user has to explicitly grant the permission to the app.


Special Permissions


There are a couple of permissions that don't behave like normal and dangerous permissions.SYSTEM_ALERT_WINDOW andWRITE_SETTINGS are particularly sensitive, so most apps should not use them. If an app needs one of these permissions, it must declare the permission in the manifest, and send an intent requesting the user's authorization. The system responds to the intent by showing a detailed management screen to the user.


For details on how to request these permissions, see theSYSTEM_ALERT_WINDOW andWRITE_SETTINGS reference entries.


Permission groups


All dangerous Android system permissions belong to permission groups. If the device is running Android 6.0 (API level 23) and the app's targetSdkVersion is 23 or higher, the following system behavior applies when your app requests a dangerous permission:


If an app requests a dangerous permission listed in its manifest, and the app does not currently have any permissions in the permission group, the system shows a dialog box to the user describing the permission group that the app wants access to. The dialog box does not describe the specific permission within that group. For example, if an app requests the READ_CONTACTS permission, the system dialog box just says the app needs access to the device's contacts. If the user grants approval, the system gives the app just the permission it requested.If an app requests a dangerous permission listed in its manifest, and the app already has another dangerous permission in the same permission group, the system immediately grants the permission without any interaction with the user. For example, if an app had previously requested and been granted the READ_CONTACTSpermission, and it then requests WRITE_CONTACTS, the system immediately grants that permission.


Any permission can belong to a permission group, including normal permissions and permissions defined by your app. However, a permission's group only affects the user experience if the permission is dangerous. You can ignore the permission group for normal permissions.


If the device is running Android 5.1 (API level 22) or lower, or the app's targetSdkVersion is 22 or lower, the system asks the user to grant the permissions at install time. Once again, the system just tells the user what permission groups the app needs, not the individual permissions.


Table 1. Dangerous permissions and permission groups.


Permission GroupPermissionsCALENDARREAD_CALENDARWRITE_CALENDARCAMERACAMERACONTACTSREAD_CONTACTSWRITE_CONTACTSGET_ACCOUNTSLOCATIONACCESS_FINE_LOCATIONACCESS_COARSE_LOCATIONMICROPHONERECORD_AUDIOPHONEREAD_PHONE_STATECALL_PHONEREAD_CALL_LOGWRITE_CALL_LOGADD_VOICEMAILUSE_SIPPROCESS_OUTGOING_CALLSSENSORSBODY_SENSORSSMSSEND_SMSRECEIVE_SMSREAD_SMSRECEIVE_WAP_PUSHRECEIVE_MMSSTORAGEREAD_EXTERNAL_STORAGEWRITE_EXTERNAL_STORAGE


Defining and Enforcing Permissions


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


For example, an application that wants to control who can start one of its activities could declare a permission for this operation as follows:


<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>


The <protectionLevel> attribute is required, telling the system how the user is to be informed of applications requiring the permission, or who is allowed to hold that permission, as described in the linked documentation.


The <permissionGroup> attribute is optional, and only used to help the system display permissions to the user. You will usually want to set this to either a standard system group (listed in android.Manifest.permission_group) or in more rare cases to one defined by yourself. It is preferred to use an existing group, as this simplifies the permission UI shown to the user.


Note that both a label and description should be supplied for the permission. These are string resources that can be displayed to the user when they are viewing a list of permissions (android:label) or details on a single permission ( android:description). The label should be short, a few words describing the key piece of functionality the permission is protecting. The description should be a couple sentences describing what the permission allows a holder to do. Our convention for the description is two sentences, the first describing the permission, the second warning the user of what bad things can happen if an application is granted the permission.


Here is an example of a label and description for the CALL_PHONE permission:


    <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 look at the permissions currently defined in the system with the Settings app and the shell command adb shell pm list permissions. To use the Settings app, go to Settings > Applications. Pick an app and scroll down to see the permissions that the app uses. For developers, the adb '-s' option displays the permissions in a form similar to how the user will see them:


$ adb shell pm list permissions -s
All Permissions:


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


...


Enforcing Permissions in AndroidManifest.xml


High-level permissions restricting access to entire components of the system or application can be applied through yourAndroidManifest.xml. All that this requires is including anandroid:permission attribute on the desired component, naming the permission that will be used to control access to it.


Activity permissions (applied to the <activity> tag) restrict who can start the associated activity. The permission is checked during Context.startActivity() andActivity.startActivityForResult(); if the caller does not have the required permission then SecurityExceptionis thrown from the call.


Service permissions (applied to the <service> tag) restrict who can start or bind to the associated service. The permission is checked during Context.startService(),Context.stopService() and Context.bindService(); if the caller does not have the required permission thenSecurityException is thrown from the call.


BroadcastReceiver permissions (applied to the<receiver> tag) restrict who can send broadcasts to the associated receiver. The permission is checked afterContext.sendBroadcast() returns, as the system tries to deliver the submitted broadcast to the given receiver. As a result, a permission failure will not result in an exception being thrown back to the caller; it will just not deliver the intent. In the same way, a permission can be supplied toContext.registerReceiver() to control who can broadcast to a programmatically registered receiver. Going the other way, a permission can be supplied when callingContext.sendBroadcast() to restrict which BroadcastReceiver objects are allowed to receive the broadcast (see below).


ContentProvider permissions (applied to the<provider> tag) restrict who can access the data in aContentProvider. (Content providers have an important additional security facility available to them called URI permissions which is described later.) Unlike the other components, there are two separate permission attributes you can set: android:readPermission restricts who can read from the provider, and android:writePermission restricts who can write to it. Note that if a provider is protected with both a read and write permission, holding only the write permission does not mean you can read from a provider. The permissions are checked when you first retrieve a provider (if you don't have either permission, a SecurityException will be thrown), and as you perform operations on the provider. UsingContentResolver.query() requires holding the read permission; using ContentResolver.insert(),ContentResolver.update(),ContentResolver.delete() requires the write permission. In all of these cases, not holding the required permission results in a SecurityException being thrown from the call.


Enforcing Permissions when Sending Broadcasts


In addition to the permission enforcing who can send Intents to a registered BroadcastReceiver (as described above), you can also specify a required permission when sending a broadcast. By calling Context.sendBroadcast() with a permission string, you require that a receiver's application must hold that permission in order to receive your broadcast.


Note that both a receiver and a broadcaster can require a permission. When this happens, both permission checks must pass for the Intent to be delivered to the associated target.


Other Permission Enforcement


Arbitrarily fine-grained permissions can be enforced at any call into a service. This is accomplished with theContext.checkCallingPermission() method. Call with a desired permission string and it will return an integer indicating whether that permission has been granted to the current calling process. Note that this can only be used when you are executing a call coming in from another process, usually through an IDL interface published from a service or in some other way given to another process.


There are a number of other useful ways to check permissions. If you have the pid of another process, you can use the Context method Context.checkPermission(String, int, int)to check a permission against that pid. If you have the package name of another application, you can use the direct PackageManager methodPackageManager.checkPermission(String, String) to find out whether that particular package has been granted a specific permission.


URI Permissions


The standard permission system described so far is often not sufficient when used with content providers. A content provider may want to protect itself with read and write permissions, while its direct clients also need to hand specific URIs to other applications for them to operate on. A typical example is attachments in a mail application. Access to the mail should be protected by permissions, since this is sensitive user data. However, if a URI to an image attachment is given to an image viewer, that image viewer will not have permission to open the attachment since it has no reason to hold a permission to access all e-mail.


The solution to this problem is per-URI permissions: when starting an activity or returning a result to an activity, the caller can set Intent.FLAG_GRANT_READ_URI_PERMISSIONand/or Intent.FLAG_GRANT_WRITE_URI_PERMISSION. This grants the receiving activity permission access the specific data URI in the Intent, regardless of whether it has any permission to access data in the content provider corresponding to the Intent.


This mechanism allows a common capability-style model where user interaction (opening an attachment, selecting a contact from a list, etc) drives ad-hoc granting of fine-grained permission. This can be a key facility for reducing the permissions needed by applications to only those directly related to their behavior.


The granting of fine-grained URI permissions does, however, require some cooperation with the content provider holding those URIs. It is strongly recommended that content providers implement this facility, and declare that they support it through the android:grantUriPermissions attribute or <grant-uri-permissions> tag.


More information can be found in theContext.grantUriPermission(),Context.revokeUriPermission(), andContext.checkUriPermission() methods.


CONTINUE READING ABOUT:


Permissions that Imply Feature RequirementsInformation about how requesting some permissions will implicitly restrict your app to devices that include the corresponding hardware or software feature.<uses-permission>API reference for the manifest tag that declare's your app's required system permissions.Manifest.permissionAPI reference for all system permissions.


YOU MIGHT ALSO BE INTERESTED IN:


Device CompatibilityInformation about Android works on different types of devices and an introduction to how you can optimize your app for each device or restrict your app's availability to different devices.Android Security OverviewA detailed discussion about the Android platform's security model.