General Discussion

• C

  RxJava 3 support
  • caeduk

  3
  0
  Votes
  3
  Posts
  1031
  Views

  L

  Hello @caeduk, nice to see you here Just wanted to mention that there's rxjava3-bridge that can convert between rx2 and rx3 and that has helped me many times when migrating apps to rx3. https://github.com/akarnokd/RxJavaBridge
• 

  Bonding with autoBondFixes set to true deletes all Bluetooth devices from Sony phones
  • AlejandroHCruz

  15
  0
  Votes
  15
  Posts
  3833
  Views

  A

  Hello, we have similiar issue (also tested with setting autoBond to false/true has no affect). We noticed that the Sony Xperia 1 is connected to our BLE device and 60 seconds later it got unbound / unpaired from the smartphone. We tested it with different scenarios to exclude sources of issue (as it is a coffee machine we turned it off before the 60 seconds where over to verify that the coffee machine didnt caused this). My question is: can this be a issue by Sweetblue or is it more a Sony only issue ? (as it only happens on this devices).
• A

  Some received data seems to be overwritten by the latter received one on Android 8 with latest SweetBLUE 3.2.7 and UpdateThreadType.HANDLER_THREAD
  • ando

  3
  0
  Votes
  3
  Posts
  613
  Views

  A

  @ryanbis Thank you for reply and advice. I answer to your questions one by one. Are all of the tests above taken from the same device/tablet? Sorry for my insufficient information. I've updated the table of Summary of our faced issue. I use HUAWEI MediaPad T5 with Android 8.0.0 and Lenovo YT-X705F with Android 10. Can you also list all the BleManagerConfig options you have set? I dumped all member of BleManagerConfig instance which we hand over to BleManager.get(). We changed loggingOptions as needed and updateThreadType only. 12-20 14:59:59.391 10905 10905 E BLE_CORE: loggingOptions : com.idevicesinc.sweetblue.LogOptions@4c8969b 12-20 14:59:59.391 10905 10905 E BLE_CORE: timeTrackerSetting : Off 12-20 14:59:59.391 10905 10905 E BLE_CORE: logger : com.idevicesinc.sweetblue.defaults.DefaultLogger@e2d8a38 12-20 14:59:59.391 10905 10905 E BLE_CORE: defaultManagerStates : [Lcom.idevicesinc.sweetblue.BleManagerState;@8d11a11 12-20 14:59:59.391 10905 10905 E BLE_CORE: enableCrashResolver : false 12-20 14:59:59.391 10905 10905 E BLE_CORE: enableCrashResolverForReset : true 12-20 14:59:59.391 10905 10905 E BLE_CORE: stopScanOnPause : true 12-20 14:59:59.397 10905 10905 E BLE_CORE: scanClassicBoostLength : -1secs/-1000millis 12-20 14:59:59.398 10905 10905 E BLE_CORE: infiniteScanInterval : 10secs/10000millis 12-20 14:59:59.398 10905 10905 E BLE_CORE: infinitePauseInterval : 0.5secs/500millis 12-20 14:59:59.398 10905 10905 E BLE_CORE: autoScanDuringOta : false 12-20 14:59:59.398 10905 10905 E BLE_CORE: revertToClassicDiscoveryIfNeeded : true 12-20 14:59:59.398 10905 10905 E BLE_CORE: updateThreadType : HANDLER_THREAD 12-20 14:59:59.398 10905 10905 E BLE_CORE: updateHandler : null 12-20 14:59:59.399 10905 10905 E BLE_CORE: postCallbacksToMainThread : true 12-20 14:59:59.399 10905 10905 E BLE_CORE: manageCpuWakeLock : true 12-20 14:59:59.399 10905 10905 E BLE_CORE: requestBackgroundOperation : false 12-20 14:59:59.399 10905 10905 E BLE_CORE: autoPauseResumeDetection : true 12-20 14:59:59.401 10905 10905 E BLE_CORE: uhOhCallbackThrottle : 30secs/30000millis 12-20 14:59:59.401 10905 10905 E BLE_CORE: manageLastUhOhOnDisk : true 12-20 14:59:59.401 10905 10905 E BLE_CORE: blockingShutdown : false 12-20 14:59:59.402 10905 10905 E BLE_CORE: autoScanDelayAfterResume : 0.5secs/500millis 12-20 14:59:59.402 10905 10905 E BLE_CORE: autoScanDelayAfterBleTurnsOn : -1secs/-1000millis 12-20 14:59:59.402 10905 10905 E BLE_CORE: autoScanPauseTimeWhileAppIsBackgrounded : -1secs/-1000millis 12-20 14:59:59.403 10905 10905 E BLE_CORE: idealMinScanTime : 5secs/5000millis 12-20 14:59:59.403 10905 10905 E BLE_CORE: autoUpdateRate : 0.02secs/20millis 12-20 14:59:59.404 10905 10905 E BLE_CORE: defaultStatePollRate : 0.1secs/100millis 12-20 14:59:59.404 10905 10905 E BLE_CORE: idleUpdateRate : 0.5secs/500millis 12-20 14:59:59.404 10905 10905 E BLE_CORE: minTimeToIdle : 20secs/20000millis 12-20 14:59:59.405 10905 10905 E BLE_CORE: delayBetweenTasks : -1secs/-1000millis 12-20 14:59:59.405 10905 10905 E BLE_CORE: scanReportDelay : 0secs/0millis 12-20 14:59:59.405 10905 10905 E BLE_CORE: defaultScanFilter : null 12-20 14:59:59.405 10905 10905 E BLE_CORE: defaultNativeScanFilterList : [BluetoothLeScanFilter [m_deviceName=null, m_deviceAddress=null, mUuid=null, m_uuidMask=null, m_serviceDataUuid=null, m_serviceData=null, m_serviceDataMask=null, m_manufacturerId=-1, m_manufacturerData=null, m_manufacturerDataMask=null]] 12-20 14:59:59.405 10905 10905 E BLE_CORE: defaultDiscoveryListener : null 12-20 14:59:59.405 10905 10905 E BLE_CORE: scanApi : AUTO 12-20 14:59:59.406 10905 10905 E BLE_CORE: scanPower : AUTO 12-20 14:59:59.406 10905 10905 E BLE_CORE: updateLoopCallback : null 12-20 14:59:59.406 10905 10905 E BLE_CORE: serverFactory : com.idevicesinc.sweetblue.internal.android.IBluetoothServer$DefaultFactory@29c464d 12-20 14:59:59.406 10905 10905 E BLE_CORE: bluetoothManagerImplementation : com.idevicesinc.sweetblue.internal.android.AndroidBluetoothManager@6839502 12-20 14:59:59.406 10905 10905 E BLE_CORE: uuidNameMaps : null 12-20 14:59:59.406 10905 10905 E BLE_CORE: defaultListComparator : com.idevicesinc.sweetblue.BleManagerConfig$DeviceNameComparator@ef93e13
