GATT Connection State Change Detection

The standard Microsoft UWP GATT API has some problems with device connections management. When your application connects to a remote GATT-enabled device (peripheral), you cannot disconnect it from the server in an easy way. Sometimes a device remains connected even after you close your application. The Microsoft UWP GATT API does not provide a Disconnect method, and none of Microsoft's recommended solutions work. Also, when your application acts as a GATT server (peripheral), there is no event that can notify your application when a remote client is connected to and disconnected from your server. And this is the big problem.

Root Causes of the Disconnect Problem

The root of the disconnect problem lies in the architecture of the UWP Bluetooth API. When you connect to a GATT peripheral using BluetoothLEDevice, the system manages the connection internally. The API provides only a Dispose or Close method on the device object, but these merely release local resources and do not force the radio to terminate the link. Microsoft's intention was for the system to handle connection lifetime automatically, but in practice the peripheral can remain bound until a system-wide timeout or a power cycle. This causes severe issues: a device that stays connected invisibly will drain its battery, refuse new connections, and remain undiscoverable because advertising stops. Developers often resort to unpairing the device or restarting the Bluetooth adapter, which is unacceptable for a polished application.

Root Causes of the Server Connection Blindness

On the server side, the UWP GattServiceProvider allows you to create a GATT service and advertise it, but it exposes no connection-oriented events. The only way to infer that a client is present is to wait for characteristic subscriptions or read/write requests. This means you cannot perform a handshake or initialization when a central device first connects; you must lazily prepare data on first access, which complicates state management. Moreover, when the client disconnects, you receive no notification at all, leaving you unable to reclaim resources, reset internal state, or log the disconnection. If a client crashes or moves out of range, your server remains unaware, potentially serving stale data to a ghost connection.

Impact on GATT Client Applications

When your GATT client application finished its work with a peripheral device, it needs to disconnect. The disconnection is critical because most peripheral devices will not accept any new connections while there is an active one. Also, peripheral devices usually stop advertising when any active connection exists. So your or any other application is not able to find your peripheral device because WinRT API did not close the connection. You need to close your application and start again to release the device. And even closing the application may not work if the device is paired: the system may keep the device connected, and you need to unpair it.

Impact on GATT Server Applications

If your application is a GATT server (peripheral), you need to know when a remote client (central) is connected to and disconnected from your application. There are many reasons why you need it: your application may need to prepare data, to initialize internal state, and many other reasons. However, the standard Microsoft UWP GATT API does not provide any events to notify your application about a remote client connection state. You even cannot know when a client disconnected to do a cleanup.

Fortunately, the Bluetooth Framework library solves all the GATT connection problems. If your application is connected to a remote GATT-enabled device and, when it finishes all the communication and needs to disconnect, the Bluetooth Framework executes the real disconnection immediately. So now your peripheral device can be discovered and connected again. Also, the library can detect when a remote GATT server (peripheral) terminates connection for different reasons, even if it was turned off.

To test this feature, use the GattClient sample application from the Bluetooth Framework package.

The other problem is the connection state detection when your application runs as a GATT server. The standard Microsoft UWP GATT API can notify your application only when a client subscribes, unsubscribes, reads, or writes a characteristic. It is not very useful if your application needs a complex initialization when the client connects. Also, the client can subscribe to more than one characteristic and read or write a few times. And of course there is no event that can notify your application when a remote client disconnects. That makes it impossible to do a clean-up and makes client connection management too complex.

The Bluetooth Framework is able to do a real client connection detection. The library is able to detect when a client connects to the server without needing to subscribe, read, or write a characteristic. The notification is immediately sent to your application when a client connects and disconnects. Also, the library allows your application to disconnect any connected client.

To test this unique feature, use the GattServer sample application from the Bluetooth Framework package.

How It Works Under the Hood

For client disconnection, the library uses a combination of lower-level Windows Bluetooth interfaces and smart resource management to terminate the link at the radio level. This guarantees that the peripheral is immediately released, resumes advertising, and accepts new connections without delay. The disconnect operation is synchronous and verifies that the physical link is torn down before returning control to your application.

For GATT server connection detection, the Bluetooth Framework integrates with the native Bluetooth LE stack beneath the UWP layer. It listens to connection and disconnection events from the Bluetooth radio itself, correlating them with the local GATT service. This allows it to fire OnClientConnect and OnClientDisconnect events the moment a link is established or dropped, without waiting for any characteristic interaction. Your application receives the client's Bluetooth address and can immediately begin session-specific initialization, and you get a reliable disconnection notification even if the remote device powers off abruptly. Additionally, the framework enables the server to forcefully disconnect a misbehaving client, something impossible with the standard UWP provider.