Describe the bug When calling the notifyCharacteristic, the onCharacteristicChanged never firing. I am getting a value for the read. And I have checked that the device indeed does support notifications using the LightBlue Application on IOS.

To Reproduce Steps to reproduce the behavior:

1. Connect to the device using blueFalcon.connect(bluetoothPeripheral, true)
2. Wait until didDiscoverServices Returns
3. Search through service to find the characteristic I want to nofify4.
4. Call notifyCharacteristic on the returned characteristic

char = service.characteristics.first { it.name == TESS5600_DATA_CHAR.lowercase() } bluetoothService.characteristicDelegate = this bluetoothService.notifyCharacteristic(bluetoothPeripheral, char!!, true)

Expected behavior Expecting the onCharacteristicChanged to fire

Smartphone

• Device: Samsung Tablet
• OS: Android API 31

There is no a working solution to use Windows Bluetooth Api in Java/Kotlin desktop app. The only was is to switch to Linux or to C# Is it possible to port windows to use in kotlin somehow? Do you mind to schedule such feature?

When requesting a change of the MTU, the peripheral returned by the callback does not contain services and characteristics. Yet, if you keep a reference of previous characteristics, one cannot write or read on it anymore.

The problem seems to lie in the fact that the MTU change request should appear between the connection and the discovery of services. Yet BlueFalcon abstracts this layer by calling directly the discovery of services as soon as the peripheral is connected.

It could be interesting to add an MTU request within the connect method for instance.

Expected For creating a connection, I am using method connect() with autoConnect flag set to true. This is setup once and it is expected that after setting up this "autoConnect", there is no other action required and Android OS BLE stack will notify the app, once remote device becomes available, and this call will never time out.

Actual Sometimes, I can reproduce following behavior: App is capable of connecting to device, but when app attempts to write bytes, it results in following exception: "BluetoothGatt: android.os.DeadObjectException"

To Reproduce Steps to reproduce the behavior:

1. call connect method with autoConnect flag set to true
2. Wait a few hours
3. After reconnection, writing to device will always result in "BluetoothGatt: android.os.DeadObjectException"

Note: Even restarting the BT module will not solve the issue. What will solve the issue is reinitialising BlueFalcon library.

Smartphone (please complete the following information):

• Device: [Samsung Galaxy A5]
• OS: [Android 7]
• BlueFalcon version: [0.7.2]

Hi, during more stress test of my app, i've discovered that Android device after some time causes peripheral to stop accept connections and stops from being visible in ble scan. This is not a case for iOS. Steps to reproduce:

0. Transport type LE
1. Start LE scan if peripheral MAC found, connect
2. If onConnected emited, stop LE scan
3. acquire all characteristics (setup notifications etc)
4. wait a little time
5. disconnect
6. wait a little time
7. repeat from point 1

After few loops, you will not be able to find peripheral MAC. Reseting peripheral or Android BT restores connectivity, removing Initializing BlueFalcon again also solves this issue. As far as i can tell, the GATT connection is held and this causes to reach maximum available connections. Good peripheral to test is Raspberry PI 3b+ with simple code using bluez.

Issue created with #45 fix. After disconnect by calling disconnect method and reconnect again with device within same BlueFalcon instance, we won’t be able to write to gatt characteristic.

It is because when we close the gatt connection in disconnect method, the method onConnectionStateChange from BluetoothGattCallback will never be called and as a result removeGatt method won’t be called. Thus the item in the Gatt list is not removed. In such cases when trying to write a characteristic we take an old object which is not currently connected to the device.

In my opinion there are two solutions add additional call of removeGatt in disconnect method moving close() method from disconnect to onConnectionStateChange in BluetoothGattCallback so gatt will be closed after remove.

First solution should work properly but it is not that clean and neat. Second is better but You need to check if moving close method won’t be an issue in disconnect scenarios and in that case You need to remove delegates.forEach { it.didDisconnect(bluetoothPeripheral) } from disconnect method to avoid calling it twice. This solution need to be tested very carefully.