• A

  Support connectGatt of API level 26 to pass handler to use for callback to notify/write on single characteristic
  • ando

  14
  0
  Votes
  14
  Posts
  1844
  Views

  A

  @ryanbis I'm very glad 3.2.7 is released! Thank you for your prompt service. We are now verifying notify/write on single characteristic with setting UpdateThreadType as HANDLER_THREAD.
• O

  Is there support for secure pairing & bonding, e.g. with OOB secret ? If so is there an example ?
  • Olivier HERSENT

  4
  0
  Votes
  4
  Posts
  667
  Views

  R

  I must admit, I'm not as familiar with that method of pairing. Usually you just call the bond method, and then a dialog will pop up requesting the pin. However, I would suggest that since you seem to have control over the firmware of the product, to implement your own encryption scheme. Android's pairing process can work well on some phones, but on others it can be a nightmare. I'd look into using a couple of characteristics for transmitting and receiving encrypted data. You can set up some kind of key exchange between the 2 to establish a session secret to use for encrypting/decrypting data. Easiest way would be to just implement pairing the standard way, and just call bond() to do so (but you will run into bonding issues on some phones).
• A

  how is the progress of support Android 12
  • ando

  4
  0
  Votes
  4
  Posts
  805
  Views

  R

  Yes, as long as you request those permissions at runtime as well as adding them to the manifest.
• 

  Android 12
  • AlejandroHCruz

  3
  0
  Votes
  3
  Posts
  1033
  Views

  A

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

  ConnectionBugHack
  • Teruyama

  4
  0
  Votes
  4
  Posts
  1052
  Views

  R

  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.
• M

  BLE notifications from background in android
  • moblers

  2
  0
  Votes
  2
  Posts
  863
  Views

  R

  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.
• 

  Disconnection issues while bonded on Huawei & Honor devices
  • AlejandroHCruz

  12
  0
  Votes
  12
  Posts
  4204
  Views

  C

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

  API KEY unavailable
  • jastrada

  1
  0
  Votes
  1
  Posts
  907
  Views

  No one has replied

• 

  How does ConnectionLostPlease.persistIf work compared to autoconnect?
  • AlejandroHCruz

  7
  0
  Votes
  7
  Posts
  2004
  Views

  

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

  Background scan times out on S10 (maybe other Samsungs)
  • blawlor

  3
  0
  Votes
  3
  Posts
  1789
  Views

  

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

  Foretting a device's characteristics
  • AlejandroHCruz

  6
  0
  Votes
  6
  Posts
  1614
  Views

  

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

  App crashing when SweetBlue dependency is added
  • EarlyWild

  2
  0
  Votes
  2
  Posts
  1516
  Views

  E

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

  Cannot get read/notify when connected to more than two devices.
  • mcgkc55

  3
  0
  Votes
  3
  Posts
  1653
  Views

  M

  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?
• M

  multiple calls per second for onConnectionLost of DeviceReconnectFilter
  • mcgkc55

  2
  0
  Votes
  2
  Posts
  1275
  Views

  R

  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.
• R

  Trial Key not working in Android library package
  • rhilse

  4
  0
  Votes
  4
  Posts
  1900
  Views

  R

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

  Best practices for saving battery life
  • AlejandroHCruz

  4
  0
  Votes
  4
  Posts
  1999
  Views

  R

  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 :).
• 

  Interacting with device that's already connected to the OS
  • AlejandroHCruz

  10
  0
  Votes
  10
  Posts
  5008
  Views

  

  @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