Microphones, cameras, location providers and text messaging services can access the user's personal data or cost the user money, so they are considered sensitive devices. Windows Store apps have features to ensure the user has control over which apps may access these sensitive devices. This topic describes guidelines for designing Windows Store apps to account for how a user may enable and disable device access.
How the user controls the app's use of sensitive devices.
Permissions for Windows Store apps to use sensitive devices are controlled on a per-app, per-user level. The user controls permissions using the consent prompt, or by using the Settings charm
The consent prompt
The following screen shot shows the consent prompt as it appears in a Windows Store apps. The prompt appears the first time an app accesses a sensitive device. It gives the user options to block or allow the app's access to the device capability. Windows remembers the response, so that the user is not prompted again for the same application.
The Settings charm
Users of Windows 8 can also control each app's access to sensitive devices by using the Settings charm. The user taps on the Settings charm to open a settings flyout. They can then enable or disable the app's access to sensitive device capabilities.
The Settings charm is pictured here on the right side of the app:
The Settings charm provides flyouts that let the user enable or disable sensitive capabilities. An example of a flyout is shown here:
Start using the device only if it's needed
The first API call that accesses the device will trigger the consent prompt. If an app's primary purpose does not require access to a sensitive device, it can be confusing to the user if a prompt for permission to use the device appears as soon as the app starts. Follow these guidelines for a good user experience.
| Guideline | Example |
|---|---|
|
If use of the sensitive device is not essential to your app, don't access it until the user specifically requests it. |
A social networking app has buttons for "Check in with my location" and "Take a profile picture". This app should not access location or the camera until the user clicks the corresponding button. |
|
If an app requires device access for its main function, then it can access the device when the app starts. |
An app for capturing live videos from an attached camera requires the camera for its main purpose. It's OK for this app to use the camera when it starts, to show a video preview right away. |
See the Reference section for more info on the API calls that trigger a consent prompt.
First use of the device must be on the main UI thread
The first call to start using the device must be made on the UI thread so that the consent prompt can be shown to the user. If the consent prompt can’t be shown, the user can’t grant device access to the app.
To make sure you first access the device on the UI thread do the following:
- Don't use a background task for the first use of the device.
- In an app using JavaScript, the first use of the object that accesses the device should not be in the activation handler for the app.
- In an app using C# or C++ with XAML, the first use of the object that accesses the device should typically be done in MainPage.xaml.cs instead of App.xaml.cs.
Note In apps that use C# or C++ in Windows 8 Release Preview, also note that the first use of the device object should be on the STA thread. Calls from an MTA thread may result in an error code of E_ILLEGAL_METHOD_CALL.
What if access to a device is turned off?
An app's access to a sensitive device may be disabled for one of these reasons:
- The user blocked access by using the consent prompt.
- The user disabled access to the device in the Settings charm.
- The device is not present on the system.
To provide a good user experience when access is disabled, do the following:
- Handle the error from the API that occurs when your app attempts to access a disabled device capability. The Reference section of this topic provides more information on the method calls that may return errors that indicate that the app doesn't have access to a device.
- Display a message to the user that informs them that the device capability is disabled, and tells them how they can re-enable it by using the Settings charm and trying again to use the capability in the app. Follow the Guidelines for notifying the user to provide this message.
- Provide UI for the user to re-initiate access to the device if the device is re-enabled. Reinstantiate or reinitialize the object that accesses the device by using this UI. For example, a mapping app may provide a button for refreshing the current location. The button must instantiate a new Geolocator object.
Guidelines for notifying the user of device revocation
The following guidance describes how apps should react when a user revokes a sensitive capability. The purpose of this guidance is to properly notify the user of loss of functionality, and guide them towards turning a capability back on without taking away from the app's experience.
Your app should tell the user that the capability is turned off, and that they can enable the capability by using the app's settings.
| Reason the device is disabled | Sample error message format |
|---|---|
|
The user blocked access using the consent prompt or the Settings charm. |
"Your <device capability> is currently turned off. To change your <device capability> setting, open the settings charm and tap permissions. Then <enable action> to start using <device capability> again. ”
|
|
The device capability isn't present on the system. |
“You do not have the required <device capability> present on your system.” |
The UI you use to present the message about a disabled device capability depends on whether the device capability is essential to the app. The following examples show how to display device capability messages.
Display a flyout or inline text if the device is non-essential
If the sensitive device is not essential to your app, display the message in a flyout at the point of invocation, or in unobtrusive inline text.
For example, if a mapping app has a button for showing the current location, and the user clicks the button when the required device capability is disabled, the app should show the error message in a flyout near the button, or in inline text.
The following screen shot shows an app that displays the message in flyout. The message reads: "Your location cannot be found. Change your permissions in Settings to allow Maps to access your location. Then restart the app."
Display a dialog if the device capability is essential
If an app requires device access for its main function, it displays the error message.
In the screen shot that follows, the Camera app requires access to the webcam and microphone capabilities for its main function, so it displays a message instructing the user to enable the camera capability.
Other guidelines for revocation messages
Here are some more guidelines for informing the user that a device capability is disabled:
- Notify the user of an unavailable capability if the user attempts to use a device capability that's not essential to the app. The user should be aware of the loss of functionality.
- Make the device revocation message clearly visible to the user.
- Use a flyout when a capability is not available, a control to use the capability is provided, and the capability is not essential to app functionality.
- Don't let the text interrupt the app's flow.
- Don't use notifications to notify the user of device capability unavailability.
- Don't programmatically try to launch the Permissions page in the Settings charm
- Don't show an error message for a device capability that has not yet been requested by the user. For example, if a social networking site has an option to include location when the user posts messages, but the user has not chosen to share location, don't show an error message when posting messages.
Reference
This table lists API info for disabling and reenabling sensitive device capabilities.
| Capability | Info on enable and disable |
|---|---|
| Location |
Either the GetGeopositionAsync method or an event handler for the PositionChanged event will trigger a consent prompt. See the Guidelines for location-aware apps for more info on how to handle user disable and re-enable of location in your app.See Detecting geolocation for tutorials. |
| Webcam or Microphone |
Apps that use Windows.Media.Capture.CameraCaptureUI.CaptureFileAsync to capture photos or videos from a camera should note the following:
Apps that use Windows.Media.Capture.MediaCapture to preview or capture audio, video, or photos should address the following issues:
See Adding Multimedia to your app for tutorials on using Windows.Media.Capture. Apps that use the IAudioClient2 interface should note that a call to ActivateAudioInterfaceAsync will trigger a consent prompt. |
| Text Messaging |
In apps that use the Windows.Devices.Sms API, operations to send or receive text messages fail with E_ACCESS_DENIED if the user revokes access. Note This functionality in the Windows.Devices.Sms API is only available to mobile operator apps and Windows Store apps given privileged access by mobile network operators. For more information see http://msdn.microsoft.com/en-us/library/windows/hardware/hh852368.aspx. |
Related topics
Build date: 10/30/2012
