Windows Dev Center

Guidelines for devices that access personal data

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.


Permissions for Windows Store apps to use sensitive devices are controlled on a per-app, per-user level. Users control permissions using the consent prompt, or by using the Settings charm. The following images show the UI associated with consent prompts and the Permissions section of the Settings pane.

The consent prompt

Here's the consent prompt in a Windows Store app. The prompt appears the first time an app tries to access 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 the user isn't prompted again for the same app.

Consent prompt in a Windows Store app

The Settings charm

Each app's access to sensitive devices can also be set using the Settings charm. The user taps on the Settings charm to open the Settings pane (SettingsPane). The Settings charm is pictured here on the right side of the app:

Settings charm

Windows provide the Permissions flyout by default for all Windows Store apps. When users click Permissions from the Setting pane, the Permissions flyout appears and they can then enable or disable the app's access to sensitive device capabilities. Here is the Permissions flyout from a weather app:

Settings flyout that provides app location settings


  • The first call to start using a sensitive device must be made on the main UI thread so the consent prompt can be shown to the user. The user won't be able to grant device access to the app unless the consent prompt is shown. Ensure that:
    • You app doesn't use a background task for the first use of the device.
    • Your app using JavaScript and HTML doesn't first use the object that accesses the device in the activation handler for the app.
    • Your app using C#/VB/C++ and XAML first uses the object that accesses the device in MainPage.xaml.cs, not App.xaml.cs.
  • If use of the sensitive device is not essential for all tasks in your app, don't access it until the user wants to complete a task that requires it. For example, a social networking app with buttons for "Check in with my location" and "Take a profile picture" shouldn't access location or the camera until the user clicks the corresponding button.
  • If your app requires sensitive device access for its primary function, access the device when the app starts. For example, an app that captures live videos requires the camera for its main purpose. In this case, it's appropriate to immediately request device access.
  • Don't programmatically launch the Permissions page in the Settings pane.

If access to a device is turned off

There are three ways access to a device can be disabled: if a user denies consent when prompted, if a user blocks access in the Permissions flyout in the Setting pane, or if the device is not present in the system. Follow these recommendations if your app can't access a sensitive device:

  • Notify users of an unavailable device capability when they attempt to use it. The user should be aware of the loss of functionality.
  • Make the disabled device notification clearly visible to the user.
  • Use a flyout or inline message to notify the user if the capability is not essential to the app's primary function.
  • Handle the error from the API that will occur 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 users that informs them that the device capability is disabled, and tells them how they can re-enable it from the Permissions flyout in the Settings pane. For examples of how to notify a user of a disabled device, see Additional usage guidance.
  • 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.
  • Don't use notifications to inform the user of an unavailable device capability.
  • 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.

Additional usage guidance

Sample error messages

Reason the device is disabledSample 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. ”

  • Replace <device capability> with webcam, microphone, location, or text messaging.
  • Replace <enable action> with the action the user needs to take in the UI to reinitialize access the capability, like clicking a button.

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.

Displaying 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 an error 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."

Consent prompt in a Windows Store app

Displaying a dialog if the device capability is essential

If an app requires device access for its main function, display an error message using a MessageDialog. For a full sample, see Message dialog sample.

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.

Message to user that location should be enabled


This table lists API info for disabling and reenabling sensitive device capabilities.

CapabilityInfo on enable and disable

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 (Windows Store apps using JavaScript and HTML) or Detecting geolocation (Windows Store apps using C#/VB/C++ and XAML) for step-by-step guidance and code examples.

Webcam or Microphone

Apps that use Windows.Media.Capture.CameraCaptureUI.CaptureFileAsync to capture photos or videos from a camera should note the following:

  • Calling Windows.Media.Capture.CameraCaptureUI.CaptureFileAsync triggers a consent prompt the first time the app is run. Windows.Media.Capture.CameraCaptureUI.CaptureFileAsync does not return an error if the webcam capability is turned off. Instead, the Camera Capture UI displays a message that indicates that the webcam capability is turned off.

Apps that use Windows.Media.Capture.MediaCapture to preview or capture audio, video, or photos should address the following issues:

  • The error handlers for the asynchronous methods of MediaCapture receive an E_ACCESSDENIED error if the user did not grant permission, and HRESULT_FROM_WIN32(ERROR_FILE_HANDLE_REVOKED), if permission is revoked.
  • Call InitializeAsync again to access the camera, if the user re-enables access to the webcam after revoking it. For example, if the error handler for a HRESULT_FROM_WIN32(ERROR_FILE_HANDLE_REVOKED) error instructs the user to re-enable the webcam using the settings charm and then to tap a button to restart a video preview. The code behind the button should call InitializeAsync before making any other calls.

See Adding multimedia to your app (Windows Store apps using JavaScript and HTML) or Adding multimedia (Windows Store apps using C#/VB/C++ and XAML) for tutorials on using Windows.Media.Capture.

Apps using the IAudioClient2 interface should note that a call to ActivateAudioInterfaceAsync will trigger a consent prompt.


Related topics

For developers (XAML)
App capability declarations
How to manually specify device capabilities in a package manifest
Adding flyouts and menus
For developers (HTML)
App capability declarations
How to manually specify device capabilities in a package manifest
Quickstart: Adding a flyout
Message dialog sample



© 2015 Microsoft