Although undocumented, conventional wisdom using the Android BLE apis is that certain operations like reading / writing Characteristics & Descriptors should be done one at a time (although some devices are more lenient than others). However, I am not clear on whether this policy should apply only to a single connection, or across all active connections.
I've heard that its best to initiate connections to devices one at a time. That might be an example of operations (connect / connectGatt) which should be executed serially among all devices.
But for other operations, like reading and writing Characteristics, is it good enough if each connection executes operations serially, or do I need some global operation queue shared among all devices so that between all devices, only one operation is executing?
x protocol SPEC, when the iPhone/Android phone play as role of BLE central mode, the limitation to have active connection at the same time is up to 8 devices.
Yes it is possible.
The ATT Maximum Transmission Unit (MTU) is the maximum length of an ATT packet. Per the Bluetooth Core Specification, the maximum length of an attribute can be 512 bytes. In reality, it can be slightly larger than this to accommodate the ATT header. On Android, the maximum MTU can be 517 bytes.
When using BLE, an Android device can act as a peripheral device, a central device, or both. Peripheral mode lets devices send advertisement packets. Central mode lets devices scan for advertisements.
On Android, per BluetoothGatt object you should only execute one operation at a time (request mtu, discover services, read/write characteristic/descriptor) otherwise things will go wrong. You have to wait until the corresponding callback gets called until you can execute the next operation.
Regarding having pending connections to multiple devices at the same time, if you use autoConnect=true then there is no problem but if you use autoConnect=false then Android's bluetooth stack will only attempt to connect to one device at a time, meaning it will enqueue the connection requests if there are more than one outstanding. There is one particular bug where it fails to cancel a pending connection that is still in the queue (when you call .disconnect() or .close()) however, that was recently fixed in Android.
Note that there is also a maximum number of connections/pending connections/gatt objects for which the behaviour is completely undocumented what happens when you exceed these limits. In the best cases you simply get a callback with error status but in some cases I've seen that the android bluetooth stack gets stuck in an endless loop where it in each iteration tells the bluetooth controller to connect to a device but the controller sends back the error code maximum connections reached.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With