| 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 |
| |
| <div id="tb-wrapper"> |
| <div id="tb"> |
| <h2>In this document</h2> |
| <ol> |
| <li><a href="#introduction">Introduction</a></li> |
| <li><a href="#permission_groups">Permission Groups</a></li> |
| <li><a href="#permission_requests_and_app_downloads">Permission |
| Requests and App Downloads</a></li> |
| <li><a href="#permission_requests_trend_downward">Permission Requests |
| Trend Downward</a></li> |
| </ol> |
| <h2>You should also read</h2> |
| <ol> |
| <li><a href="{@docRoot}guide/topics/security/permissions.html">System Permissions</a></li> |
| <li><a href="{@docRoot}training/permissions/index.html">Working with System |
| Permissions</a></li> |
| </ol> |
| </div> |
| </div> |
| |
| <p> |
| 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. |
| </p> |
| |
| <p> |
| 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. |
| </p> |
| |
| <p> |
| For specific recommendations on how to manage permissions, please see |
| <a href="{@docRoot}training/articles/user-data-permissions.html">Best |
| Practices for App Permissions</a>. For best practices on using unique |
| identifiers on Android, please see <a href= |
| "{@docRoot}training/articles/user-data-ids.html">Best Practices for Unique |
| Identifiers</a>. For details on how to work with permissions in your code, |
| see <a href="{@docRoot}training/permissions/index.html">Working with System |
| Permissions</a>. |
| </p> |
| |
| |
| <h2 id="introduction">Introduction</h2> |
| |
| <p> |
| Every Android application must have a <em>manifest file</em> 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. |
| </p> |
| |
| |
| <h2 id="permission_groups">Permission Groups</h2> |
| |
| <p> |
| Permissions in Android are organized into <code><a href= |
| "{@docRoot}guide/topics/security/permissions.html#perm-groups">permission |
| groups</a></code> 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 <em><strong>single permission group</strong></em> |
| corresponds to <em><strong>several permission declarations</strong></em> in |
| the app manifest; for example, the SMS group includes both the |
| <code>READ_SMS</code> and the <code>RECEIVE_SMS</code> declarations. |
| </p> |
| |
| |
| <div class="wrap"> |
| <img src="{@docRoot}images/training/articles/user-data-overview-permissions-flow01.jpg"> |
| </div> |
| |
| <p> |
| 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. |
| </p> |
| |
| <p> |
| 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 <code>WRITE_CALL_LOG</code> |
| permission, the user will be asked to grant access to the <em>PHONE</em> |
| group (in API level 23 and higher), which is composed of the |
| <code>READ_PHONE_STATE</code>, <code>CALL_PHONE</code>, |
| <code>READ_CALL_LOG</code>, <code>WRITE_CALL_LOG</code>, |
| <code>ADD_VOICEMAIL</code>, <code>USE_SIP</code>, and |
| <code>PROCESS_OUTGOING_CALLS</code> permissions, and |
| all their associated methods. |
| </p> |
| |
| <div class="wrap"> |
| <img src="{@docRoot}images/training/articles/user-data-overview-permissions-flow02.png"> |
| </div> |
| |
| <p> |
| 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. |
| </p> |
| |
| <ol> |
| <li>API Call →</li> |
| <li stydle="margin-left:.5em;">Triggers a specific <em>Permission Group</em> access |
| request →</li> |
| <li stydle="margin-left:1em;">Successful request grants access to all permissions in |
| group (if auto-update |
| enabled) →</li> |
| <li stydle="margin-left:1.5em;">Each permission grants access to all APIs under that |
| permission</li> |
| </ol> |
| |
| <p> |
| As another example, let's assume your application uses one or more <a href= |
| "{@docRoot}reference/android/telephony/TelephonyManager.html"><code>TelephonyManager</code></a> |
| methods, such as: |
| </p> |
| |
| <pre class="prettyprint"> |
| TelephonyManager.getDeviceId() |
| TelephonyManager.getSubscriberId() |
| TelephonyManager.getSimSerialNumber() |
| TelephonyManager.getLine1Number() |
| TelephonyManager.getVoiceMailNumber() |
| </pre> |
| |
| <p> |
| To use these methods, the <code>READ_PHONE_STATE</code> permission must be |
| declared in the app's manifest, and the associated permission group, |
| <em>PHONE</em>, 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. |
| </p> |
| |
| <p>For a full mapping between permissions and their associated permission groups, |
| please refer to the appropriate version-specific documentation below:</p> |
| |
| <ul> |
| <!--<li> <a href="">pre-M Android OS versions</a>.</li> --> |
| <li> <a href="{@docRoot}guide/topics/security/permissions.html#perm-groups">Permission |
| groups, Android 6.0 Marshmallow (API level 23) and later</a>.</li> |
| </ul> |
| |
| |
| <h2 id="permission_requests_and_app_downloads">Permission Requests and App Downloads</h2> |
| |
| <div style="padding:.5em 2em;"> |
| <div style="border-left:4px solid #999;padding:0 1em;font-style:italic;"> |
| <p><em>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</em>...<span |
| style="font-size:.8em;color:#777"><sup><em><a |
| href="#references" style="color:#777;padding-left:.1em;">1</a></em></sup></span></p> |
| </div> |
| </div> |
| |
| <p> |
| 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. |
| </p> |
| |
| <p> |
| One study<span style="font-size:.8em;color:#777"><sup><em><a href= |
| "#references" style= |
| "color:#777;padding-left:.1em;">2</a></em></sup></span>, 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 <span style= |
| "font-size:.8em;color:#777"><sup><em><a href="#references" style= |
| "color:#777;padding-left:.1em;">3</a></em></sup></span> showed that users are 1.7 |
| times more likely, on average, to select the application with fewer |
| permission requests. |
| </p> |
| |
| <p> |
| 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). |
| </p> |
| |
| <div class="wrap"> |
| <div class="cols"> |
| <div class="col-16of16"> |
| <img src="{@docRoot}images/training/articles/user-data-overview-permissions-groups.png"> |
| <p class="figure-caption"><strong>Figure 1.</strong> Distribution of |
| permission groups use across Arcade Games category.</p> |
| </div> |
| </div> |
| </div> |
| |
| <p> |
| 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 <em>Phone</em> permission group. As a result, they |
| may install a similar app in that category that avoids those |
| requests.<span style="font-size:.8em;color:#777"><sup><em><a href= |
| "#references" style="color:#777;padding-left:.1em;">4</a></em></sup></span> |
| </p> |
| |
| |
| <h2 id="permission_requests_trend_downward">Permission Requests Trend Downward</h2> |
| |
| <p> |
| 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. |
| </p> |
| |
| <div class="wrap"> |
| <div class="cols"> |
| <div class="col-16of16"> |
| <img src="{@docRoot}images/training/articles/user-data-overview-permissions-usage.jpg"> |
| <p class="figure-caption"><strong>Figure 2.</strong> Developer usage of popular |
| permissions has decreased over time.</p> |
| </div> |
| </div> |
| </div> |
| |
| <p> |
| The graph in <em>Figure 2</em> 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 |
| (<code>READ_PHONE_STATE</code>, <code>ACCESS_FINE_LOCATION</code>, and |
| <code>ACCESS_COARSE_LOCATION</code>). These results indicate that developers |
| are reducing the permissions their apps request in response to user behavior. |
| </p> |
| |
| <p> |
| 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 <a href= |
| "{@docRoot}training/articles/user-data-permissions.html">Best Practices for |
| Application Permissions</a>. |
| </p> |
| |
| |
| <h2 id="references">References</h2> |
| |
| <p>[1] Developer quote on StackOverflow. <em>(<a |
| href="http://stackoverflow.com/questions/24374701/alternative-to-read-phone-state-permission-for-getting-notified-of-call">source</a>)</em></p> |
| <p>[2] <em>Using Personal Examples to Improve Risk Communication for Security and Privacy Decisions</em>, by M. Harbach, M. Hettig, S. Weber, and M. Smith. In Proceedings of ACM CHI 2014.</p> |
| <p>[3] <em>Modeling Users’ Mobile App Privacy Preferences: Restoring Usability in a Sea of Permission Settings</em>, by J. Lin B. Liu, N. Sadeh and J. Hong. In Proceedings of SOUPS 2014.</p> |
| <p>[4] <em>Teens and Mobile Apps Privacy. (<a href="http://www.pewinternet.org/files/old-media/Files/Reports/2013/PIP_Teens%20and%20Mobile%20Apps%20Privacy.pdf">source</a>)</em></p> |