iOS, turning off bluetooth radio and peripheral.state

[curioustechizen]

Hello, I considered opening an issue for this, but I'm not sure if I'm using the library wrong. So I opened a discussion instead.

My question is : On iOS, given a peripheral with an active connection, should turning off the Bluetooth radio result in the peripheral.state flow emitting a Disconnected state?

In my app I never see this. On Android it works a 100% of the time but on iOS I see the following sequence of events in the Kable logs. Disconnection always times out after 5 seconds; and the Disconnected state is never emitted. Since things work as expected on Android, I'm assuming this might be something I'm doing wrong.

I/Kable: <SOME-UUID> Bluetooth powered off
  state: 4
V/Kable/Connection: <SOME-UUID> Waiting for connection tasks to complete
D/Kable/Connection: <SOME-UUID> Disconnecting
V/Kable/Connection: <SOME-UUID> cancelPeripheralConnection
API MISUSE: <CBCentralManager: 0x30259c000> can only accept this command while in the powered on state
W/Kable/Connection: <SOME-UUID> Timed out after 5s waiting for disconnect
D/Kable/Connection: <SOME-UUID> Closing
kotlin.coroutines.cancellation.CancellationException: com.juul.kable.NotConnectedException: Disconnect requested
    at 0   MyAppName.debug.dylib      0x105570eeb        kfun:kotlin.Throwable#<init>(kotlin.Throwable?){} + 243 
    at 1   MyAppName.debug.dylib      0x10556b0a7        kfun:kotlin.Exception#<init>(kotlin.Throwable?){} + 95 
    at 2   MyAppName.debug.dylib      0x10556b277        kfun:kotlin.RuntimeException#<init>(kotlin.Throwable?){} + 95 
    at 3   MyAppName.debug.dylib      0x10556b73b        kfun:kotlin.IllegalStateException#<init>(kotlin.Throwable?){} + 95 
    at 4   MyAppName.debug.dylib      0x105577fe3        kfun:kotlin.coroutines.cancellation.CancellationException#<init>(kotlin.Throwable?){} + 95 
    at 5   MyAppName.debug.dylib      0x105f81283        kfun:com.juul.kable.CBPeripheralCoreBluetoothPeripheral#disconnect#suspend(kotlin.coroutines.Continuation<kotlin.
I/Kable/Connection: <SOME-UUID> Closed

From my reading of the source, it looks like there are 2 components at play here

1. onBluetoothPoweredOff in CBPeripheralCoreBluetoothPeripheral.kt
2. onDispose in Connection.kt.

It looks like for some reason, when onBluetoothPoweredOff happens, then disconnect is also being called. My guess is that CBCentralManager.cancelPeripheralConnection is only allowed to be called when the Bluetooth radio is powered on and that explains the rest of the log output.

However, what I don't understand is: Why is onBluetoothPoweredOff eventually calling disconnect in Perpiheral.kt? Could it be something do with the coroutine scope that I'm using to collect the peripheral.state flow?

Does anyone have any ideas?

[twyatt]

Bluetooth state handling on iOS has not yet been thoroughly tested, so it is possible it is being handled incorrectly on iOS.

Ultimately, Kable aims to have the platforms be as consistent as possible; so the situation you're describing (state not transitioning to Disconnected when BLE is turned off, while it doing that on Android) does seem like a bug.

On Android, when bluetooth is turned off, peripherals remain connected, but strange behavior around that can ensue — so, Kable makes sure to explicitly drop connections. Explicitly closing connections on iOS may not be needed, but we rely on the system to deliver us connection state. So, if iOS is automatically killing connections for us, then I'm really surprised it doesn't send us a disconnect event.

Definitely worth investigating further. The questions I'd need to test (when I have time) are:

1. Does iOS drop peripherals connections for us when bluetooth is turned off (meaning we shouldn't call cancelPeripheralConnection)? Is that behavior consistent across all iOS versions?
2. If iOS drops connections for us, does it deliver the disconnected event to the delegate callback? (if not, we'd need to explicitly set the state)

[curioustechizen]

In my limited testing I notice that when you turn of bluetooth, the peripheral:didDisconnect: callback of the CBPeripheralDelegate is not called. I always assumed that on iOS, you need to monitor both the peripheral disconnection event and the CentralManager state to determine if your peripheral is connected.

But my testing does not have a good spread of iOS devices and versions so I don't want to draw any conclusions from it.

[twyatt]

Created #959 to track.