FAQs for USB, Bluetooth, and HID APIs (Windows Store apps)
In Windows 8.1, all developers can use the device protocol APIs to write Windows Store apps that communicate with USB, Human Interface Devices (HID), Bluetooth GATT, and Bluetooth RFCOMM peripheral devices. Here's some of the most frequently asked questions (FAQs) that people have when they start programming for USB, HID, or Bluetooth. For more info about the APIs that enable this, see Communicating with peripheral devices.
Yes, the user has full control over the app's device access. The first time the app attempts to access a device, the user is prompted with a message dialog that asks their permission to access the device. The text in the message dialog is based on name of the app and the friendly name of the device: "Can <app name> use your <friendly device name>?"
This message dialog works on a device model basis, not a per-device basis. So, if you plug in two identical devices and block access to the first one, the app will not prompt you about the second device, and assume that you want to block access to that device too.
If the user changes their mind later, they can block access to the device from the app's Permissions flyout. To open the Permissions flyout, tap the Settings charm, and then tap Permissions in the Settings pane. If the user turns off permissions to the device, they will not be asked again. If they ever want to let the app access the device in the future, they'll need to go back to the Permissions flyout and turn on permissions.
Users can change permissions for all devices in PC Settings. From PC Settings, tap Privacy to configure all device permissions.
Yes, the user can turn permissions on/off for individual devices as long as the Hardware ID of the devices are different.
Yes. Permissions will follow a USB device even if the device doesn't implement a serial number. It's not uncommon for USB and HID devices to not implement a serial number, so the Hardware ID is used to distinguish between devices. If two devices have the same Hardware ID, but different serial numbers, the permissions will follow the Hardware ID.
Will device permissions roam across PCs if the user is using the same app and device on multiple PCs?
No. Device permission settings to do not roam across PCs. This is similar to the current experience for webcams.
Yes, in the Windows Store, on the Details tab of the app description page, each app will list which permissions it needs. This list is based on the device capabilities declared in the app's package manifest file.
If the device is already installed on the user's PC: The Details tab will display the device manufacturer and model name.
If the device has never been installed on the user's PC: The details tab will display a generic string like "USB peripheral."
Tip When you submit your app to the Windows Store, include a list of supported devices in your app's description.
Yes, that is done in the DeviceCapability element of the app's package manifest file. The device capabilities for USB, HID, and Bluetooth, include XML child elements to specify the applicable device and function information. You can specify a specific VIN and PID for a given function or leave it open to any device that can perform that function.
- How to specify device capabilities for Bluetooth
- How to specify device capabilities for HID
- Updating the app manifest package for a USB device
If the user blocks your app from accessing a device, your app will receive an access denied error when it tries to access the device.
Yes. However, the Windows Store app that uses these APIs must be a privileged app that is explicitly declared in device metadata by the OEM for that PC. This is the case for any device that is integrated, non-removable, and inside the PC chassis. For more info about using device metadata with your device app, see Windows Store device apps for hardware partners.
Yes. A Windows Store app can communicate with an externally attached device over USB, Bluetooth, and HID as long as the following criteria are met:
Drivers: The device has loaded only the correct Microsoft-supplied driver (via INF or OS descriptors). For example, the WinUSB driver for the USB APIs.
Protocol knowledge: The developer must know the app-level protocol used by the device. A majority of these devices will have vendor specific protocols so the developer will have to work with the device manufacturer to understand the protocol. Device manufacturers who need an additional level of protection for their device integrate security chips in their device to ensure that only authenticated clients can access the device.
User consent: The user will need to allow the app to access to the device before the app can communicate with it.
The Windows Runtime will perform the following runtime checks to make sure that the device can be accessed with the APIs.
No filter drivers: The device must work with approved Microsoft-provided drivers (WinUSB or HID) and have no filter drivers. If filter drivers are present, access is limited to apps that are defined as privileged apps in device metadata.
Approved device types: These APIs are for use with custom peripherals; the device must comply with a known list or supported HID and USB devices that do not conflict with built-in operating system behavior. For example, the USB APIs and WinUSB driver cannot be used with a printer. Doing so would conflict with the printing experience that users expect from their printer.
No. These APIs are intended for communicating with custom peripheral devices from a Windows Store app. Windows Store apps are per-user apps and do not have the ability to make changes outside the scope of each app.
- Communicating with peripheral devices (Windows Store apps)
- Windows 8.1: new APIs and features
- Windows Store device apps for Microsoft hardware partners