3

I have just a little question about BLE services discovery on Android. I have something that is working perfectly fine but I have a little performances issue..

I saw that the function BluetoothGatt.discoverServices() first discovers all the services+characteristics+descriptors before it sends it back to you. But in my case it takes a little more than two seconds and I absolutely need it to take less time. I based my code on the sample that I found in the Android SDK.

So I just wanted to know if there is any way to do it ? Can we override the services discovery so we can just discover services and not the characteristics/descriptors or anything else :/ ? Or is there any other way to discovers services?

tshepang
  • 12,111
  • 21
  • 91
  • 136
Alarsha
  • 31
  • 5
  • iOS also discovers everything. I think your chances are bad to tweak the service discovery on the Android side. – OneWorld Mar 09 '14 at 00:25
  • 2 seconds is kind of long. It takes max half a second for 20 discovered elements in my app. How much stuff does your device provide? Does your Ble service have bad performance? You could try to discover services in another thread. What's your device? E.g. on Samsung Galaxy S3 with android 4.3 you have to use a new thread inside onLeScan in order not to block the Ble stack. – OneWorld Mar 09 '14 at 00:26
  • Why do you need faster discovery? Could you discover services at some earlier point and actually work with the device at a later time? – OneWorld Mar 09 '14 at 00:26
  • @OneWorld: First of all thank you for your time and your answers. I work on a Samsung Galaxy S4 with Android 4.3. I will quickly discribe you the process I go through in my app: - I launch the scan for BLE devices and put the devices found in a ListView (This part is fine) - Then I select a device in the List: the scan is stopped, I connect to the device, launch the services discovery, execute some actions on the characteristics, and the device disconnect me. So I can't do the service discovery before because I don't know which device the user will select :/ – Alarsha Mar 10 '14 at 09:11
  • @OneWorld: And I need to do it in less than 2 seconds because the device I want to connect to has a 2 seconds timeout so if I have not finished the discovery within 2 seconds, it disconnects me. – Alarsha Mar 10 '14 at 09:13
  • @OneWorld: I've done some tests this morning and found something I didn't know. Does Android stock the services found somewhere for the next discovery ? Because when I first connect to the device it takes around 2.4 second to find 4 services + 19 characteristics + very small operations. But each time after I do the exact same process, it takes around 0.1 second until I connect to another device (2.4 seconds again) I tried to do the service discovery in another thread but it doesn't change anything – Alarsha Mar 10 '14 at 09:19
  • It's possible that Android handles some pairing internally. However, you can't count on it. The behaviour may be different on other handsets. It's important that you try your code on other handsets. – OneWorld Mar 10 '14 at 09:51
  • @OneWorld: I'm sorry, what do you call "handsets" ? Is it the phone I use or the device I want to connect to ? It will always be the same device but not always the same phone. So globally you think that it is not possible to improve the discovery ? Do you think it is a normal delay for the first time ? – Alarsha Mar 10 '14 at 10:31
  • Sorry, I mean just a Android Smartphone by handset. It can be a normal delay for the first time. But with that knowledge you now can start a 2nd connection attempt right after the failed one. That's something I usually do as well. I try 3 times to connect and then display the user a dialog with [Cancel] [Retry] buttons. What I mean by adviceing you to try different smartphones: BLE is in constant development right now. Every new android update or new smartphone can operate different. Also see my answer to http://stackoverflow.com/questions/17870189/android-4-3-bluetooth-low-energy-unstable – OneWorld Mar 10 '14 at 15:13
  • @OneWorld: When I saw that the discovery has failed, I tried many times to reconnect but it does the same thing, it disconnects me after 2 seconds. I think that the phone doesn't save services if it hasn't complete one discovery, so it will always fail for me. The only solution must be to increase the timeout a little bit. It is not a great solution for me but maybe it is the only one. Thanks a lot for your time and your explanations – Alarsha Mar 10 '14 at 16:29
  • If you are able to increase the timeout then you definitely should do it. You should leave some room for even slower smartphones. 10 seconds is a good number. Do you have the short time out for a reason? – OneWorld Mar 10 '14 at 18:26
  • Yes the device I want to connect to has to be reactive so I can't use it 10 seconds for just a single connection. 5 seconds is already too much. I'm sorry I can't tell much more about it. I increased it to 5 and it works perfectly fine but this why I asked this question in the first place :) – Alarsha Mar 11 '14 at 08:27
  • So we learnt, that 2 seconds is to short for service discovery and 5 seconds might be pretty ok for most of the android smartphones. – OneWorld Mar 11 '14 at 09:24
  • Yes ! 2 seconds is too short the first time. So if we connect to a single device we can do the discovery before so it takes 0.1s after. The discovery on a Samsung Galaxy S4 takes 2.4 to discover and do 3 minor operations so yeah I think 5s is good for most smartphones. And maybe for all of them, do you think the discovery is related to the device performances ? It takes less time on iOS (less than 2s), so maybe it is just the BLE implementation on Android that is limitating the delay and not the device itself ? – Alarsha Mar 11 '14 at 09:35
  • It's purely related on the BLE implementation of your smartphone which depends on many things like chipset, dealing with wifi, priority of certain bluetooth packages, connection parameters, different implementations of different engineers at google, samsung, HTC... Pls. share the build number of your samsung device since the implementation can differ from build to build – OneWorld Mar 11 '14 at 10:12
  • Ok, I tought there was a unique Android implementation of BLE regardless of the device. So BLE is not managed the same way on different phones ? My Build Number (I think) is JSS15J.I9505XXUEMKF – Alarsha Mar 11 '14 at 10:26
  • Hi @Alarsha autoConnection state false also can help you here(will be depend on requirement)..I found this useful when my app require re-connection with same device multiple time. Also can you elaborate "How all other android 4.3+ mob different in terms of BLE"..specially in case of service discovery!!!..any suggestion? – CoDe May 23 '14 at 09:30

1 Answers1

0

Old question nevertheless it needs some insights. You can improve service discovery by some amount by setting connection priority to high after your connection and before you call discoverServices() on BluetoothGatt. Although this is not recommended since it drains smartphone battery quickly. But you can switch back to balanced priority after onServicesDiscovered() is called. So do this on connection.

gatt.requestConnectionPriority(BluetoothGatt.CONNECTION_PRIORITY_HIGH);

and this on onServicesDiscovered(), to switch back priority to balanced.

gatt.requestConnectionPriority(BluetoothGatt.CONNECTION_PRIORITY_BALANCED);

This will improve your service discovery. However, it is important to mention that it will depend on the BLE implementation of the smartphone on the amount of improvement you get.

Sam
  • 2,935
  • 1
  • 19
  • 26
  • @Emil ah Right. Do you have a link to the documentation? I would like to read it. – Sam Dec 03 '18 at 22:48
  • Android's BLE stack's internals are not documented publicly. But you can see the commit that introduced this (I guess) at https://android.googlesource.com/platform/system/bt/+/7fa4fba6f59f97df00aff07dbe8fb21b114b3c2c%5E%21. Search for "L2CA_EnableUpdateBleConnParams(p_clcb->p_srcb->server_bda, FALSE);" which performs the conn param update. – Emil Dec 03 '18 at 23:28
  • This did nothing for me – The Hungry Androider Jan 28 '22 at 17:38