Lines Matching full:permission
11 <li><a href="#scenarios">Permission Scenarios</a></li>
41 a user might grant a handset app permission to use location data, and subsequently
42 have to grant the same permission to the Wear version of the app.</p>
46 every permission an app may ever need. Instead, the app does not request permissions until it
57 <h2 id="scenarios">Permission Scenarios</h2>
72 <li>The wearable app uses a <em>different permission model</em> from its handset counterpart.
79 <h3 id="wear-app-wear-perm">Wear app requests permission for an app running on the wearable
82 <p>When the Wear app requests a permission for an app running on the wearable device, the system
83 displays a dialog to prompt the user for that permission. An app or service can only call the
87 a watch face, the service must open an activity before requesting the permission.</p>
92 you may choose to provide additional education before prompting for a permission.</p>
94 <p>If an app or watch face requires more than one permission at a time,
95 permission requests appear one after the other.</p>
100 alt="Multiple permission screens, one after another." width="700" height="" id="permission-flow" />
102 <strong>Figure 1.</strong> Permission screens appearing in succession.
109 <h3>Wear app requests handset permission</h3>
111 <p>When the Wear app requests a handset permission, the
112 Wear app must send the user to the handset to accept the permission. There, the handset app can
114 one for granting, and one for denying, the permission.</p>
119 alt="The Wear app sends the user to the handset to grant permission." width="700"
120 height="" id="permission-flow" />
122 <strong>Figure 2.</strong> Sending the user to the handset to grant permission.
124 <h3>Handset app requests wearable permission</h3>
126 <p>When the user is in a handset app and the app requires a wearable permission, the
127 handset app must send the user to the wearable to accept the permission.
135 alt="The handset app sends the user to the wearable to grant permission."
136 width="700" height="" id="permission-flow" />
138 <strong>Figure 3.</strong> Sending the user to the wearable to grant permission.
141 <h3>Mismatching permission models between wearable and handset app</h3>
151 <h2 id="requesting">Permission-Request Patterns</h2>
153 <p>There are different patterns for requesting permission from users. In order of
157 <li><a href="#aic">Ask in context</a> when the permission is obviously necessary for a specific
160 <li><a href="#eic">Educate in context</a> when the reason for requesting the permission is
161 not obvious, and the permission is not necessary for the app to run at all.</li>
163 <li><a href="#auf">Ask up front</a> when the need for the permission is obvious, and the
164 permission is required in order for the app to run at all.</li>
166 <li><a href="#euf">Educate up front</a> when the need for the permission is not obvious, but
167 the permission is required in order for the app to run at all.</li>
173 given operation. Users are more likely to grant a permission when they understand its connection to
178 immediately request the location permission, because there is a clear
180 permission. The obviousness of this relationship makes it unnecessary for the app to display
186 alt="The app requests permission when it's obviously necessary."
187 width="700" height="" id="permission-flow" />
194 for a permission. Again, your app should do this in context of a specific
195 action, if it?s unclear why your app needs access to the requested permission
200 activity (location detection) is locked. When the user taps the cue, a permission-request screen
214 alt="When the need for the permission arises, the app explains why the permission is necessary."
215 width="700" height="" id="permission-flow" />
221 <p>If your app clearly requires a permission in order to work at all, you can prompt for that
222 permission when the user launches the app. For example, a maps app clearly requires access
224 is necessary for this permission.</p>
229 alt="If the app obviously needs a permission to run at all, it can ask for it immediately on
231 width="700" height="" id="permission-flow" />
238 <p>In some cases, the app requires a permission for basic functionality, but the need for that
239 permission is not obvious. In these cases, when the user first
241 ask for the permission.</p>
246 alt="When requesting a permission on launch, the app can explain why it needs the permission."
247 width="700" height="" id="permission-flow" />
253 <p>If a user denies a requested permission that is not critical to an intended
255 the activity are disabled by the denied permission, provide visual, actionable
257 locked because the user did not grant permission to use it.</p>
262 alt="When the user denies permission, a lock icon is shown alongside the associated feature."
263 width="700" height="" id="permission-flow" />
265 <strong>Figure 8.</strong> Lock icon, showing a feature is locked because of denied permission.
267 <p>When a previously denied wearable permission dialog appears a second
269 chooses this option, then the only way for them to allow this permission in the
275 alt="The system offers to stop requesting permission."
276 width="700" height="" id="permission-flow" />
278 <strong>Figure 9.</strong> Offering not to show the permission-request screen anymore.
286 the permission. This activity could provide additional education, or it could simply
290 an app in which it might make sense to request a permission,
301 alt="The user may need to grant a permission when indirectly interacting with an app, via a
303 width="700" height="" id="permission-flow" />
305 <strong>Figure 10.</strong> A service requesting permission.
311 permission, the app should always first call the
313 method to see if the app currently has permission to perform this operation. The app should perform
314 this check even if it knows the user has previously granted that permission, since the
315 user might have subsequently revoked that permission.</p>
321 width="700" height="" id="permission-flow" />
