So I'm trying to get an old version of bluetooth on Sony phones to work
In the process I realized I've always been doing something dumb which
bastically works fine, but is an ugly hack I also did to support old
devices. Due to an accident of history there were two different layers
of the app which were trying to manage bluetooth connections, which was
dumb. Always only one layer of an app should worry about such things.
/**
* Should we automatically try to reconnect when we lose our connection?
*
* Originally this was true, but over time (now that clients are smarter and need to build
* up more state) I see this was a mistake. Now if the connection drops we just call
* the lostConnection callback and the client of this API is responsible for reconnecting.
* This also prevents nasty races when sometimes both the upperlayer and this layer decide to reconnect
* simultaneously.
*/
to complete. Change timeout to 10 secs (units in the field were showing
the mtu operation completing after 5 seconds.
Also - don't throw an exception if we encounter a result when we've already
killed things with the failsafe timer
Non-fatal Exception: kotlin.KotlinNullPointerException
at com.geeksville.mesh.service.BluetoothInterface.doDiscoverServicesAndInit(BluetoothInterface.java:357)
at com.geeksville.mesh.service.BluetoothInterface.access$doDiscoverServicesAndInit(BluetoothInterface.java:78)
at com.geeksville.mesh.service.BluetoothInterface$onConnect$1.invokeSuspend(BluetoothInterface.java:429)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(BaseContinuationImpl.java:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.java:56)
at kotlinx.coroutines.scheduling.CoroutineScheduler.runSafely(CoroutineScheduler.java:571)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.executeTask(CoroutineScheduler.java:738)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.runWorker(CoroutineScheduler.java:678)
at kotlinx.coroutines.scheduling.CoroutineScheduler$Worker.run(CoroutineScheduler.java:665)
root cause in log:
the problem is that we are running dropAndReconnect (because of an error diduing writec) at the same time as handleSendToRadio called scheduleReconnect because of the exception
fix is: now that BluetoothInterface is smart enough to do its own reconnections, do not auto reconnect in SafeBluetooth. Instead just throw a BLEException and assume the client will reconnect if it wants.
geeksville