标签:
User does not have to grant any permissions when they install or upgrade the app. Instead, the app requests permissions as it needs them, and the system shows a dialog to the user asking for the permission.
With the M Developer Preview, the platform introduces a new app permissions model. Here‘s a summary of the key components of this new model:
CONTACTS
permission group contains permissions to read and write the user‘s contacts and profile information.Limited Permissions Granted at Install Time: When the user installs or updates the app, the system grants the app all permissions listed in the manifest that fall under PROTECTION_NORMAL
. For example, alarm clock and internet permissions fall under PROTECTION_NORMAL
, so they are automatically granted at install time. For more information about how normal permissions are handled, see Normal Permissions.
The system may also grant the app signature permissions, as described in System components and signature permissions. The user is not prompted to grant any permissions at install time.
This permission model changes the way your app behaves for features that require permissions. Here‘s a summary of the development practices you should follow to adjust to this model:
PROTECTION_NORMAL
.Figure 1. Permission screen in the app‘s Settings.
Note: If an app targets the M Developer Preview, it must use the new permissions model.
As of the launch of the M Developer Preview, not all Google apps fully implement the new permissions model. Google is updating these apps over the course of the M Developer Preview to properly respect Permissions toggle settings.
Note: If your app has its own API surface, do not proxy permissions without first ensuring the caller has the requisite permissions to access that data.
Related permissions are divided into permission groups to allow users to grant related permissions to an app in a single action. The user only has to grant permission once per app for each permission group. If the app subsequently requests a permission from the same permission group, the system automatically grants the permission without any action from the user. The system calls your app‘s onRequestPermissionsResult()
method just as if the user had granted permission through the dialog box.
For example, suppose an app lists in its manifest that it needs the SEND_SMS
and RECEIVE_SMS
permissions, which both belong to android.permission-group.SMS
. When the app needs to send a message, it requests theSEND_SMS
permission. The system shows the user a dialog box asking if the app can have access to SMS. If the user agrees, the system grants the app the SEND_SMS
permission it requested. Later, the app requestsRECEIVE_SMS
. The system automatically grants this permission, since the user had already approved a permission in the same permission group.
Ordinarily, when the user installs an app, the system only grants the app the permissions listed in the manifest that fall under PROTECTION_NORMAL
. However, under some circumstances the system grants the app more permissions:
PROTECTION_SIGNATURE
, and the app is signed with the same certificate as the app that declared those permissions, the system grants the requesting app those permissions on installation. Apps cannot request signature permissions at runtime.If an app does not target the M Developer Preview, the app continues to use the old permissions model even on M Preview devices. When the user installs the app, the system asks the user to grant all permissions listed in the app‘s manifest.
Note: On devices running the M Developer Preview, a user can turn off permissions for any app (including legacy apps) from the app‘s Settings screen. If a user turns off permissions for a legacy app, the system silently disables the appropriate functionality. When the app attempts to perform an operation that requires that permission, the operation will not necessarily cause an exception. Instead, it might return an empty data set, signal an error, or otherwise exhibit unexpected behavior. For example, if you query a calendar without permission, the method returns an empty data set.
If you install an app using the new permissions model on a device that is not running the M Preview, the system treats it the same as any other app: the system asks the user to grant all declared permissions at install time.
Note: For the preview release, you must set the minimum SDK version to the M Preview SDK to compile with the preview SDK. This means you will not be able to test such apps on older platforms during the developer preview.
In many cases, you can choose between two ways for your app to perform a task. You can have your app ask for permission to perform the operation itself. Alternatively, you can have the app use an intent to have another app perform the task.
For example, suppose your app needs to be able to take pictures with the device camera. Your app can request the android.permission.CAMERA
permission, which allows your app to access the camera directly. Your app would then use the camera APIs to control the camera and take a picture. This approach gives your app full control over the photography process, and lets you incorporate the camera UI into your app.
However, if you don‘t need such control, you can just use an ACTION_IMAGE_CAPTURE
intent to request an image. When you start the intent, the user is prompted to choose a camera app (if there isn‘t already a default camera app), and that app takes the picture. The camera app returns the picture to your app‘s onActivityResult()
method.
Similarly, if you need to make a phone call, access the user‘s contacts, and so on, you can do that by creating an appropriate intent, or you can request the permission and access the appropriate objects directly. There are advantages and disadvantages to each approach.
If you use permissions:
If you use an intent:
If your app targets the new M Developer Preview, you must use the new permissions model. This means that in addition to declaring your needed permissions in the manifest, you must also check to see if you have the permissions at run time, and request the permissions if you do not already have them.
To enable the new M Developer Preview permissions model, set the app‘s targetSdkVersion
attribute to "MNC"
, and compileSdkVersion
to "android-MNC"
. Doing so enables all the new permissions features.
For the preview release, you must set minSdkVersion
to "MNC"
to compile with the preview SDK.
You can use the new <uses-permission-sdk-m>
element in the app manifest to indicate that a permission is only needed on the M Developer Preview. If you declare a permission this way, then whenever the app is installed on an older device, the system does not prompt the user or grant the permission to the app. By using the <uses-permission-sdk-m>
element, you can add new permissions to updated versions of your app without forcing users to grant permissions when they install the update.
If the app is running on a device with the M Developer Preview, <uses-permission-sdk-m>
behaves the same as<uses-permission>
. The system does not prompt the user to grant any permissions when they install the app, and the app requests permissions as they are needed.
If your app uses the new M Developer Preview permissions model, the user is not asked to grant all permissions when the app is first launched on a device running the M Preview. Instead, your app requests permissions as they are needed. When your app requests a permission, the system shows a dialog to the user.
If your app runs on a device that has SDK 22 or lower, the app uses the old permissions model. When the user installs the app, they are prompted to grant all the permissions your app requests in its manifest, except for those permissions which are labeled with <uses-permission-sdk-m>
.
This permissions model is only supported on devices running the M Developer Preview. Before calling any of these methods, the app should verify what platform it‘s running on by checking the value of Build.VERSION.CODENAME
. If the device is running the M Developer Preview, CODENAME
is "MNC"
.
When the user tries to do something that requires a permission, the app checks to see if it currently has permission to perform this operation. To do this, the app calls Context.checkSelfPermission(permission_name)
. The app should perform this check even if it knows the user has already granted that permission, since the user can revoke an app‘s permissions at any time. For example, if a user wants to use an app to take a picture, the app callsContext.checkSelfPermission(Manifest.permission.CAMERA)
.
标签:
原文地址:http://www.cnblogs.com/WalsonWang/p/4720026.html