Excellent news, thank you!

@ryanbis Ah, good to know. I will be sure to test this thoroughly. Thanks for the tip!

Excellent, please let me know if you still see the problem.

Removing all the calls to unbond() from our side does not mitigate the automatic reconnection.

Gotcha, sounds great!

Got it, thanks! Will look to alternative solutions like keeping a service in the background. Our goal is to provide push notification capabilities to the custom BLE device.

Glad to hear! Looking forward to the next release.

@ryanbis Awesome! We look forward to the release. Cheers, Gunnar

Try setting the delay between tasks option in the settings menu to something like .5 seconds (the value is in seconds). See if it improves the connection rate at all. I've heard sometimes delaying after service discovery can sometimes help with 133 gatt errors when connecting. This test should at least give us some proof that this is true or not.

Bjoern, How are you setting your reconnect filter?

I'm having the same problems on v3.0.2, where as I connect, turn Bluetooth off and on again, it'll automatically reconnect (at least that's what the sensor says),but a NATIVE_CONNECTION_FAILED is given.

`Well, the Sweetblue library does already make a big improvement on connection time, and the amount of phones even being able to connect... I'm mostly worried about the phones that sometimes don't connect at all, but so far, I've only seen that on a Sony in my small test team... Too bad the guy doesn't want to test again to see if my latest fixes work for that issue :S

That shouldn't matter (where you set the config). However, if you want it to apply to all devices, I would just set the options in the BleManagerConfig when instantiating the BleManager instance. (BleManagerConfig extends BleDeviceConfig mainly for this purpose). Try doing this, and see if you get any different results.

Today was a busy day. When 3.0.3 was initially pushed to our Maven server, it somehow jammed up the works, and thus began 5 hours of work. Finally after slaying the Archiva demon, we were able to successfully get the new version up and ready for the masses. We'll be adding older versions over the next day, so if there's an older version you need, it will be up soon. So onto the changelist! We now have a new kind of API key. This key is meant for licensed customers to be able to deploy debug/alpha/beta versions of their app internally. This key will cause an Exception to be thrown if the app was installed from a public app store (Google, Amazon, Samsung, etc). This key will allow you to use one key for several variations of the app. These new keys will only work on 3.0.3 and up. BleDeviceConfig.tryBondingWhileDisconnected_manageOnDisk has been deprecated, and will be removed in the next minor release (3.2.X, so a while away). Fixed an issue where early outs weren't being emitted to the listener when calling enableNotify/disableNotify. Updated some logic when calling update on BleDevices, which eliminates some ASSERT exceptions that would get posted to Logcat. These messages don't apply anymore since moving to version 3. Fixed NPE that could happen when calling ReadWriteEvent.isNull() in certain scenarios. Bumped gradle plugin version to 3.3.0 Fixed issue where DeviceReconnectFilter wasn't being used, or honored when it is set via BleDevice.setListener_DeviceReconnect() or BleManager.setListener_DeviceReconnect() Added NoReconnectFilter convenience class if you don't want SweetBlue to reconnect at all. Fixed an issue where SweetBlue would unintentionally spam log messages in certain situations when scanning. Fixed a remote issue where SweetBlue should reconnect, but wouldn't. Added check to see if the BleServer has been instantiated before trying to clean it up (this was causing some exceptions to get printed to logcat).

I've updated the logic for enabling/disabling notifications. Now if you pass in a notification listener in a BleNotify instance, it will set that listener as the default only if there are no other NotificationListeners set for the device. This will be in the next version.