270 lines
11 KiB
Plaintext
270 lines
11 KiB
Plaintext
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>
|