1page.title=Permissions and User Data
2page.metaDescription=An overview of permissions on Android and how to manage them.
3page.tags="user data","permissions","identifiers"
4page.image=images/cards/card-user_2x.png
5
6page.article=true
7@jd:body
8
9<div id="tb-wrapper">
10<div id="tb">
11    <h2>In this document</h2>
12    <ol>
13      <li><a href="#introduction">Introduction</a></li>
14      <li><a href="#permission_groups">Permission Groups</a></li>
15      <li><a href="#permission_requests_and_app_downloads">Permission
16      Requests and App Downloads</a></li>
17      <li><a href="#permission_requests_trend_downward">Permission Requests
18      Trend Downward</a></li>
19    </ol>
20    <h2>You should also read</h2>
21    <ol>
22      <li><a href="{@docRoot}guide/topics/security/permissions.html">System Permissions</a></li>
23      <li><a href="{@docRoot}training/permissions/index.html">Working with System
24      Permissions</a></li>
25    </ol>
26  </div>
27</div>
28
29<p>
30  Permissions protect sensitive information available from a device and should
31  only be used when access to information is necessary for the functioning of
32  your app.
33</p>
34
35<p>
36  This document provides a high-level overview on how permissions work in
37  Android so you can make better, more informed decisions about the permissions
38  you're requesting. The information in this document is not use-case specific
39  and avoids complex, low-level discussions of the underlying code.
40</p>
41
42<p>
43  For specific recommendations on how to manage permissions, please see
44  <a href="{@docRoot}training/articles/user-data-permissions.html">Best
45  Practices for App Permissions</a>. For best practices on using unique
46  identifiers on Android, please see <a href=
47  "{@docRoot}training/articles/user-data-ids.html">Best Practices for Unique
48  Identifiers</a>. For details on how to work with permissions in your code,
49  see <a href="{@docRoot}training/permissions/index.html">Working with System
50  Permissions</a>.
51</p>
52
53
54<h2 id="introduction">Introduction</h2>
55
56<p>
57  Every Android application must have a <em>manifest file</em> that presents
58  essential information about the app to the Android system. The Android system
59  also requires apps to request permission when they want to access sensitive
60  device or user information, and these requests must be documented in advance
61  as a part of your app's manifest. Moreover, accessing sensitive information
62  can affect user behavior, so it's important to make sure you are only making
63  permission requests when that information is necessary for the functioning of
64  your app.
65</p>
66
67
68<h2 id="permission_groups">Permission Groups</h2>
69
70<p>
71  Permissions in Android are organized into <code><a href=
72  "{@docRoot}guide/topics/security/permissions.html#perm-groups">permission
73  groups</a></code> that organize, and group, permissions related to a device's
74  capabilities or features. Under this system, permission requests are handled
75  at the group level and a <em><strong>single permission group</strong></em>
76  corresponds to <em><strong>several permission declarations</strong></em> in
77  the app manifest; for example, the SMS group includes both the
78  <code>READ_SMS</code> and the <code>RECEIVE_SMS</code> declarations.
79</p>
80
81
82<div class="wrap">
83   <img src="{@docRoot}images/training/articles/user-data-overview-permissions-flow01.jpg">
84</div>
85
86<p>
87  This arrangement is simpler and more informative for users; once an app is
88  granted permission to access the group, it can use API calls within that
89  group and users with auto-update enabled will not be asked for additional
90  permissions because they have already granted access to the group. Grouping
91  permissions in this way enables the user to make more meaningful and informed
92  choices, without being overwhelmed by complex and technical permission
93  requests.
94</p>
95
96<p>
97  This also means that when you request access to a particular API call or
98  query a content provider behind a permission, the user will be presented with
99  a request to grant permission for the whole group rather than the specific
100  API call. For example, if you request the <code>WRITE_CALL_LOG</code>
101  permission, the user will be asked to grant access to the <em>PHONE</em>
102  group (in API level 23 and higher), which is composed of the
103  <code>READ_PHONE_STATE</code>, <code>CALL_PHONE</code>,
104   <code>READ_CALL_LOG</code>, <code>WRITE_CALL_LOG</code>,
105  <code>ADD_VOICEMAIL</code>,  <code>USE_SIP</code>, and
106  <code>PROCESS_OUTGOING_CALLS</code> permissions, and
107  all their associated methods.
108</p>
109
110<div class="wrap">
111   <img src="{@docRoot}images/training/articles/user-data-overview-permissions-flow02.png">
112</div>
113
114<p>
115  One consequence of grouping permissions is that a single API call within your
116  app can have a multiplying effect in terms of the number of permissions
117  requested by your app.
118</p>
119
120<ol>
121<li>API Call →</li>
122<li stydle="margin-left:.5em;">Triggers a specific <em>Permission Group</em> access
123request →</li>
124<li stydle="margin-left:1em;">Successful request grants access to all permissions in
125group (if auto-update
126enabled) →</li>
127<li stydle="margin-left:1.5em;">Each permission grants access to all APIs under that
128permission</li>
129</ol>
130
131<p>
132  As another example, let's assume your application uses one or more <a href=
133  "{@docRoot}reference/android/telephony/TelephonyManager.html"><code>TelephonyManager</code></a>
134  methods, such as:
135</p>
136
137<pre class="prettyprint">
138TelephonyManager.getDeviceId()
139TelephonyManager.getSubscriberId()
140TelephonyManager.getSimSerialNumber()
141TelephonyManager.getLine1Number()
142TelephonyManager.getVoiceMailNumber()
143</pre>
144
145<p>
146  To use these methods, the <code>READ_PHONE_STATE</code> permission must be
147  declared in the app's manifest, and the associated permission group,
148  <em>PHONE</em>, will be surfaced to the user. This
149  is important, because it means the user will be asked to grant permission for
150  the relevant group and all its associated permissions and API calls, rather
151  than for the specific API call you're requesting.
152</p>
153
154<p>For a full mapping between permissions and their associated permission groups,
155please refer to the appropriate version-specific documentation below:</p>
156
157<ul>
158  <!--<li> <a href="">pre-M Android OS versions</a>.</li> -->
159  <li> <a href="{@docRoot}guide/topics/security/permissions.html#perm-groups">Permission
160  groups, Android 6.0 Marshmallow (API level 23) and later</a>.</li>
161</ul>
162
163
164<h2 id="permission_requests_and_app_downloads">Permission Requests and App Downloads</h2>
165
166<div style="padding:.5em 2em;">
167<div style="border-left:4px solid #999;padding:0 1em;font-style:italic;">
168<p><em>I'm currently using the READ_PHONE_STATE permission in Android to pause my
169media player when there's a call, and to resume playback when the call is over.
170The permission seems to scare a lot of people</em>...<span
171style="font-size:.8em;color:#777"><sup><em><a
172href="#references" style="color:#777;padding-left:.1em;">1</a></em></sup></span></p>
173</div>
174</div>
175
176<p>
177  Research shows that among apps that are otherwise identical (e.g.,
178  functionality, brand recognition), requesting fewer permissions leads to more
179  downloads. Publicly available sources exist that assign grades to apps based
180  on their permissions usage and allow users to compare related apps by score;
181  such grades exist for many of the current Android apps and users pay close
182  attention to the related rankings.
183</p>
184
185<p>
186  One study<span style="font-size:.8em;color:#777"><sup><em><a href=
187  "#references" style=
188  "color:#777;padding-left:.1em;">2</a></em></sup></span>, in which users
189  were shown two unbranded apps with similar ratings that had the same
190  functionality but different sets of permission requests, showed that users
191  were, on average, 3 times more likely to install the app with fewer
192  permissions requests. And a similar study <span style=
193  "font-size:.8em;color:#777"><sup><em><a href="#references" style=
194  "color:#777;padding-left:.1em;">3</a></em></sup></span> showed that users are 1.7
195  times more likely, on average, to select the application with fewer
196  permission requests.
197</p>
198
199<p>
200  Finally, permissions usage is not evenly distributed across apps within
201  a similar category of Play apps. For example, 39.3% of arcade game apps in
202  the Play store request no permissions that are surfaced to the user while
203  only 1.5% of arcade games request the Phone permission group (see Figure
204  1).
205</p>
206
207<div class="wrap">
208  <div class="cols">
209    <div class="col-16of16">
210   <img src="{@docRoot}images/training/articles/user-data-overview-permissions-groups.png">
211    <p class="figure-caption"><strong>Figure 1.</strong> Distribution of
212    permission groups use across Arcade Games category.</p>
213    </div>
214  </div>
215</div>
216
217<p>
218  Users comparing your app to other similar apps may determine that it is
219  making unusual permission requests for that category - in this case, Arcade
220  Games apps accessing the <em>Phone</em> permission group. As a result, they
221  may install a similar app in that category that avoids those
222  requests.<span style="font-size:.8em;color:#777"><sup><em><a href=
223  "#references" style="color:#777;padding-left:.1em;">4</a></em></sup></span>
224</p>
225
226
227<h2 id="permission_requests_trend_downward">Permission Requests Trend Downward</h2>
228
229<p>
230  A recent analysis of Play store apps over time indicated that many developers
231  trim permissions after first publishing their apps, suggesting that they may
232  be employing more caution around which permission groups they declare.
233</p>
234
235<div class="wrap">
236  <div class="cols">
237    <div class="col-16of16">
238   <img src="{@docRoot}images/training/articles/user-data-overview-permissions-usage.jpg">
239    <p class="figure-caption"><strong>Figure 2.</strong> Developer usage of popular
240    permissions has decreased over time.</p>
241    </div>
242  </div>
243</div>
244
245<p>
246  The graph in <em>Figure 2</em> illustrates this trend. There has been a
247  steady decrease in the average percentage of developers' apps requesting at
248  least one of the three most popular permissions in the Play store
249  (<code>READ_PHONE_STATE</code>, <code>ACCESS_FINE_LOCATION</code>, and
250  <code>ACCESS_COARSE_LOCATION</code>). These results indicate that developers
251  are reducing the permissions their apps request in response to user behavior.
252</p>
253
254<p>
255  The bottom line is that providing the same functionality to the user with
256  minimal access to sensitive information means more downloads for your app.
257  For specific recommendations on how to achieve this, please see <a href=
258  "{@docRoot}training/articles/user-data-permissions.html">Best Practices for
259  Application Permissions</a>.
260</p>
261
262
263<h2 id="references">References</h2>
264
265<p>[1] Developer quote on StackOverflow. <em>(<a
266    href="http://stackoverflow.com/questions/24374701/alternative-to-read-phone-state-permission-for-getting-notified-of-call">source</a>)</em></p>
267<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>
268<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>
269<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>
270