Anybody have thoughts on this? Trying to get it resolved ASAP, so any insight would be appreciated. Thanks!
On Thursday, September 1, 2016 at 3:31:46 PM UTC-4, Chris Bates wrote: > > I am part of a team developing an Android application that will connect to > various beacons via BLE, and then execute different commands (such as > sending requests for data). This works fairly well for most of the BLE > beacons and on most platforms, but we've noticed a lot of connection issues > with the most recent version of the beacon. The connection issues seem to > be specific to non-Nexus devices, so it's possible that this isn't an issue > or something that can be address from this end, but we're running out of > ideas and wanted to see if anyone has seen something similar and > (hopefully) found a solution. > > Through several rounds of debugging and trying different solutions, we've > identified the problem to a flag being set incorrectly during the > connection attempt. This flag is used to specify the type of address for > the BLE beacon, and on the Nexus devices (we've tested on Nexus 5 and Nexus > 7, Android 6.0.1) the flag is set to use a "Random Device Address". This > results in a successful connection, and everything is fine. However, on > other devices, most notably Samsung which we've done most of our testing > on, this flag is sometimes set to "Public Device Address". When this flag > is set incorrectly, the connection will fail. If we toggle Wi-Fi and > Bluetooth off, and then restart the phone, this flag will more likely get > set correctly, but it usually gets worse over time. As mentioned earlier, > this is happening for almost all connection attempts to our latest > BLE beacon version, but we have noticed the same behaviour on failed > connections with previous BLE beacons (it just doesn't happen as often). > > Now that we've identified what we believe is the route cause, we've been > looking for a way to ensure the flag is always set correctly, but > unfortunately have come up short. Has anyone encountered this issue before > and found a way to ensure the connection attempt is set correctly? Is there > any way to ensure these flags are set correctly for BLE connection attempts? > > As a side note, we've noticed on Samsung devices that the failed > connection will be killed after about 5 seconds, and that this results in a > 133 status code back from BluetoothGatt, which is an undocumented error > code. Our understanding is that the connection is being forcibly killed by > Samsung so we get this "unknown failure" code. We've tested on an HTC One > M8 and haven't seen this behaviour, but the incorrect flag is still set > preventing a solid connection. > > Any ideas would be greatly appreciated. Thanks! > -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/android-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/android-developers/4959130e-17f8-429f-a5f7-e358c81a7180%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
