How many devices we can pair via Bluetooth of BLE to Android? - android

How many devices can be connected to at one time via Bluetooth using the BLE firmware on Android?

A search of the Android Bluetooth Firmware source shows the following:
Max concurrent active synchronous connections (BTA_GATTC_CONN_MAX):
4 on Android 4.3
7 on Android 4.4+
Max concurrent active notifications (BTA_GATTC_NOTIF_REG_MAX):
4 on Android 4.3
7 on Android 4.4
15 on Android 5.0+
As a comparison my experience with iOS is that 8 devices can be connected at at time.
I tried connecting more than 7 devices the other day on Android 7.1 and Bluetooth stopped responding. Starting and stopping didn't help; the only thing that fixed it was restarting the device.
After working with several apps that connect to 4+ devices I can say from experience that these numbers are theoretical. Depending on each individual device and its hardware you'll have an easier or harder time connecting to and maintaining a connection to the maximum number of BLE devices.

Follow Bluetooth at Wikipedia,
A master Bluetooth device can communicate with a maximum of seven devices in a piconet (an ad-hoc computer network using Bluetooth technology), though not all devices reach this maximum.
You need know Master/Slave in Bluetooth first.
I think the good answer depend on your aim.
You're right when you know "can communicate with how many devices" depend on Hardware (Bluetooth Chip).
Bluetooth chip on Apple iPhone 4, 5 or Samsung Galaxy S3, S4 ... totally different with Basic Bluetooth Chip.
In my case :
I'm working with Firmware side related to BLE.
His peripheral device has used Basic Bluetooth Chip since it did not has enough memory to store many capacities as many features, likes Bluetooth chip on Apple iPhone 4, 5 or Samsung Galaxy S3, S4 ....
Therefore, his peripheral device only paired with one device in one time.
Thanks,

Both of the answers here are wanting so I thought I should add one:
There are connection limitations built in to the different BLE hardware. I think the lowest I've encountered is 3 connections at once and the highest was about 12-13 connections. These were limitations due to the design of the hardware and had nothing to do with the OS being used, though. Usually the limitation is due to the fact that the hardware has to keep track of certain data and there's a limited amount of memory in the hardware.
So, I don't know specifically for Android, but it doesn't make much sense for a limitation to be imposed at the OS level. Likely when you try to make a connection, and you've reached the limit due to the hardware, you should receive some sort of error/exception preventing the new connection. I think there's actually a "connection limit" error in Bluetooth, but some hardware gives other exceptions like "out of resources". Again, I'm not sure how that gets reflected on the Android level.

I come into BLE development without any knowledge in Classic Bluetooth development and I really don't know what "pair" means in BLE. Isn't that something only exists in Classic Bluetooth?
If you are talking about connection, when Android 4.3 first came out I made a few test on the SDK on Nexus 7 2013. The maximum number of devices it can connect is 4. I didn't test if this number changes in 4.4, but I can confirm it will not be anything less than 4.

For every system, be it any firmware or OS like Android or iOS, there is a configured maximum concurrent connection limit. But in reality the connection parameters of each connection play a very important role in determining weather or not the system will be able to achieve that many concurrent connections.
For example, if the configure connection limit is 4 then the system can not have more than 4 concurrent connections. But if all of the connected devices are demanding a higher connection interval(say a 50mS connection interval) then the system may not be able to support all of them. This results in either some of the connections dropping out or not being able to connect entirely. But if the connection parameters are a bit relaxed(say a 1sec connection interval) then all the connections can be serviced properly.

Related

What is the best way to connect multiple android and android wear os devices in a local network?

We are developing an application that should collect data from multiple Wear OS smartwatches and show the collected informations from all the smartwatches on one Android device.
The aim is to find a solution that does not need the presence of the smartwatches' paired phones, so that the users could leave their phones away.
The other requirement is to avoid the use of internet, so that the application could work even in remote areas or where there is no WiFi hotspot for the smartwatches.
I have found Android Nearby Connections API that seems a good choice when you want to develop a local area network application, but it seems that this API is not compatible with Android's Wear OS. (Even though I am not sure about that...)
I am not sure that Bluetooth could accomplish the task of connecting many devices together, as I read about protocol limit and hardware limit that takes to a maximum of 7 devices connected and only 1 device active per time.
Also, the android docs about Bluetooth connections seems to reference about connection between android and devices, more than android and android.
I am not sure that WiFi direct would work, and, from what I understood, BLE works only for very limited amount of data (in the order of the bytes, we need at least a rate of 1 or 2 kbps, but maybe it would be enough) and I am not sure that would work to connect more android devices together.
So the question is: what is the best solution to create a local area network between one android device (acting as a server / central node) and multiple andoid wear os devices acting as clients / sensors?

