Compartilhar via

Supporting Bluetooth Devices (XAML)

  • Artigo

[This article is for Windows 8.x and Windows Phone 8.x developers writing Windows Runtime apps. If you’re developing for Windows 10, see the latest documentation]

Windows Runtime in Windows 8.1 provides several new Bluetooth namespaces:

Using these namespaces, developers can write a Windows Store app that talks to Bluetooth devices.

You must provide information about your device's capabilities in the declarations in the App Manifest. This allows an app to be associated with your device.

For more information, see How to specify device capabilities for Bluetooth.

RFComm

The Bluetooth RFComm APIs adhere to Windows Runtime guidelines, and provide the following features:

  • The API builds on existing patterns for Windows.Devices, including enumeration and instantiation.
  • SDP attributes have a value and an expected type. However, some common devices have faulty implementations of SDP attributes where the value is not of the expected type. Additionally, many usages of RFCOMM do not require additional SDP attributes at all. For these reasons, this API offers access to the unparsed SDP data, from which developers can obtain the information they need
  • Data reading and writing is designed to take advantage of established data stream patterns and objects in Windows.Storage.Streams.

The RFCOMM APIs use the concept of service identifiers. Although a service identifier is simply a 128-bit GUID, it is also commonly specified as either a 16- or 32-bit integer. The RFCOMM API offers a wrapper for service identifiers that allows them be specified and consumed as 128-bit GUIDs as well as 32-bit integers but does not offer 16-bit integers (to conform to Windows Runtime guidelines). This is not an issue for the API because languages will automatically upsize to a 32-bit integer and the identifier can still be correctly generated.

Starting in Windows 8.1, a Windows Store device apps can perform multi-step device operations in a background task so that they can run to completion even if the app is moved to the background and suspended. This allows for reliable device servicing such as changes to persistent settings or firmware, and content synchronization, without requiring the user to sit and watch a progress bar. Use the DeviceServicingTrigger for device servicing and the DeviceUseTrigger for content synchronization. Note that these background tasks constrain the amount of time the app can run in the background, and are not intended to allow indefinite operation or infinite synchronization. For more info, see Device sync and update (Windows Store apps).

For more information, see the following RFCOMM usage scenarios:

GATT

Developers can use the Bluetooth GATT APIs to access Bluetooth LE services, descriptors, and characteristics.

Bluetooth LE devices expose their functionality through a collection of:

  • Primary Services
  • Included Services
  • Characteristics
  • Descriptors

Primary services define the functional contract of the LE device and contain a collection of characteristics that define the service. Those characteristics, in turn, contain descriptors that describe the characteristics.

The Bluetooth GATT APIs expose objects and functions, rather than access to the raw transport. At the driver level primary services are enumerated as Child Device Nodes of the Bluetooth LE device using the enumeration API.

The Bluetooth GATT APIs also enable developers to work with Bluetooth LE devices with the ability to perform the following tasks:

  • Perform Service / Characteristic / Descriptor discovery
  • Read and Write Characteristic / Descriptor values
  • Register a callback for the Characteristic ValueChanged event

The Bluetooth GATT APIs simplify development by dealing with common properties and providing reasonable defaults to aid in device management and configuration. They provide a means for developers to access functionality of a Bluetooth LE device from a Windows Store App.

To create a useful implementation a developer has to have prior knowledge of the GATT services and characteristics the application intends to consume, and to process the specific characteristic values such that the binary data provided by the API is transformed into useful data before being presented to the user. The Bluetooth GATT APIs expose only the basic primitives required to communicate with a Bluetooth LE device. To interpret the data, an application profile must be defined, either by a Bluetooth SIG standard profile, or a custom profile implemented by a device vendor. A profile creates a binding contract between the application and the device, as to what the exchanged data represents and how to interpret it.

For convenience the Bluetooth SIG maintains a list of public profiles available.

For more information, see the following GATT usage scenarios: