1 page.title=Permissions and User Data 2 page.metaDescription=An overview of permissions on Android and how to manage them. 3 page.tags="user data","permissions","identifiers" 4 page.image=images/cards/card-user_2x.png 5 6 page.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 123 request </li> 124 <li stydle="margin-left:1em;">Successful request grants access to all permissions in 125 group (if auto-update 126 enabled) </li> 127 <li stydle="margin-left:1.5em;">Each permission grants access to all APIs under that 128 permission</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"> 138 TelephonyManager.getDeviceId() 139 TelephonyManager.getSubscriberId() 140 TelephonyManager.getSimSerialNumber() 141 TelephonyManager.getLine1Number() 142 TelephonyManager.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, 155 please 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 169 media player when there's a call, and to resume playback when the call is over. 170 The permission seems to scare a lot of people</em>...<span 171 style="font-size:.8em;color:#777"><sup><em><a 172 href="#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
