kopia lustrzana https://github.com/meshtastic/Meshtastic-Android
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.pull/66/head
rodzic
8e0ceb6661
commit
2780a08931
7
TODO.md
7
TODO.md
|
@ -1,7 +1,12 @@
|
||||||
# Remaining tasks before declaring 1.0
|
# 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 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.
|
Things for the betaish period.
|
||||||
|
|
||||||
|
|
|
@ -384,11 +384,14 @@ class BluetoothInterface(val service: RadioInterfaceService, val address: String
|
||||||
// This callback is invoked after we are connected
|
// This callback is invoked after we are connected
|
||||||
|
|
||||||
connRes.getOrThrow()
|
connRes.getOrThrow()
|
||||||
|
|
||||||
|
service.serviceScope.handledLaunch {
|
||||||
info("Connected to radio!")
|
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
|
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
|
//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()
|
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
|
||||||
}
|
}
|
||||||
|
|
||||||
// we begin by setting our MTU size as high as it can go (if we can)
|
// we begin by setting our MTU size as high as it can go (if we can)
|
||||||
|
@ -411,6 +414,7 @@ class BluetoothInterface(val service: RadioInterfaceService, val address: String
|
||||||
else
|
else
|
||||||
doDiscoverServicesAndInit()
|
doDiscoverServicesAndInit()
|
||||||
}
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
|
||||||
override fun close() {
|
override fun close() {
|
||||||
|
|
Ładowanie…
Reference in New Issue