CaptureDeviceConfiguration.RequestDeviceAccess Method
[ This article is for Windows Phone 8 developers. If you’re developing for Windows 10, see the latest documentation. ]
Requests access for all possible capture devices (audio or video) that are available on the client system.
Assembly: System.Windows (in System.Windows.dll)
Return Value
Type: System.Booleantrue if the user grants device access based on their response to the access request dialog prompt, or if the request is automatically granted in some circumstances. false if the user does not grant access or if the request is denied by other factors. See Remarks.
Client user permission to access the captures from available devices is scoped by sites in domains, and must be enabled by calls to RequestDeviceAccess and a resulting affirmation in the request access dialog by the user. Calls must be made separately for each session and must be requested again if a session ends and a new session begins. The Windows Phone configuration dialog enables setting which device (if any) is reported as the default to all enabled sites, but requesting user permission is a separate dialog that your application potentially invokes through the RequestDeviceAccess call.
Calling RequestDeviceAccess should be done from the context of a user-initiated event. If a call is made that is not from a user-initiated context, no exception is thrown. However, the dialog is not displayed in this case. The RequestDeviceAccess return value will still return results of any previously granted access request or other condition in this case, but otherwise the call is a no-op.
So long as the call is made from a user-initiated context, calling RequestDeviceAccess potentially blocks the Windows Phone UI thread, because it often presents an end user modal dialog in Windows Phone to the client user and that dialog runs on the UI thread.
You must have user-affirmed permission for this session / domain if you call capture-related APIs that carry or generate specific capture information (for example, CaptureSource.Start). Lack of user permission causes the called API to error or throw an exception (InvalidOperationException or possibly others).
An affirmation in the Windows Phone request access dialog enables both audio and video capture. There is no feature available for enabling audio but not video, or vice versa.
The following additional consideration affects the behavior of RequestDeviceAccess and whether the request access dialog box displays to a client user at run time:
If the client is the Windows Phone developer runtime, the request access dialog box never displays; access is considered granted for all sites and RequestDeviceAccess returns true.