BluetoothPeripheral dual-mode not available

ceduliocezar commented 3 years ago

As a developer I want to configure the transport used by BluetoothPeripheral during connection phase so that is possible to use the library in a bluetooth dual-mode setup.

Currently the transport is hard coded on BluetoothPeripheral in different places:

[1] https://github.com/weliem/blessed-android/blob/9643ff696659882d6129d3eaf5b80c83c61f1111/blessed/src/main/java/com/welie/blessed/BluetoothPeripheral.java#L1850

[2] https://github.com/weliem/blessed-android/blob/9643ff696659882d6129d3eaf5b80c83c61f1111/blessed/src/main/java/com/welie/blessed/BluetoothPeripheral.java#L1856

[3] https://github.com/weliem/blessed-android/blob/9643ff696659882d6129d3eaf5b80c83c61f1111/blessed/src/main/java/com/welie/blessed/BluetoothPeripheral.java#L1882

_{Legal Imprint (Mandatory for legal reasons, sorry for that)} _{Cedulio Silva cedulio.silva@daimler.com, MBition GmbH, imprint}

ceduliocezar commented 3 years ago

PR #106

weliem commented 3 years ago

Can you explain what the problem is you are facing? This is a BLE library and even if you have a DUAL device, the library should work fine.

Actually, using anything else than Transport.LE, will lead to connection problems with error 133 as a common symptom.

ceduliocezar commented 3 years ago

Hi @weliem thanks for your reply.

I understand that this is a BLE library, therefore the reason why the transport was hardcoded. However, it would be nice to have the ability to specify the transport and be able to connect to a peripheral that is running a dual-mode(BR/EDR transport) without advertising the scanning.

Steps to reproduce the problem

Two phone with blessed, PhoneA (Peripheral) and PhoneB (Central).
Pair phones using pairing from android settings screen.
Install app on both phones and setup blessed with roles accordingly.
Try to connect from PhoneB to PhoneA without advertising/scanning.
It wont work because blessed is hard coding LE as the transport.

To skip the advertising/scanning part it is necessary to use Transport.BREDR.

I tested using Transport.LE and it only works if the peripheral is advertising, which is not the case.

So to sum, the idea is to have a peripheral not advertising and give the central the ability to connect to it without scanning.

ceduliocezar commented 3 years ago

The PR #106 implements what I described in my previous comment. There I kept the Transport.LE as the default value for those who dont need to change it (most of lib users) and for those like that need to change it, it is possible to do it via BluetoothCentralManager.setTransport(Transport), so after calling that function all BluetoothPeripherals created by it will have the transport defined.

ceduliocezar commented 3 years ago

The idea is to join forces rather than create a separated library only for dual mode.

weliem commented 3 years ago

Hi, thanks for trying to contribute, always nice! However, I am still puzzled about this one. I guess you are saying that after using Transport.BREDR you are able to connect? But what are you doing after that? None of the methods like reading/writing characteristics will work for a BREDR connection, since that is a BLE-only thing. So what is the point of allowing a BREDR connection if after connecting you cannot do anything with this library? In other words, why would a BLE library allow BREDR connections if you can't do any BLE related things?

As for your use-case, I think this can all be achieved without changing anything in Blessed. Due to how BLE (and BREDR) works, you will have to scan at least once to find the other phone. You can then use createBond() to pair/bond with the peripheral. What that does is that Android will permanently store the information it needs to reconnect to the peripheral without scanning again. So this can be done using Blessed and leaving the transport parameter to LE.

By the way, using the Settings menu way of pairing only creates a BREDR -level bond and is ignored for BLE. If you use createBond() using this library it will create a BLE-level bond.

ceduliocezar commented 3 years ago

@weliem I had the same assumptions as you before I tested. Since you have multiple points I will go over them separately.

I guess you are saying that after using Transport.BREDR you are able to connect?

Yes, using this Transport.BREDR makes possible to connect two devices using GATT without the peripheral advertising and the central scanning. You just need to create the pairing from settings screen and then proceed with val peripheral = BluetoothCentralManager.getPeripheral(Address) and BluetoothCentralManager.connectPeripheral(peripheral, peripheralCallback) .

But what are you doing after that?

The normal stuff, as soon as the service discovery happens it is possible to read, write, and subscribes to characteristics.

None of the methods like reading/writing characteristics will work for a BREDR connection, since that is a BLE-only thing.

That is not true, among other things dual-mode means being able to use GATT over Bluetooth Classic(BREDR). You can check the GATT documentation from the Bluetooth.com where they are explicitly mentioning the usage of GATT with BREDR https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=229871 .

So what is the point of allowing a BREDR connection if after connecting you cannot do anything with this library? In other words, why would a BLE library allow BREDR connections if you can't do any BLE related things?

The point is to allow the usage of GATT over Classic using this great lib.

In other words, why would a BLE library allow BREDR connections if you can't do any BLE related things?

As I said this is not true, when you say BLE here in this case it means GATT+Advertisement+Scanning. It is possible to use GATT functions while connected via BREDR as mentioned before in this comment. Your library besides covering the advertisement/scan process it also covers in a nice way the general usage of GATT, which is also acessible from Bluetooth Classic in a dual-mode setup.

As for your use-case, I think this can all be achieved without changing anything in Blessed. Due to how BLE (and BREDR) works, you will have to scan at least once to find the other phone. You can then use createBond() to pair/bond with the peripheral. What that does is that Android will permanently store the information it needs to reconnect to the peripheral without scanning again. So this can be done using Blessed and leaving the transport parameter to LE.

That is the case only when you use the Transport.LE, if you use Transport.BREDR it is not necessary to scan/advertise. As I said I forked the library and tested it, I had the same assumption as you, I tried and it didnt worked, but then I figure out this transport configuration which makes it possible.

By the way, using the Settings menu way of pairing only creates a BREDR -level bond and is ignored for BLE. If you use createBond() using this library it will create a BLE-level bond. That is only true when you are using Transport.LE, If you use Transport.BREDR no additional bonding will be necessary.

More over, if you look at the PR that I mentioned you will see that the the normal users of the library wont be affected because the default transport will be Transport.LE, only when necessary the developer can define the transport as Transport.BREDR.

Again, it is true that GATT was lately introduced for BLE, however the dual-mode is there to make it possible to use GATT with Bluetooth Classic (BREDR). I guess this diagram helps to understand the usage of GATT over Bluetooth Classic (Transport.BREDR).

weliem commented 3 years ago

Whooh, amazing. I did some research and it seems you are right!

Never knew this was possible. Will have a look at your PR...

weliem commented 3 years ago

I merged your PR. Thank you!

ceduliocezar commented 3 years ago

I thank you for the great lib =)

I will close the issue then.

weliem / blessed-android

BluetoothPeripheral dual-mode not available #105