Android is a privilege-separated operating system, in which each app
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 apps from each other and from the system.
Because each Android app operates in a process sandbox, apps must
explicitly request access to resources and data outside their sandbox. They
request this access by declaring the permissions they need for
additional capabilities not provided by the basic sandbox. Depending on how
sensitive the area is, the system may grant the permission automatically, or
may prompt the user to approve or reject the request.
This page describes how apps can request standard system permissions. The
following document, Defining Permissions,
describes how apps can define their own permissions, so they can securely
share their data and capabilities with other apps.
A basic Android app 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
tags in your app
For example, an app that needs to monitor incoming SMS messages would
If your app lists normal permissions 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 accesses
permission-protected APIs. 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.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 a SecurityException being thrown back to the app. 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 app may also define and enforce its
own permissions, so this is not a comprehensive list of all possible
A particular permission may be enforced at a number of places during your
At the time of a call into the system, to prevent an app from
executing certain functions.
When starting an activity, to prevent apps from launching
activities of other apps.
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
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 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 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
Viewing an app's permissions
You can view at 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 will see them:
$ adb shell pm list permissions -s
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
Permission required to install unknown apps
If your app targets Android 8.0 (API level 26) or higher and triggers APK
installs using the package installer API, you need to add the
permission, as shown in the following code snippet:
Only apps that use this permission can appear in the Install unknown apps
system settings screen. For more information, see the Android Studio publishing
guide to learn how to install unknown apps.
Normal and Dangerous Permissions
System permissions are divided into several protection levels. The two most
important protection levels to know about are normal and
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.
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.
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
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
and it then requests WRITE_CONTACTS, the system immediately grants that permission.
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 your app requests
permission, then the
you shouldn't assume that the system can automatically grant the
WRITE_CONTACTS permission, even though it's in the same
permission group as READ_CONTACTS as of Android 8.0 (API level
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
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
Table 1. Dangerous permissions and permission groups.