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 android-developers+unsubscr...@googlegroups.com. To post to this group, send email to android-developers@googlegroups.com. 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.
