Commit graph

61 commits

Author SHA1 Message Date
Kevin Hester
cea7755aa4 ignore BLE errors while closing 2021-03-23 13:17:36 +08:00
Kevin Hester
518241c3c9 less logspam 2021-03-23 13:05:50 +08:00
Paul Mandal
1357be5499 Change SafeBluetooth's handler to run on the main thread 2020-09-25 19:44:04 -06:00
Ken Van Hoeylandt
f97bc21719 simplified calls to system services
and fixed some code that assumed BluetoothManager to never be NULL
2020-09-17 19:49:50 +02:00
geeksville
a5678392f5 fix autobug - if gatt is closed while we are shutting down it is not an error 2020-08-30 12:01:38 -07:00
geeksville
bd29a93a71 fix autobug during software update, treat sync timeouts just like async timeouts 2020-08-30 11:52:46 -07:00
geeksville
750855c8d4 begin gradle support for auto play upload 2020-07-20 12:07:55 -07:00
geeksville
6b0e19ea9a remove comment 2020-07-18 14:24:06 -07:00
geeksville
25ceaa6364 Fix autobugs related to Samsung BLE 2020-07-18 13:18:38 -07:00
geeksville
38b4bc255c 0.7.90 read on if you want to see the stories of bluetooth trauma #76
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.
     */
2020-07-04 17:40:44 -07:00
geeksville
bc6fa0b1bb If we have an exception thrown *back to us* complain and ignore it? 2020-07-04 11:33:24 -07:00
geeksville
92b3fa8d1f bug #76 - old sonys can take a VERY long time for the setMTU operation
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
2020-07-04 11:19:54 -07:00
geeksville
5f34fcba17 0.7.88 oops - if no work is pending, we also try to reconnect 2020-07-02 14:08:12 -07:00
geeksville
103b21aafd Add stress tester that simulates super high chance of BLE failures
and fix bug that it revealed (missing handling of error during discovery)
2020-07-02 09:38:08 -07:00
geeksville
e5d6ffc4bd fix #77, see below:
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.
2020-07-02 08:46:25 -07:00
geeksville
4172b221f0 autobug: failure to start should be treated like any other BLE exception 2020-06-30 12:35:58 -07:00
geeksville
fed418dae2 better debug output for the next time an autobug occurs 2020-06-30 12:18:49 -07:00
geeksville
e6fd79f477 fix another autobug - clear gatt first, because close() can fail 2020-06-30 11:39:04 -07:00
geeksville
549b1e8d7c fix #68 - workaround a disconnect bug in old androids
https://github.com/don/cordova-plugin-ble-central/issues/473#issuecomment-396790239
2020-06-28 18:04:52 -07:00
geeksville
1fd80c06d8 Fix #67, see that issue for writeup. gatt needs to be @Volatile 2020-06-25 17:56:31 -07:00
geeksville
b3f0ef6b09 now that BLE and UART are equal peers, much cleaner to look for
BLE disable/enable in the general RadioInterfaceService
2020-06-20 14:50:15 -07:00
geeksville
aae9690369 minor cleanups 2020-06-18 15:47:36 -07:00
geeksville
323809b762 fix autobug when gatt is being destroyed 2020-06-18 15:45:30 -07:00
geeksville
65014dac48 Fix autobug by making the standard reconnect logic also get used if
we are told BLE just got turned back on.
2020-06-18 15:41:15 -07:00
geeksville
73de2c33c2 fix autobug if old work items run after gatt is destroyed 2020-06-17 14:02:58 -07:00
geeksville
44e084c999 fix dead object exception 2020-06-15 07:09:21 -07:00
geeksville
f9c1ac8cd2 Fix back to back writes to not overwrite BLE characterstic. Fixes
the "sending while device was asleep bug"
2020-06-13 16:21:26 -07:00
geeksville
eb5a492ade OMG - we were accidentally leaving two GATTs alive - which is super bad 2020-06-11 17:34:22 -07:00
geeksville
e20f7c5943 use only async io when talking to the radio 2020-06-11 16:22:20 -07:00
geeksville
96a28afb8f fix autobug: old notifies might come in from devices we are reconnecting to 2020-06-10 12:03:31 -07:00
geeksville
1be402d771 fix autobug - discovery can now occur after mtu 2020-06-10 11:42:11 -07:00
geeksville
590e76731f One more fix for Soyes XS phones (but see disclaimer below)
The bluetooth implementation of this phone calls the gatt callbacks
*before* the connect call returns to the client.  This is incorrect because
the client won't have a reference to the gatt at that time.

