The android Gatt caching bug on old phones (based on my reading of

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.
1.2-legacy
geeksville 2020-06-25 15:53:17 -07:00
rodzic 8e0ceb6661
commit 2780a08931
2 zmienionych plików z 34 dodań i 25 usunięć

Wyświetl plik

@ -1,7 +1,12 @@
# Remaining tasks before declaring 1.0
- disable software update button after update finishes
- check BLE handle stability across sleep - stress test sleep/wake
- @feh123 Sony Xperia Z1 C6903 running Android 5.1.1
- first message sent is still doubled for some people
- Android frontend should refetch the android messages from backend service on Resume
- let users set arbitrary params in android
* add a low level settings screen (let user change any of the RadioConfig parameters)
* add play store link with https://developers.google.com/analytics/devguides/collection/android/v4/campaigns#google-play-url-builder and the play icon
Things for the betaish period.

Wyświetl plik

@ -384,32 +384,36 @@ class BluetoothInterface(val service: RadioInterfaceService, val address: String
// This callback is invoked after we are connected
connRes.getOrThrow()
info("Connected to radio!")
if (needForceRefresh) { // Our ESP32 code doesn't properly generate "service changed" indications. Therefore we need to force a refresh on initial start
//needForceRefresh = false // In fact, because of tearing down BLE in sleep on the ESP32, our handle # assignments are not stable across sleep - so we much refetch every time
forceServiceRefresh()
}
// we begin by setting our MTU size as high as it can go (if we can)
if (shouldSetMtu)
safe!!.asyncRequestMtu(512) { mtuRes ->
try {
mtuRes.getOrThrow() // FIXME - why sometimes is the result Unit!?!
debug("MTU change attempted")
// throw BLEException("Test MTU set failed")
doDiscoverServicesAndInit()
} catch (ex: BLEException) {
shouldSetMtu = false
scheduleReconnect(
"Giving up on setting MTUs, forcing disconnect $ex"
)
}
service.serviceScope.handledLaunch {
info("Connected to radio!")
if (needForceRefresh) { // Our ESP32 code doesn't properly generate "service changed" indications. Therefore we need to force a refresh on initial start
//needForceRefresh = false // In fact, because of tearing down BLE in sleep on the ESP32, our handle # assignments are not stable across sleep - so we much refetch every time
forceServiceRefresh() // this article says android should not be caching, but it does on some phones: https://punchthrough.com/attribute-caching-in-ble-advantages-and-pitfalls/
delay(200) // From looking at the android C code it seems that we need to give some time for the refresh message to reach that worked _before_ we try to set mtu/get services
}
else
doDiscoverServicesAndInit()
// we begin by setting our MTU size as high as it can go (if we can)
if (shouldSetMtu)
safe!!.asyncRequestMtu(512) { mtuRes ->
try {
mtuRes.getOrThrow() // FIXME - why sometimes is the result Unit!?!
debug("MTU change attempted")
// throw BLEException("Test MTU set failed")
doDiscoverServicesAndInit()
} catch (ex: BLEException) {
shouldSetMtu = false
scheduleReconnect(
"Giving up on setting MTUs, forcing disconnect $ex"
)
}
}
else
doDiscoverServicesAndInit()
}
}