Disconnection issues while bonded on Huawei & Honor devices



  • @ryanbis, thank you for your suggestion.

    The issue seems to be the one you've pointed out: W/P_UhOhThrottler: UPDATE(24744) uhOh() - CONNECTION_STILL_ALIVE

    I've also been able to reproduce this issue on a OnePlus 1 device.

    Sometimes the onEvent(ConnectionBugEvent e) gets called, producing the log above, but sometimes it doesn't so the device stays stuck on this artificial “connected” state even in the cases in which the connection did not go through.

    Could it be related to this issue that I see on every connection attempt (even on those who succeed)?

    2019-12-11 15:03:11.399 E/BleManager: ASSERTION FAILED 
    java.lang.Exception
        at com.idevicesinc.sweetblue.internal.P_BleManagerImpl.ASSERT(P_BleManagerImpl.java:671)
        at com.idevicesinc.sweetblue.internal.P_DeviceConnectionManager.onConnected(P_DeviceConnectionManager.java:183)
        at com.idevicesinc.sweetblue.internal.P_BleDeviceImpl.onNativeConnect(P_BleDeviceImpl.java:1422)
        at com.idevicesinc.sweetblue.internal.P_BleDevice_ListenerProcessor.onNativeConnect(P_BleDevice_ListenerProcessor.java:213)
        at com.idevicesinc.sweetblue.internal.P_BleDevice_ListenerProcessor.onConnectionStateChange_updateThread(P_BleDevice_ListenerProcessor.java:162)
        at com.idevicesinc.sweetblue.internal.P_BleDevice_ListenerProcessor.lambda$onConnectionStateChange$0$P_BleDevice_ListenerProcessor(P_BleDevice_ListenerProcessor.java:142)
        at com.idevicesinc.sweetblue.internal.-$$Lambda$P_BleDevice_ListenerProcessor$YO_ZOMJ313stv1rjLiHfCHO_nkg.run(lambda)
        at com.idevicesinc.sweetblue.internal.ThreadHandler$SweetRunnable.run(ThreadHandler.java:173)
        at com.idevicesinc.sweetblue.internal.ThreadHandler.processRunnables(ThreadHandler.java:221)
        at com.idevicesinc.sweetblue.internal.ThreadHandler.loop(ThreadHandler.java:58)
        at com.idevicesinc.sweetblue.internal.P_SweetBlueThread$HandlerRunner.run(P_SweetBlueThread.java:30)
        at java.lang.Thread.run(Thread.java:776)


  • No, that assert is ok (its meant to inform us of when weird things happen we're not expecting). It's just showing how messed up bonding can be on android. It's tripping that assert because the device is reporting that it's bonded, but the device doesn't show up in the list of bonded devices from the system. SweetBlue isn't doing anything about it, just throwing the assert (which one do we trust to be accurate?).



  • I see. Thanks for the information on the asserts when bonding.

    I've also experienced a state in which the device was disconnecting and connecting again all the time in a loop.

    It could've been cause by a combination of using the ConnectionBugEvent.Please.tryFix() and something else my configuration file.

    This is what I've set it to do:

     forceBondDialog = true // does not always works
     useLeTransportForBonding = true
     autoBondFixes = true
     tryBondingWhileDisconnected = true
     bondingFailFailsConnection = true
     alwaysBondOnConnect = true
    

    Should I try anything else in the config? I'm thinking about changing useLeTransportForBonding to false and adding autoReconnectDeviceWhenBleTurnsBackOn = true



  • Hi.

    I've fixed the loop by ignoring multiple calls to the onEvent(ConnectionBugEvent e) however the disconnection issue is not fixed.

    I'm considering prompting the user to restart their Bluetooth adapter... Not sure what else to do when the UhOh's suggestion is to RECYCLE_CONNECTION 🤔



  • Unfortunately, thats a side effect of the bug fix. This is why it's not on by default. In most cases it fixes the problem, but not all. If it doesn't fix the problem, it will end up in a loop because the problem still exists. Do you find that recycling the bluetooth adapter fixes the problem?



  • Actually, it looks like we had a bug in the implementation. I've fixed it on our dev branch currently so it will not go into a perpetual loop. Still probably won't fix your issue, but at least in the next release, you won't end up in a connection loop.



  • It's great that you've fixed the connection loop issue! 🥳 Looking forward to that future update.

    By recycling the Bluetooth adapter you mean to turn it off and on again?
    When I do that manually, then I can connect the bonded device on the next attempt.

    Is it a good practice to do this on the background silently or to ask/notify/alert the user before doing this? I would go and do it silently if there's a way for me to detect that no other Bluetooth devices are connected to the OS...

    By the way, the issue even happens on the Google Pixel 2 if I delete the bonding keys on the phone but not on the bonded peripheral.



  • By recycling the Bluetooth adapter you mean to turn it off and on again?
    When I do that manually, then I can connect the bonded device on the next attempt.

    Interesting. When I was messing around with it, turning bluetooth off/on didn't seem to make any difference.

    Is it a good practice to do this on the background silently or to ask/notify/alert the user before doing this? I would go and do it silently if there's a way for me to detect that no other Bluetooth devices are connected to the OS...

    I would say it's always good practice to ask the user before doing it.



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



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