Fortunately, we only need to check gatt on disconnect, so I moved that later.

But one problem I've noticed in my testing.  Sometimes this phone stops
being able to scan for BLE devices.  The only fix I've found is to click to
turn bluetooth off briefly and then back on.

A major problem with this phone is that if you reboot the phone it seems
the time the phone has forgotten its paring data and devices must
be re-paired.  This is a huge bummer and I don't think my app can fix this.
2020-06-09 12:25:05 -07:00
geeksville
2568f00762 ignore failures delivering close exceptions (autobug) 2020-06-09 10:22:19 -07:00
geeksville
7a3cda314e Fix recent bug where sometimes phone would not auto-reconnect to devices 2020-06-07 18:05:18 -07:00
geeksville
db43f47f91 handle 133 statuses when direct connect fails 2020-06-04 09:58:06 -07:00
geeksville
d526d11d20 Fix #32
+            // Note: To workaround https://issuetracker.google.com/issues/36995652
+            // Always call BluetoothDevice#connectGatt() with autoConnect=false
+            // (the race condition does not affect that case). If that connection times out
+            // you will get a callback with status=133. Then call BluetoothGatt#connect()
+            // to initiate a background connection.
2020-06-04 09:35:25 -07:00
geeksville
4d6ca25caf autobug, prevent redundant notifcations from onConnectChanged 2020-05-24 11:38:33 -07:00
geeksville
38f45a9413 fix autobug that showed on a MIX2 (whatever that is), ignore BLE state changes
when we don't have a gatt
2020-05-24 11:07:15 -07:00
geeksville
e6abd9d1a5 autobugs - some phones send bougs onMtuChanged when we are not setting mtu 2020-05-24 11:01:13 -07:00
geeksville
8b3817964e make sync BLE operations timeout a bit shorter 2020-05-24 10:47:02 -07:00
geeksville
a191dac0f4 stay with old api for now, because too much change hurts reliaiblity ;-) 2020-05-24 10:12:12 -07:00
geeksville
28023b8f42 Fix 27: add timeouts for BLE operations, to protect against buggy drivers 2020-05-24 09:45:39 -07:00
geeksville
c06f5f1c39 set aside ble sw update for now 2020-05-15 10:18:15 -07:00
geeksville
0b7f853abc fix an autobug - race condition on some phones BLE reconnect 2020-05-10 21:39:49 -07:00
geeksville
5822dddc6c Fix #23: autobug, if we get mystery BLE error 133 while reading messages
drop the BLE link and reconnect and try again.
2020-04-26 13:03:35 -07:00
geeksville
e302848607 0.5.5 only try to set max MTU once, if it fails consider phone buggy 2020-04-24 15:49:34 -07:00
geeksville
3e89510f52 Some phones have buggy race conditions wrt finding services or characteristics
This workaround is: If we fail in that way during initial device connection
we disconnect() and try again 500 ms later.
2020-04-24 15:22:54 -07:00
geeksville
8bf60c7603 make BLE exceptions strongly typed, so I can trigger closing down connections if needed 2020-04-20 11:10:53 -07:00
geeksville
0919bc75ef only ignore connect failures if autoconnect is on 2020-04-20 11:01:27 -07:00
geeksville
2a52b707ee fix autobug: some phones call gatt connected but with an error status code 2020-04-20 10:37:46 -07:00