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>