Permissions in Android Studio

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.

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

Permission Group	Permissions
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 -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.