Requesting permissions on Wear OS is similar to requesting permissions on mobile, with a couple of additional use cases. This document assumes you understand how Android permissions work. If you don’t, review how permissions work on Android.
Just as they do in a mobile app, a user must grant permissions to a Wear app for access to certain functionality. Wear apps should provide meaningful functionality without requesting any permissions.
Note: A Wear app can't assume permissions granted in a phone app. For example, if a user grants a phone app the permission to use location data, the user must also grant the Wear app the same permission.
Permission scenarios
There are several scenarios you may encounter when requesting dangerous permissions on Wear OS:
- The Wear app requests wearable permission; that is, it requests the permission on itself.
- The Wear app requests permissions for an app running on the phone.
- The phone app requests permissions for an app running on the wearable device.
To see all these scenarios in a working app, review the RuntimePermissionsWear sample.
The following sections explain each of these scenarios. For more detailed information about requesting permissions, see Permission-request patterns.
Wear app requests wearable permission
When the Wear app requests a permission for an app running on the wearable device, the system displays a dialog to prompt the user for that permission. Your app should request permissions only when it’s clear why the permissions are needed to perform a given operation.
Review the permission principles to make
sure you are providing the best experience for your users, and remember to check
shouldShowRequestPermissionRationale() and
provide additional information if needed.
If an app or watch face requires more than one permission at a time, permission requests appear one after the other.
Figure 1. Permission screens appearing in succession.
Note: Wear OS automatically syncs Calendar, Contact, and Location data to the Wear device. This scenario is applicable when Wear requests this data.
Wear app requests phone permission
When the Wear app requests a phone permission—for example, a wearable app wants access to photos or other sensitive data on the mobile version of the app—the Wear app must send the user to the phone to accept the permission. There, the phone app can provide additional information to the user using an activity. The activity should include two buttons: one for granting, and one for denying, the permission.
Figure 2. Send the user to the phone to grant permission.
Phone app requests wearable permission
If the user is in a phone app and the app requires a wearable permission—for example, to preload
music in case the phone gets disconnected—the phone app must send the user to the wearable device to
accept the permission. The wearable version of the app uses the
requestPermissions() method to trigger the system permissions dialog.
Figure 3. Send the user to the wearable to grant permission.
Permission-request patterns
There are different patterns for requesting permissions from users. In order of priority, they are:
- Ask in context when the permission is obviously necessary for a specific functionality, but isn't necessary for the app to run at all.
- Educate in context when the reason for requesting the permission isn't obvious, and the permission isn't necessary for the app to run at all.
Ask in context
Your app should request permissions when it’s clear why they are needed in order to perform a given operation. Users are more likely to grant a permission when they understand its connection to the feature they want to use.
For example, an app may require a user’s location in order to show nearby places of interest. When the user taps to search for nearby places, the app can immediately request the location permission, because there is a clear relationship between searching for nearby places and the need for the location permission. The obviousness of this relationship makes it unnecessary for the app to display additional education screens.
Figure 4. Ask for a permission in context.
Educate in context
Figure 5 shows an example of in-context education. The app doesn't require permissions in order to start the timer, but an inline educational cue shows that part of the activity (location detection) is locked. When the user taps the cue, a permission-request screen appears, allowing the user to unlock location-detection.
Use the
shouldShowRequestPermissionRationale() method to help your app decide whether to provide
more information. For additional details, see
Request permissions.
Figure 5. Educate in context.
Handle rejection
If a user denies a requested permission that isn't critical to an intended activity, don't block them from continuing the activity. If certain parts of the activity are disabled by the denied permission, provide visual, actionable feedback.
Figure 6 shows the use of a lock icon to indicate that a feature is locked because the user didn't grant permission to use it.
Figure 6. Lock icon, showing a feature is locked because of denied permission.
When a previously denied wearable permission dialog appears a second time, it includes a Deny, don't show again option. If the user chooses this option, then the only way for them to allow this permission in the future is to go into the wearable's Settings app.
Figure 7. Offer to stop showing the permission-request screen.
Learn more about how to handle permission denial.
Permissions for services
Only an activity can call the
requestPermissions() method, so if the user interacts with your app using a service, for
example through a watch face, the service must open an activity before requesting the permission.
This activity should provide additional education on why the permission is needed.
Generally, you shouldn't request permissions for a watch face. Instead implement a complication and let the user choose which data to display through the complication.
Settings
A user can change a Wear app’s permissions in Settings at any time. When the user tries to do
something that requires a permission, the app should always first call the
checkSelfPermission() method to see if the app currently has permission to perform this
operation.
The app should perform this check even if it knows the user has previously granted that permission, because the user may have subsequently revoked that permission.
Figure 8. Change settings using the Settings app.