If the latest SweetBLUE already support to write to and be notified from a single characteristic, please notice it. I think that the latest android bluetooth framework still have the following issues, and I expect that SweetBLUE can avoid it. Writing and notifying from the same characteristic Generally there is no such issue but you shouldn't do it if you intend to communicate with an Android phone since there is a race condition in the API itself So I would definitely recommend you to have two characteristics. How could I achieve maximum thread safety with a read/write BLE Gatt Characteristic? This change allows us to force all calls to BluetoothGattCharacteristic.setValue() - both for our outbound writing to the characteristic and the inbound notifications - onto the same thread, which eliminates the race condition corrupting the BluetoothGattCharacteristic.mValue;

@ryanbis Would you please tell me how is the progress of support Android 12? I think it will come soon...

If you're not setting a custom BondFilter, then something else is going on. The connection bug fix should only happen if you set a custom BondFilter, the DefaultBondFilter doesn't run the connection bug fix. @teruyama said in ConnectionBugHack: The customBondFilter is not set. I have set autoBondFixes to false. Since the target device uses passkey authentication, I don't want it to unbond every time it is disconnected. I am using the following code to bond, connect and it happens every time on Google Pixel3 and other smartphones. I assume you are referring to the bondFilter field in BleDeviceConfig/BleManageConfig as there is no customBondFilter field. Are you seeing device get unbonded when you disconnect? This shouldn't happen in normal circumstances. As far as not re-bonding, I wish you well. There are some devices (many Sony, and Motorola devices) that don't handle bond credentials very well. I'm hoping for you sake that they handle it better when a pin code is required. Have you changed any settings in BleDeviceConfig/BleManagerConfig? If so, please post what they are.

If you're just talking about BLE notifications, then yes you can get notifications in the background. Not sure what you're referring to with notification services. If you're talking about android notifications, that's not handled by SweetBlue, you would have to implement those in the callback for the BLE notifications.

It's something that is on our radar, however we have no timetable for when that will happen. Just wanted to post here to let you know we are aware of it.

@hayashi Due to the way Azure Artifacts works, we were forced to create a new feed. See https://forum.sweetblue.io/topic/152/new-maven-server for the new URL (basically, just tack a 3 onto the second sweetblue in the url).

@ryanbis the fix to this connection loop went out with 3.2.3 right? I had implemented the methods in DefaultReconnectionFilter , to workaround the issue described here https://forum.sweetblue.io/topic/12/explicit-disconnect-triggers-automatic-reconnect/15 Now the workaround fails. How do we simply tell Sweetblue -- hey, disconnect now and do not retry to connect until we call connect() again?

Thanks a lot for the fixes and documentation! @ryanbis

@ryanbis Ah! Alright, everything's clear now. That was the confusion

@blawlor Funny enough, I'm seeing this behavior despite using a foreground service to scan. So in theory I shouldn't need the background location permission. Have you seen something like that too?

@ryanbis Perfect! Thanks a lot. This is great.

@alejandrohcruz Set autoBondFixes to false.

You're right, thanks for pointing that out. It's been fixed now.

Issue solved... make sure to add Java 8 compatibility to project. compileOptions { sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8 }

Thanks for getting back with me. It appears I get the same results using the Toolbox app, but did notice something interesting. My flow using Toolbox app after having connected to two devices Turn device 1 on. Wait for button to turn green and say "Disconnect". Usually takes about 5-10 seconds I'm able to get notify values Turn device off. Wait for button to turn white and say "Connect" ========= Turn device 2 on. Wait for button to turn green and say "Disconnect". Usually takes about 5-10 seconds. I'm able to get notify values Turn device off. Wait for button to turn white and say "Connect" This is pretty consistent. I can do this multiple times with the same result, but sometimes when I turn a device on, it's button will not turn green even after waiting for over a minute. But as soon as I turn on another device (two devices are now on), both devices will connect and buttons will turn green. When a third device is added, the only way I can get a device to connect and turn green, is to turn on another device too. This is pretty consistent with results I'm seeing with Sweetblue in our app. We try to connect to devices use a ReconnectFilter val deviceReconnectFilter = object : DeviceReconnectFilter { override fun onConnectFailed(connectFailEvent: DeviceReconnectFilter.ConnectFailEvent): ConnectFailPlease { return ConnectFailPlease.retry() } override fun onConnectionLost(connectionLostEvent: ConnectionLostEvent): ConnectionLostPlease { return ConnectionLostPlease.retryIn(Interval.secs(3.0) ) } } So our app is continuously trying to connect to devices it knows about. When device is turned on ConnectionEvent is triggered and we start getting data. When the device is turned off, onConnectionLost is fired and we start continuously trying to reconnect. Is there another way we should be trying to handle continuously being connected to a device?