15

I am experiencing serious issues with Android 6.0 and some devices with Bluetooth Low Energy. One of those conflictive devices is this one:

DEVICE INFO:
Name:         Samsung Galaxy SV  
Model number: SM-G900V  
Android vers: 6.0.1  
Patch level:  May 1, 2016  
Hard. vers:   G900V.05  

If I make some stress test based on connecting and disconnecting the app to a BLE peripheral the success ratio barely reaches 50%.

Reading the latest documentation of Android, they recommend to specify the transport mode in the last parameter of connectGatt method to enforce BLE transport connectivity instead of BR/EDR:

device.connectGatt(this, false, mGattCallback, BluetoothDevice.TRANSPORT_LE);

Nothing changed with this improvement.

Following some suggestions and also reading about BLE connectivity issues, I found several related issues with Samsung Galaxy S6 and in one of those they suggested a series of steps to fix BLE connectivity problems. The key one was to clear Bluetooth Share system app data. Doing so, connectivity ratio increased in almost 100% of success immediately. However, if you wait and play with some other BLE apps and connect to other peripherals the problem will be back sooner or later.

There are some apps in Google Play that tries to fix these BLE issues and what they basically do is:

/system/bin/rm -r /data/misc/bluetoothd/*
/system/bin/rm -r /data/misc/hcid/*

Although it is a way to clear bluetooth cache, it requires the device to be rooted which is not a reasonable solution for professional apps.

None of the private Android API's I researched helped me to solve this issue, and the only similar one I found was to enforce service discovery cache cleanup which has nothing to do with the issue.

Using a BLE packet sniffer I see that the ADV_CONNECT_REQ is not even sent from the device to the peripheral, and after a while the Android stack triggers the STATE_DISCONNECTED event in BluetoothGattCallback.

I don't exactly know why this problem occurs in some 6.0 devices and not in others since Bluetooth Share cache seems to be the problem. What is exactly stored there? Just previously connected/paired devices? Am I the only one experiencing this issue? If not, how do you guys tackle it? I would hate to instruct final users on how to Clear Bluetooth Share app Data.

Community
  • 1
  • 1
GoRoS
  • 5,183
  • 2
  • 43
  • 66
  • Tested this on S6 edge and I can confirm, clearing Bluetooth Share cache and data helped it connect without the need to pass BluetoothDevice.TRANSPORT_LE parameter. I am lost as to why this happens also. Before clearing the cache, it did not connect at all. – Can Canbek Jul 25 '16 at 12:51
  • It's good yo know I'm not the only one. Thanks fíe the feedback @CanCanbek , hope someone can help us. – GoRoS Jul 25 '16 at 19:12
  • I read the contents of the above, I understand the general idea of the you mean, in the 6.0 system on S6 edge, after the implementation of the connectGatt() function, executive to the cache operation, can ensure the normal phones and communications equipment, there will be no delay. Is that what it means?@Can Canbek – amibition Aug 16 '16 at 09:39
  • I don't have a perfect solution but found that calling gatt dispose and setting it to null at least reduces this problem to some extent. – user2107373 Sep 01 '16 at 11:09
  • I have a Moto X Play on which BLE device discovery was working well with Android 5.1.1. Post update to Android 6.0, its unable to discover BLE devices. I too need a solution. In the App, I call mBtAdapter.startLeScan(mLeScanCallback). The callback is not seen to be invoked. I see from Android Doc that startLeScan method was deprecated in API level 21. – Padmanabha V Sep 06 '16 at 08:01
  • @Padmanabha it seems this is a different topic or question, so you should ask a new question. However, have you enabled Location services? From Android 6 on location is required for scanning purposes http://stackoverflow.com/questions/33043582/bluetooth-low-energy-startscan-on-android-6-0-does-not-find-devices/33045489#33045489 – GoRoS Sep 06 '16 at 08:53
  • When using one of these problematic mobile devices, do your BLE peripherals show up reliably in BLE scan results? I have had trouble in the past with intermittent failure to find peripherals in a scan and also intermittent failure to connect to a peripheral. The worst devices I had were the Samsung Galaxy Tab S2 and the Samsung Xcover3. We solved the problem on the Samsung Xcover3 by making our peripheral adjust its BLE transmit power in a ramp until a connection occurs. Some devices do not discover BLE advertising packets unless within a particular RSSI range. It has been long and painful. – Mark Ch Sep 18 '17 at 20:15

2 Answers2

0

There is hidden method called "removeBond". Sometimes, ble devices cannot be disconnected clearly, in that case you need to call remove bond.

Codes from here

   //remove authrization 
   Method method = null; 
   try { 
       method = gatt.getDevice().getClass().getMethod("removeBond", (Class[]) null); 
       method.invoke(gatt.getDevice(), (Object[]) null); 
   } catch (Exception e) { 
       e.printStackTrace(); 
   }        
   gatt.disconnect(); 

Additionally, you can refresh gatt services using hidden method "refresh". Originally refresh method is for update gatt services, but in some cases of unwanted disconnection, you may need to refresh to connect your gatt service correctly.

How to programmatically force bluetooth low energy service discovery on Android without using cache

Stanley Ko
  • 3,383
  • 3
  • 34
  • 60
0

My tests indicate that this is a more general problem with the Android Bluetooth Stack and that the GATT Connection failure rate is about 20 percent, compared with just 2 percent on iOS. You can see my detailed test results here

Part of the problem is the Android BLE link supervision timeout is hard-coded to 20 seconds in Android 4.3-9 (it is 5 seconds as of Android 10 and 750 ms on iOS) so if a connection is lost, most Android devices will fail silently to reconnect for 20 seconds.

But the long link supervision timeout still doesn't explain a high rate of failure on the first connection attempt, or the loss of the connection after a short time.

I have found that different BLE peripherals have much different GATT connection failure rates with the same Android device acting as the central. I have one device on my desk with which my Google Pixel 3a will successfully connect at a rate close to 100 percent, and maintain that connection for hours. I have a two other peripherals where the connection failure rate is closer to 20 percent, and connections cannot ever be held for more than 15 seconds.

davidgyoung
  • 63,876
  • 14
  • 121
  • 204