0

Scenario:

Given, a device which is always turned on, and does a Bluetooth Low Energy advertising every second.
I have to implement an application for Android tablets which connects to this device via Bluetooth Low Energy, sends some commands and then disconnects from it.
Minimum Android version: the one which works best, I'm free to decide. I started with API 21 (Android 5.0, Lollipop)

Issue:

The issues the BLE stack has, caused trouble also for me: I'd like to issue a successful direct connection using the object retrieved by BluetoothAdapter#getRemoteDevice(MACAddress: String) method, and it always fails.

Results of my research:

Below are the questions / answers / posts that I've found and seems useful (maybe these will help someone):

Questions:

Beside these, I looked into the BluetoothDevice's source code, and I've found out that the Context parameter of the connectGatt() method is not used at all:
https://android.googlesource.com/platform/frameworks/base/+/master/core/java/android/bluetooth/BluetoothDevice.java#1899
Wondering if can this be one of the reasons of the flaws the BLE stack has?

Also, I don't understand what is the difference between a BluetoothDevice object retrieved by the scanner vs the one retrieved by BluetoothAdapter#getRemoteDevice(MACAddress: String) method.
If I issue a direct connection (autoconnect parameter is set to false when calling connectGatt()) on the device got via scanning, the connection usually succeeds. But, a direct connection always fails (status = 133, timeout) when using the object retrieved by getRemoteDevice().

As the device I want to connect to advertises itself every second, I expect the direct connection to always / most of the time work, like in the case of scanning.
Because the background connection (autoconnect parameter set to true) is very slow, I cannot rely on that.
Also, because the scanning is unreliable and slow, I cannot force the user to wait every time the application starts.

To summarize my questions:

  • The Context parameter of the connectGatt() method is not used at all - can this be one of the reasons of the flaws the BLE stack has? I suppose someone put it there for a good reason.
  • What is the difference between a BluetoothDevice object retrieved by the scanner vs the one retrieved by BluetoothAdapter#getRemoteDevice(MACAddress: String) method?
Community
  • 1
  • 1
Robert
  • 15
  • 5

1 Answers1

1

  1. The context parameter was used in earlier Android versions but apparently wasn't needed anymore. You should still pass a valid context to be compatible with earlier versions, or newer if they decide to make use of it again.

  2. There shouldn't be any difference. But if you just connect by Bluetooth Device address, you will notice the flaw in the API that you cannot pass the address type (public or random). So if you try to connect to a static random address, that will probably fail unless you have first scanned the device. This is because Android keeps a cache of a addresses and which address type it had in the latest advertisement. So try to first scan and make sure you see the device you want to connect to. Then try to connect using BluetoothAdapter#getRemoteDevice(MACAddress: String).

Emil
  • 16,784
  • 2
  • 41
  • 52
  • Thank you for you answer. I'd like to ask you, out of curiosity, why does setting the address type help in establishing the connection? – Robert Apr 30 '18 at 07:15
  • How do you mean? The Bluetooth controller needs the full address (49 bits) in order to connect. If one just guesses the address type, one might end up trying to connect to the wrong device, which apparently won't work. – Emil Apr 30 '18 at 15:50