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.
username_unset - look to "unset", normally not translated to "ungesetzt" instead use "nicht gesetzt"
Translated "cancel" to "Abbrechen". Expected standard for most users. If you want to use "Rückgängig" please fix the typo ("Rückgänig")
looking_for_meshtastic_devices - corrected wrong case
new_channel_rcvd - corrected wrong case
the android C code) needs a small delay after calling refresh() because
otherwise the (stale) BLE handles are not discarded until _after_
we start using the connected service.
(for now - possibly loosen in the future - someone reported the device
code didn't like odd characters, and we definitely don't want anything
>127). Also, shrink length to 11 chars (which is 12 including the nul
terminator on the device side (current limit in mesh.options).
