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
PROTECTION_NORMAL
: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.As of Android 8.1 (API level 27), the following permissions that third-party apps can use are classified as
PROTECTION_SIGNATURE
: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
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. 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 theREAD_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
targetSdkVersion
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 requestsWRITE_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,
If the device is running Android 5.1 (API level 22) or lower, or the app's
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.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.
Permission Group | Permissions |
---|---|
CALENDAR |
|
CALL_LOG |
|
CAMERA |
|
CONTACTS |
|
LOCATION |
|
MICROPHONE |
|
PHONE |
|
SENSORS |
|
SMS |
|
STORAGE
|
Viewing an app's permissions
You can view all the permissions currently defined in the system using the Settings app and the shell commandadb 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 -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 ...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.
No comments:
Post a Comment