@AlejandroHCruz , I think the most bang for the buck you are going to get is adjusting the connection interval. You can try to set the connection priority via BleDevice.setConnectionPriority(). This only gives you LOW/MEDIUM/HIGH, so there's not much fine-tuning you can do (however, you can set whatever parameters you want in your firmware, given you have access to do that). I think most of the SweetBlue options will have a minor impact compared to adjusting the connection interval. You may want to consider also adjusting the autoUpdateRate to a higher value (increasing the time between update ticks). This will only really make a difference if there are a lot of devices you are working with, but you may want to run some tests to see what difference there really is. As for the slowest poll rate for the defaultStatePollRate, it's really how confident you are in the android callbacks working. The state poll is there because the callback isn't always called, hence the need for polling. I would say somewhere between .5 and 1 second should be good. Again, it's something you will have to test with your device (and several different phones for better coverage).

Thank you for your replies. It is interesting that you got different results than me. On my undersanding, turning off the Bluetooth adapter definitely terminates the connection and thus the device can be used again for further scanning/connection. I've been trying out a bunch of different things. Sometimes, when the device is stuck on this state, I am able to retrieve the device from the regular getDevice(String macAddress) method. And then I can establish a connection, verify the BONDED state, read the standard Device Information Service, and even enable some BleNotify. However, I am not able to negotiate the MTU as the operation fails with a REMOTE_GATT_FAILURE due to “no resources”. I'll activate autoNegotiateMtuOnReconnect and try again tomorrow, maybe you have some magic in there or I'm doing something wrong. Other than that, I think I'll use the getDevices_bonded() function, filter for the device, and unbond it. Then connect again. That seems to work on the Toolbox V3 app and does not retrigger a bonding notification for some reason.

Hi, I'm jumping back into this thread with more information and a couple of questions: The Nordic's nRF Connect app can detect when I connect the BLE peripheral on my own app and directly interact with it. Which is pretty cool. Also, when you open up their application and you click 'connect' on a bonded device that is already connected (using my own app), their app connects the services and is able to interact with the peripheral device. Q1: How could I achieve the behavior described by point #2? Either manually (user interaction required) or automatically? i.e. when I open up my app, it should detect bonded devices that are connected and enable them to be used right away by the user.

Undiscover will disconnect, but will not explicitly unbond.

@caeduk Please post a new topic with specific steps to reproduce the issue you're having so we can investigate it on our end.

I found your post here https://forum.sweetblue.io/topic/12/explicit-disconnect-triggers-automatic-reconnect and I was actually able to make it work, but it's tricky

@benp thanks a lot, will check it out!

@alejandrohcruz said in Bluetooth connections servered by the OS get the power back to SweetBlue: Are you enabling the autoConnect parameter? Also, from what I've seen, Android OS does not reconnect to bonded devices, except for A2DP ones… However, if that is happening, maybe you could disconnect/unbond when you notice that the device is stuck or when your service gets killed? Hope Hey, the autoConnect parameter is not enabled. Yes I can do disconnect/unbond the device, the problem is that the user has to open the app, because we don't get any response in the background when the Android OS controls the connection and kills our app. Currently we have a little workaround in our device that kicks the smartphone after 2 seconds in a set up state, because we found out when Android OS tries to reconnect, it get stuck in this state. So we can handle it from our device and get the control back. Edit: Is there a chance to disconnect to a device when the Android OS has the control of the connection ? Like to use the native Android LE methods ? Because if you use the SweetBlue disconnect or shutdown methods the connection is still there..

Hi, any updates or plans on this? It would still be very meaningful. Thanks!

Hi, any updates on the Android Q testing? The APIs are now final on the Android SDK. Thanks!

Alejandro, If you are using a different package name for testing, then you will need a debug key linked to that package name. Email us at sweetblue@idevicesinc.com with the package name, and we'll send you a debug key.

We are using sweetblue v2 with xamarin. I needed to basically create a java wrapper interface around the bledevice methods which required callbacks/listeners. The bindings compilation had issues with the generic type java features being used with the listeners, so I just call to my java wrapper object from c# which has simple listeners and the binding generation has no issues with. I've attached our wrapper's source code for you to use, it filters the scans without needing to call back into c# too which was a huge performance improvement.sweetbluewrapper

What you did works, however, I would suggest using -dontwarn com.idevicesinc.**

@CTirendi has this been published on the maven servers yet?

We're looking at around 2 weeks or so before we put out the official release.