- This topic has 1 reply, 1 voice, and was last updated 6 years, 10 months ago by Anonymous.
- November 14, 2015 at 11:00 pm #5837nidlaXGuest
After a bit more digging on BLE related issues in Android 4.3/4.4, I’ve found that, anecdotally, the Bluetooth stack in those OS versions may have issues with connectivity if you attempt read/write activities immediately post-connection. In light of this, I implemented a test fix in which a thread sleep for 10 seconds was added right after BluetoothGatt.GATT_SUCCESS and before startSingleMeterActivity in the ScanActivity class. The result was a dramatic improvement in the connection success rate. In fact, I would say my LG Volt running Android 4.4.2 now connects with a 90% success rate as opposed to less than 10% if the meter activity is started immediately after GATT_SUCCESS. Empirically, a delay of less than 5 seconds makes no improvement for my phone, so I’ve stuck with a 10 second delay.
My recommendation for a fix is as follows: add either a thread sleep or an activity timer delay between GATT_SUCCESS and starting the meter activity for all instances in which a connection is established or refreshed. Make this sleep / delay setting active by default if the host is running Android 4.3/4.4, and allow the user to toggle the delay and configure its length. A thread sleep might not be appropriate if the app is designed to connect to multiple meters simultaneously, so I think the final implementation will need to be optimized.
Although there is still a connectivity issue with an intermittent crash-on-connect (especially after multiple connect/disconnects), this basic fix transforms the meter from unusable to stable for my LG Volt. I would like to know if this can help anyone else running Android 4.3/4.4 improve the reliability of establishing a connection with their meter.
By the way, thanks for your hard work! I’ll try to pitch in with Android development wherever I can.
- November 20, 2015 at 1:37 am #5905AnonymousGuest
After reading more of the code, I would say sleeping before mInitialized is set to true in MooshimeterDevice.discover() would be reliable. My previous suggestion misses the fact that comm begins once mInitialized = true such as with the scan screen meter readings.