Maximum Concurrent Bluetooth LE Devices on iOS and Android?

I am looking for definitive values for the maximum number of concurrent BLE devices you can connect to on both iOS and Android. I have done my own research and testing and it is not consistent. The Bluetooth LE spec does not limit the number of simultaneous connections, but the platforms have added caps due to memory constraints.
On Android 7 I was able to connect to 22 BLE peripherals simultaneously. One Android 9, I was only able to connect to 12 BLE peripherals at a time. And on Android 10 I have at times been able to connect to 12 BLE peripherals simultaneously and the same setup could connect to 14 BLE peripherals simultaneously at other times. All of this testing was on Samsung Galaxy Tab 10 hardware.
iOS is a similar story. I have been able to connect to 8 BLE peripherals simultaneously on iOS 9, 12 BLE peripherals simultaneously on iOS 10, 11, and 12, and 15 BLE peripherals simultaneously on iOS 13. I have not tested iOS 14, yet. This testing was done on iPad Mini 2s, iPad Mini 5s, and iPhone 7+s with the same results on all hardware. Others on this site claim to have seen as many as 20 concurrent devices on iPhone 6S with iOS 10 - I cannot confirm that.
I have seen lots of similar numbers from others' testing and some have even referenced documentation from Android and Apple calling these values out. I have not been able to find anything in the documentation from the last few releases of Android or iOS that call out these maximum values.
Could anyone help point me out to the true, documented values? Thanks!
The sad truth is that there are no documented values anywhere to be found, for most devices. The manufacturers don't state the Bluetooth limitations anywhere. When the product goes through Bluetooth certification and declaration, it however needs to specify every single supported Bluetooth feature supported, but not how many connections it can handle.
The BLE spec does not state any limitation, so it's up to the Bluetooth implementation to decide.
First, the Bluetooth chip (controller) usually has its own restriction. The HCI does not expose any functionality to query the maximum number of connections, so the host stack does not know what the controller's limitations are. First when the maximum is reached and the host tries to connect another device, the controller will return an HCI error code of maximum connections reached.
All Bluetooh chips have unique limitations. They usually range from somewhere between 3 to 20, as you have noticed. This limitation is more important than the specific OS and version the device runs.
Now if we look at the Android Bluetooth host stack, it has a hardcoded limit of 7 connections the last time I checked the source code. So in Pixel and Nexus phones, which run the "vanilla" Android, the limit will be 7, even though the Bluetooth chip can itself handle more (I've recompiled AOSP with an increased limit and verified this on Nexus 6P). I've seen that other manufacturers, such as Samsung, increase this limit to match what the Bluetooth chip actually supports.
Anyway, looking at specific OS versions will not give any useful information; you must test each device individually.

Android: Limit of simultaneous BLE connections

we are developing an Android app which can connect to multiple heart rate sensors simultaneoulsy via Bluetooth Low Energy.
We have an implementation which is working quite well, so the code is not the problem.
What drives us crazy is the limitation of parallel BLE-connections which seems to be different from device to device.
We have a few test devices here: Motorola MotoE and MotoG, a Samsung Galaxy Tab A and an HTC Nexus 9. All of them are running Android 5 or 6, original vendor versions. None of them is able to connect to more than 7 BLE HR sensors simultaneously.
Then I have tested with my private Samsung Galaxy S4, which is rooted and has Cyanogen CM12 installed. With this device I can easily connect to 12 HR sensors simultaneously which is the number we want to achieve with our app.
I have tested this both with our own app implementation and with the Nordic Semiconductor nRF Master Control Panel which I think is a pretty good generic BLE app: https://play.google.com/store/apps/details?id=no.nordicsemi.android.mcp&hl=de
When I try to connect the app to a 7th BLE sensor on any of our devices, the ADB output prints the following error message:
E/BluetoothLeBasicConn: Connection state changing error: 133
I did some pretty intensive googling about that whole problem, but most of the results I've found were quite old. Some people said, that the limitation came from the Bluetooth Chipset itself, others said it was a software limitation through Android.
Could you help me to find out, where the limitation is coming from?
If it is the chipset, then I would like to know, which devices we should use for supporting as many parallel connections as possible. Sadly it is very hard to find out which Bluetooth chipset is built in the different devices. Hardly any of the hardware specs I found tell anything about this.
If the limitation comes from software side, can we change it somehow without rooting phones or install modded OS?
Thank you very much!
In case that you are still interested in it. The limit comes from
BTA_GATTC_CONN_MAX (hardcoded in android)
Which is set to:
4 on Android 4.3 and
7 on Android 4.4
There is by the way also a limit on the amount of characteristics for which you can activate notifications. (BTA_GATTC_NOTIF_REG_MAX)
which is:
4 on Android 4.3,
7 on Android 4.4 and
15 on Android 5.0

Possible to hack BLE peripheral mode support in Android?

This blog post from radius networks discusses how Android devices can not yet be used as iBeacons (AKA: BLE peripheral mode) even if the device's hardware supports BLE, because Android has no APIs for BLE peripheral mode.
NOTE: BLE means Bluetooth Low Energy
After reading this section, I am gonna suggest something stupid
Because their SDK only supports the central role, “advertising” a
service as a central server means sitting their quietly, only
revealing (or “advertising”) its service characteristics to another
device in peripheral mode after a connection is already established.
This connection establishment requires another device to do the actual
radio advertising first. Samsung’s SDK isn’t going to do it.
Is it possible to trick the device in central mode (the Samsung phone) into thinking another device in peripheral mode has established a connection to it and then get the central mode to "advertise". Can you trick the phone by faking the connection in software?
Probably a stupid idea, probably it's possible to trick the device in central mode, but the "advertisement" is not the BLE peripheral mode advertisement and would not resemble an iBeacon in peripheral mode.
I very much need BLE peripheral mode support from Android and for the moment I would be ok with hacking something, in the hopes that Android is going to eventually support this feature-set, which BTW is already a feature request
I don't think this technique will work, even if it is possible to "trick" Android into thinking it has a connection to another BLE device. Although this question is about the Samsung BLE SDK, I think the same answer applies to the dedicated Android BLE APIs (android.bluetooth.BluetoothAdapter) that shipped starting with Android 4.3.
Let's put aside the tricking part for a minute -- even if Android's actually does have a connection to another BLE device, can you make it advertise? If by "advertising" you mean revealing its services to the other device, the answer is yes. But this radio transmission is over a private channel between the two devices, and could not be picked up by a BLE scan in the same way that iBeacon advertisements are. It really isn't an advertisement at all -- which is why I said in the blog post that the Samsung documentation is misleading. So if you can't do this with a real connection, then tricking a connection won't work either.
My understanding of bluetooth stacks is limited, but I think that the actual radio broadcast advertisements that scans can pick up are controlled by the hardware BLE chipset, which means you have to have access to the parts of the bluetooth stack that tell the hardware to make this happen. I don't think there is anything in Samsung BLE SDK or the Android SDK that intentionally allows this.
An alternative may be to make direct JNI calls to the BlueDroid stack. I'm not sure if Android permissions allow this, or if advertising is even implemented in the BlueDroid stack.
UPDATE: Transmitting as a pheripheral now possible in Android 4.4.3 and Android L. See here.

Motorola and Bluetooth Low Energy with custom Bluetooth Low Energy client device

I need to develop an Android application handling the data from a custom built Bluetooth Low Energy client device.
After researching it seems that the best option is to use the API's developed by Motorola for their Android smartphones, but it looks like the Motorola Bluetooth Low Energy API is made to connect only with Motorola bluetooth devices, from the link:
applications can use [the Motorola Bluetooth Low Energy API] to interface with Bluetooth LE (Low
Energy) profiles implemented by certain Motorola Mobility devices
Besides the above mentioned API, there is the Motorola Bluetooth Low Energy GATT Framework API, but it is unclear to me whether it is applicable for my needs.
Can anyone here tell me how these API's can be used to achieve my goal or whether there are other options that I haven't realized yet?
Android options for BLE are limited, and this answer may be different at any given point in the future.
Motorola API will only work for Motorola phones. The GATT API will allow you to push data to the GATT and transmit it via ble. HOWEVER Motorola has ONLY extended the HRM profile. Additionally the API stopped working on devices that were updated to ICS (as of 10 days ago this is still the case). They are working to update the API as well as possibly extend the profiles beyond HRM. There have been people that have simply leveraged the HRM profile to shuttle data, but there is currently a 2 octet limit.
There are additional bugs that have been reported as well, that are also supposed to be fixed in the post ICS updates. However since it took them a year to get ICS out to their headsets and all of the Motorola apps are still working, who knows when they'll update the API's.

Categories

Resources