@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).

@alejandrohcruz said in Android 12: https://developer.android.com/about/versions/12/non-sdk-12 For new android versions, we always run the library through tests, to make sure the library is compatible. At a quick glance, I only see one method we use that will be blocked (factoryReset). While it'd be nice to keep that method, I don't think it's a huge loss (and I was never sure it really made any difference than just turning the ble radio off/on).

@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?

No, it's not supposed to fire that much. Looks like you found a bug, thanks for pointing it out. We'll make sure to get this fixed for the next release.

Managed it to make it work. What you need is the application id, not the package name. Very confusing.

To be honest, it's been a while since I've dug deep into the numbers for connection interval. I would think 100ms would be good, just make sure to test like crazy :).

@caeduk interesting, I didn't know that you can do that if you scan without filters. We can probably look into their source code and find more hints i.e. see under which conditions they trigger that notification to ask the user if they want to debug the connection