本文共 18524 字，大约阅读时间需要 61 分钟。
权限概览 Permissions overview
目录
Android安全架构的一个核心设计要点是，默认情况下，任何 app 都没有权限执行任何可能对其他app、操作系统或用户产生不利影响的操作。这包括读写用户的私有数据(如联系人或电子邮件)、另一个应用程序的文件、执行网络访问、保持设备唤醒，等等
本页面概述了Android权限控制是如何工作的，包括:权限如何呈现给用户，请求安装时权限和运行时权限的区别，权限如何执行，权限的类型及其组。如果您只是想了解如何使用应用程序权限，请参阅 。
权限审批 Permission approval
app 必须在 中使用 标签来公开声明它所需的权限。例如，一个要发短信的 app 得在清单中添加这一行
...
如果您的 app 在其清单中列出了常规权限(即不会对用户隐私或设备操作造成太大风险的权限)，系统会自动将这些权限授予您的 app
如果 app 在清单中列出危险的权限(即可能影响用户隐私或设备正常操作的权限)，例如上面的SEND_SMS权限，用户必须明确同意授予这些权限。
关于常规和危险权限的更多信息，请看 。
提示请求获取危险权限 Request prompts for dangerous permissions
只有危险权限才需要用户同意授权。Android要求用户授予危险权限的方式取决于用户设备上运行的Android版本，以及应用程序针对的系统版本。
运行时申请授权 Runtime requests (Android 6.0 或更高)
如果设备运行在 Android 6.0 (API level 23) 或更高版本，并且 app 的 设为 23 或更高，用户在安装时不会收到任何申请权限的提示。您的 app 必须在运行时向用户申请使用危险权限。当您的 app 请求授权时，用户会看到一个系统对话框(如图1左侧所示)，告知用户此 app 试图访问哪个权限组。该对话框包含两个按钮拒绝 Deny和允许 Allow。
如果用户拒绝请求，下一次 app 申请权限时，该对话框将包含一个复选框，勾选则表示用户不希望再看到提示(参见图1右侧)。
如果用户勾选莫再提 Never ask again复选框并点击拒绝 Deny，那么您稍后尝试请求相同的权限，系统将不再提示用户。
即使用户授予应用程序所请求的权限，您也不能完全依赖它。用户还可以在系统设置中逐个启用和禁用权限。所以您应该始终在运行时检查并请求权限，以防止运行时错误()。
有关如何处理运行时权限请求的详细信息，请参见。
安装时请求 Install-time requests (Android 5.1.1 或更低)
如果设备运行在 Android 5.1.1 (API level 22)或更低，或 App 的 targetSdkVersion 在任何版本为22或更低的 Android 上运行时，系统会在 App 安装时自动向用户请求所有危险权限(见图2)。
图2 安装时权限对话框 如果用户点击** 同意 Accept**，则授予应用程序请求的所有权限。如果用户拒绝权限请求，系统将取消 app的安装。
如果 App 更新包含对额外权限的需要，则会提示用户在更新应用程序之前授予这些新权限。
关于权限请求，有些推荐的用户体验模式，请参见
了解如何检查和请求用户的权限，请参见 。
可选的硬件特性的权限 Permissions for optional hardware features
App 访问某些硬件功能(如蓝牙或摄像头)需要授权。然而，并不是所有的Android设备都有这些硬件功能。因此，如果 App 申请 权限，则需要在清单中添加 标签，以声明是否确实需要此功能。例如:
如果你声明 android:required="false"，那么Google Play 将允许你的 App 安装在没有这个功能的设备上。然后，您必须在运行时自行调用,来检查当前设备是否具有该特性，如果该特性不可用，则优雅地禁用 App 的相关功能。
如果您没有提供 标签，那么系统默认按 android:required="true" 处理。当 Google Play 看到您的应用程序请求相应的权限时，它假定您的应用程序需要此功能。所以它会从没有这个功能的设备中过滤掉你的应用。
更多有关信息，请参见
Permission enforcement
Permissions aren’t only for requesting system functionality. Services provided by apps can enforce custom permissions to restrict who can use them. For more information on declaring custom permissions，请参见。
Activity permission enforcement
Permissions applied using the android:permission attribute to the tag in the manifest restrict who can start that . The permission is checked during and . If the caller doesn’t have the required permission then is thrown from the call.
Service permission enforcement
Permissions applied using the android:permission attribute to the tag in the manifest restrict who can start or bind to the associated . The permission is checked during , and . If the caller doesn’t have the required permission then is thrown from the call.
Broadcast permission enforcement
Permissions applied using the android:permission attribute to the tag restrict who can send broadcasts to the associated BroadcastReceiver. The permission is checked after Context.sendBroadcast() returns, as the system tries to deliver the submitted broadcast to the given receiver. As a result, a permission failure doesn’t result in an exception being thrown back to the caller; it just doesn’t deliver the Intent.
In the same way, a permission can be supplied to Context.registerReceiver() to control who can broadcast to a programmatically registered receiver. Going the other way, a permission can be supplied when calling Context.sendBroadcast() to restrict which broadcast receivers are allowed to receive the 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. For more information, see Restricting broadcasts with permissions.
Content Provider permission enforcement
Permissions applied using the android:permission attribute to the tag restrict who can access the data in a ContentProvider. (Content providers have an important additional security facility available to them called URI permissions which is described next.) 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 doesn’t 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 is thrown), and as you perform operations on the provider. Using ContentResolver.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.
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 apps for them to operate on.
A typical example is attachments in a email app. Access to the emails 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 no longer has permission to open the attachment since it has no reason to hold a permission to access all email.
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_PERMISSION and/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 (such as opening an attachment or selecting a contact from a list) drives ad-hoc granting of fine-grained permission. This can be a key facility for reducing the permissions needed by apps to only those directly related to their behavior.
To build the most secure implementation that makes other apps accountable for their actions within yor app, you should use fine-grained permissions in this manner and declare your app’s support for it with the android:grantUriPermissions attribute or tag.
More information can be found in the Context.grantUriPermission(), Context.revokeUriPermission(), and Context.checkUriPermission() methods.
Other permission enforcement
Arbitrarily fine-grained permissions can be enforced at any call into a service. This is accomplished with the Context.checkCallingPermission() method. Call with a desired permission string and it returns 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 process ID (PID) of another process, you can use the Context.checkPermission() method to check a permission against that PID. If you have the package name of another app, you can use the PackageManager.checkPermission() method to find out whether that particular package has been granted a specific permission.
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 (thereby, “grandfathering” your app for the permission). Android makes the decision as to whether an app might need the permission based on the value provided for the targetSdkVersion attribute. If the value is lower than the version in which the permission was added, then Android adds the permission.
For example, the READ_EXTERNAL_STORAGE permission is enforced beginning with API level 19 to restrict access to the shared storage space. If your targetSdkVersion is 18 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.
Protection levels
Permissions are divided into several protection levels. The protection level affects whether runtime permission requests are required.
There are three protection levels that affect third-party apps: normal, signature, and dangerous permissions.
Normal 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 in its manifest that it needs a normal permission, the system automatically grants the app that permission at install time. The system doesn’t prompt the user to grant normal permissions, and users cannot revoke these permissions.
As of Android 9 (API level 28), the following permissions are classified as :- ACCESS_LOCATION_EXTRA_COMMANDS
- ACCESS_NETWORK_STATE
- ACCESS_NOTIFICATION_POLICY
- ACCESS_WIFI_STATE
- BLUETOOTH
- BLUETOOTH_ADMIN
- BROADCAST_STICKY
- CHANGE_NETWORK_STATE
- CHANGE_WIFI_MULTICAST_STATE
- CHANGE_WIFI_STATE
- DISABLE_KEYGUARD
- EXPAND_STATUS_BAR
- FOREGROUND_SERVICE
- GET_PACKAGE_SIZE
- INSTALL_SHORTCUT
- INTERNET
- KILL_BACKGROUND_PROCESSES
- MANAGE_OWN_CALLS
- MODIFY_AUDIO_SETTINGS
- NFC
- READ_SYNC_SETTINGS
- READ_SYNC_STATS
- RECEIVE_BOOT_COMPLETED
- REORDER_TASKS
- REQUEST_COMPANION_RUN_IN_BACKGROUND
- REQUEST_COMPANION_USE_DATA_IN_BACKGROUND
- REQUEST_DELETE_PACKAGES
- REQUEST_IGNORE_BATTERY_OPTIMIZATIONS
- SET_ALARM
- SET_WALLPAPER
- SET_WALLPAPER_HINTS
- TRANSMIT_IR
- USE_FINGERPRINT
- VIBRATE
- WAKE_LOCK
- WRITE_SYNC_SETTINGS
Signature permissions
The system grants these app permissions at install time, but only when the app that attempts to use a permission is signed by the same certificate as the app that defines the permission.
Note: Some signature permissions aren’t for use by third-party apps.
As of Android 8.1 (API level 27), the following permissions that third-party apps can use are classified as :
- BIND_ACCESSIBILITY_SERVICE
- BIND_AUTOFILL_SERVICE
- BIND_CARRIER_SERVICES
- BIND_CHOOSER_TARGET_SERVICE
- BIND_CONDITION_PROVIDER_SERVICE
- BIND_DEVICE_ADMIN
- BIND_DREAM_SERVICE
- BIND_INCALL_SERVICE
- BIND_INPUT_METHOD
- BIND_MIDI_DEVICE_SERVICE
- BIND_NFC_SERVICE
- BIND_NOTIFICATION_LISTENER_SERVICE
- BIND_PRINT_SERVICE
- BIND_SCREENING_SERVICE
- BIND_TELECOM_CONNECTION_SERVICE
- BIND_TEXT_SERVICE
- BIND_TV_INPUT
- BIND_VISUAL_VOICEMAIL_SERVICE
- BIND_VOICE_INTERACTION
- BIND_VPN_SERVICE
- BIND_VR_LISTENER_SERVICE
- BIND_WALLPAPER
- CLEAR_APP_CACHE
- MANAGE_DOCUMENTS
- READ_VOICEMAIL
- REQUEST_INSTALL_PACKAGES
- SYSTEM_ALERT_WINDOW
- WRITE_SETTINGS
- WRITE_VOICEMAIL
Dangerous permissions
angerous 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. Until the user approves the permission, your app cannot provide functionality that depends on that permission.
To use a dangerous permission, your app must prompt the user to grant permission at runtime. For more details about how the user is prompted, see Request prompt for dangerous permission.
For a list of dangerous permissions, see table 1 below.
Special permissions
There are a couple of permissions that don’t behave like normal and dangerous permissions. SYSTEM_ALERT_WINDOW and WRITE_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 the SYSTEM_ALERT_WINDOW and WRITE_SETTINGS reference entries.
All permissions provided by the Android system can be found at Manifest.permission.
Permission groups
Permissions are organized into groups related to a device’s capabilities or features. Under this system, permission requests are handled at the group level and a single permission group corresponds to several permission declarations in the app manifest. For example, the SMS group includes both the READ_SMS and the RECEIVE_SMS declarations. Grouping permissions in this way enables the user to make more meaningful and informed choices, without being overwhelmed by complex and technical permission requests.
All dangerous Android permissions belong to permission groups. Any permission can belong to a permission group regardless of protection level. However, a permission’s group only affects the user experience if the permission is dangerous. If the device is running Android 6.0 (API level 23) and the app’s is 23 or higher, the following system behavior applies when your app requests a dangerous permission:
- If the app doesn’t currently have any permissions in the permission group, the system shows the permission request dialog to the user describing the permission group that the app wants access to. The dialog doesn’t describe the specific permission within that group. For example, if an app requests the READ_CONTACTS permission, the system dialog 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 the app has already been granted 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_CONTACTS permission, and it then requests WRITE_CONTACTS, the system immediately grants that permission without showing the permissions dialog to the user.
Caution: Future versions of the Android SDK might move a particular permission from one group to another. Therefore, don’t base your app’s logic on the structure of these permission groups.
For example, READ_CONTACTS is in the same permission group as WRITE_CONTACTS as of Android 8.1 (API level 27). If your app requests the READ_CONTACTS permission, and then requests the WRITE_CONTACTS permission, don’t assume that the system can automatically grant the WRITE_CONTACTS permission.
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. For example, when an app requests READ_CONTACTS the install dialog lists the Contacts group. When the user accepts, only the READ_CONTACTS permission is granted to the app.
Note: Your app still needs to explicitly request every permission it needs, even if the user has already granted another permission in the same group. In addition, the grouping of permissions into groups may change in future Android releases. Your code shouldn’t have logic that depends on a set of particular permissions being in the same group.
Table 1. Dangerous permissions and permission groups.
| CALENDAR | READ_CALENDAR WRITE_CALENDAR |
| CALL_LOG | READ_CALL_LOG WRITE_CALL_LOG PROCESS_OUTGOING_CALLS |
| CAMERA | CAMERA |
| CONTACTS | READ_CONTACTS WRITE_CONTACTS GET_ACCOUNTS |
| LOCATION | ACCESS_FINE_LOCATION ACCESS_COARSE_LOCATION |
| MICROPHONE | RECORD_AUDIO |
| PHONE | READ_PHONE_STATE READ_PHONE_NUMBERS CALL_PHONE ANSWER_PHONE_CALLS ADD_VOICEMAIL USE_SIP |
| SENSORS | BODY_SENSORS |
| SMS | SEND_SMS RECEIVE_SMS READ_SMS RECEIVE_WAP_PUSH RECEIVE_MMS |
| STORAGE | READ_EXTERNAL_STORAGE WRITE_EXTERNAL_STORAGE |
Viewing an app’s permissions
You can view all the permissions currently defined in the system using the Settings app and the shell command adb shell pm list permissions. To use the Settings app, go to Settings > Apps. 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 sees them:
$ adb shell pm list permissions -sAll Permissions:Network communication: view Wi-Fi state, create Bluetooth connections, fullinternet access, view network stateYour location: access extra location provider commands, fine (GPS) location,mock location sources for testing, coarse (network-based) locationServices that cost you money: send SMS messages, directly call phone numbers...
You can also use the adb -g option to grant all permissions automatically when installing an app on an emulator or test device:
$ adb shell install -g MyApp.apk
Additional resources
- Request app permissions: The how-to guide for requesting permissions in your app.
- Permissions that imply feature requirements: Information about how requesting some permissions implicitly restricts your app to devices that include the corresponding hardware or software feature.
- <uses-permission>: API reference for the manifest tag that declares your app’s required permissions.
- Device compatibility: Information about how 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 Overview: A detailed discussion about the Android platform’s security model.
- “Mother, May I?” Asking for Permissions: This video from Android Dev Summit 2015 describes best practices for requesting permissions.
- Android M Permissions: This video from Google I/O 2015 explains changes made to the permissions model in Android 6.0.
转载地址：https://jerryjin.blog.csdn.net/article/details/86686027 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！
发表评论
最新留言
关于作者
