Permissions protect sensitive information available from a device and should only be used when access to information is necessary for the functioning of your app.
This document provides a high-level overview on how permissions work in Android so you can make better, more informed decisions about the permissions you're requesting. The information in this document is not use-case specific and avoids complex, low-level discussions of the underlying code.
For specific recommendations on how to manage permissions, please see Best Practices for App Permissions. For best practices on using unique identifiers on Android, please see Best Practices for Unique Identifiers. For details on how to work with permissions in your code, see Working with System Permissions.
Every Android application must have a manifest file that presents essential information about the app to the Android system. The Android system also requires apps to request permission when they want to access sensitive device or user information, and these requests must be documented in advance as a part of your app's manifest. Moreover, accessing sensitive information can affect user behavior, so it's important to make sure you are only making permission requests when that information is necessary for the functioning of your app.
Permissions in Android are organized into
groups that organize, and group, permissions 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
This arrangement is simpler and more informative for users; once an app is granted permission to access the group, it can use API calls within that group and users with auto-update enabled will not be asked for additional permissions because they have already granted access to the group. Grouping permissions in this way enables the user to make more meaningful and informed choices, without being overwhelmed by complex and technical permission requests.
This also means that when you request access to a particular API call or
query a content provider behind a permission, the user will be presented with
a request to grant permission for the whole group rather than the specific
API call. For example, if you request the
permission, the user will be asked to grant access to the PHONE
group (in API level 23 and higher), which is composed of the
PROCESS_OUTGOING_CALLS permissions, and
all their associated methods.
One consequence of grouping permissions is that a single API call within your app can have a multiplying effect in terms of the number of permissions requested by your app.
As another example, let's assume your application uses one or more
methods, such as:
TelephonyManager.getDeviceId() TelephonyManager.getSubscriberId() TelephonyManager.getSimSerialNumber() TelephonyManager.getLine1Number() TelephonyManager.getVoiceMailNumber()
To use these methods, the
READ_PHONE_STATE permission must be
declared in the app's manifest, and the associated permission group,
PHONE, will be surfaced to the user. This
is important, because it means the user will be asked to grant permission for
the relevant group and all its associated permissions and API calls, rather
than for the specific API call you're requesting.
For a full mapping between permissions and their associated permission groups, please refer to the appropriate version-specific documentation below:
Research shows that among apps that are otherwise identical (e.g., functionality, brand recognition), requesting fewer permissions leads to more downloads. Publicly available sources exist that assign grades to apps based on their permissions usage and allow users to compare related apps by score; such grades exist for many of the current Android apps and users pay close attention to the related rankings.
One study2, in which users were shown two unbranded apps with similar ratings that had the same functionality but different sets of permission requests, showed that users were, on average, 3 times more likely to install the app with fewer permissions requests. And a similar study 3 showed that users are 1.7 times more likely, on average, to select the application with fewer permission requests.
Finally, permissions usage is not evenly distributed across apps within a similar category of Play apps. For example, 39.3% of arcade game apps in the Play store request no permissions that are surfaced to the user while only 1.5% of arcade games request the Phone permission group (see Figure 1).
Users comparing your app to other similar apps may determine that it is making unusual permission requests for that category - in this case, Arcade Games apps accessing the Phone permission group. As a result, they may install a similar app in that category that avoids those requests.4
A recent analysis of Play store apps over time indicated that many developers trim permissions after first publishing their apps, suggesting that they may be employing more caution around which permission groups they declare.
The graph in Figure 2 illustrates this trend. There has been a
steady decrease in the average percentage of developers' apps requesting at
least one of the three most popular permissions in the Play store
ACCESS_COARSE_LOCATION). These results indicate that developers
are reducing the permissions their apps request in response to user behavior.
The bottom line is that providing the same functionality to the user with minimal access to sensitive information means more downloads for your app. For specific recommendations on how to achieve this, please see Best Practices for Application Permissions.
 Developer quote on StackOverflow. (source)
 Using Personal Examples to Improve Risk Communication for Security and Privacy Decisions, by M. Harbach, M. Hettig, S. Weber, and M. Smith. In Proceedings of ACM CHI 2014.
 Modeling Users’ Mobile App Privacy Preferences: Restoring Usability in a Sea of Permission Settings, by J. Lin B. Liu, N. Sadeh and J. Hong. In Proceedings of SOUPS 2014.
 Teens and Mobile Apps Privacy. (source)