page.title=Permissions and User Data page.metaDescription=An overview of permissions on Android and how to manage them. page.tags="user data","permissions","identifiers" page.image=images/cards/card-user_2x.png page.article=true @jd:body

In this document

  1. Introduction
  2. Permission Groups
  3. Permission Requests and App Downloads
  4. Permission Requests Trend Downward

You should also read

  1. System Permissions
  2. Working with System Permissions

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.

Introduction

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.

Permission Groups

Permissions in Android are organized into permission 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 RECEIVE_SMS declarations.

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 WRITE_CALL_LOG permission, the user will be asked to grant access to the PHONE group (in API level 23 and higher), which is composed of the READ_PHONE_STATE, CALL_PHONE, READ_CALL_LOG, WRITE_CALL_LOG, ADD_VOICEMAIL, USE_SIP, and 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.

  1. API Call →
  2. Triggers a specific Permission Group access request →
  3. Successful request grants access to all permissions in group (if auto-update enabled) →
  4. Each permission grants access to all APIs under that permission

As another example, let's assume your application uses one or more TelephonyManager 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:

Permission Requests and App Downloads

I'm currently using the READ_PHONE_STATE permission in Android to pause my media player when there's a call, and to resume playback when the call is over. The permission seems to scare a lot of people...1

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

Figure 1. Distribution of permission groups use across Arcade Games category.

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

Permission Requests Trend Downward

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.

Figure 2. Developer usage of popular permissions has decreased over time.

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 (READ_PHONE_STATE, ACCESS_FINE_LOCATION, and 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.

References

[1] Developer quote on StackOverflow. (source)

[2] 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.

[3] 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.

[4] Teens and Mobile Apps Privacy. (source)