First, please pardon me if the question is close to some topics of other threads. I searched previous topics but as I'm not a programmer/technician, I could not be sure they answered my question exactly.
In fact, I'm wondering whether it is possible to develop an application on iOS or Android that would scan for Bluetooth devices around (in particular, other Smartphones with Bluetooth enabled) and gather all their UUIDs.
Is there a constraint (such as a preliminary pairing) required?
Could the other devices have their screen locked / off, as long as Bluetooth is enabled? After some basic tests just trying to discover an iPhone device from my Windows Phone (from the user interface, not programmatically), I realize that the iPhone disappears from the Windows Phone list as soon as its screen turns off; still, it is recognized in my car (with which it is paired) even though its screen is off.
Are there constraints relative to the Bluetooth version? I read on this website that iOS does only discover Bluetooth 4.0 devices.
In summary, I need an app that would run on iOS and Android and which would be able to scan for all other mobile phones with Bluetooth enabled and gather their UUID, irrespective of their current status (idle, screen off, ..).
Thank you in advance.
Best
Related
Before you mark this as duplicate, there have been so many questions on SO asking about how to connect Android to iOS over bluetooth. Many of the answers say it isn't possible, or it wasn't possible, or it might be. They are also quite a bit old. This question is about answers from actual practice.
I've done extensive research and found plenty of articles saying it is and isn't possible, but it seems like it should be, especially with Bluetooth Low Energy.
So here's my simple Yes/No question: When making an iOS device broadcast as a Peripheral using CoreBluetooth, have you ever been able to connect an Android device as a Central and exchange data?
Yes it is possible. I wrote a test using an iPhone 5 running 8.1 and a One Plus One running Lollipop. The iPhone advertised a custom service and characteristic, the Android connected to it and retrieved the value of the characteristic.
Interesting observations:
When the iPhone app was advertising in the foreground the Android could detect it when doing a scan only for the specific service uuid, and it would work every time.
When the iPhone app was advertising in the background the Android could only detect it if it was doing a generic scan for all devices, it had to connect to every device it could find to see if it contained the correct custom service uuid. And even then it only worked sometimes. I was quite surprised that the iPhone service could be detected at all when it was advertising in the background, considering on the iOS developer site it says peripherals advertising in the background can only be detected by other iOS devices looking specifically for that service.
If I make one device (e.g. Android tablet) indefinitely discoverable and make a second one (e.g. phone with BL 3.0 support) search for devices, it seems like I'll be able to extract server device name (http://developer.android.com/guide/topics/connectivity/bluetooth.html). By device name, I can deduct where in the world is the second device. What is wrong with sucn an approach? (I'm completely new to Android, just validating feasibility of some idea).
The problem with BLE is - 70% of android devices still have OS version < 4.3.
You can certainly do it within limits - I have some software running on my Mac that automatically locks the screen when my Bluetooth phone goes out of range. It doesn't use BLE.
One issue that you will have is the power consumption is greater than BLE, so battery life may be affected.
Another is that as the transmit power of the older Bluetooth can be higher than BLE you may find that the devices stay "in contact" for longer than you would like - It can certainly give you an idea of 'proximity/presence' although not really 'location'.
Also, if you pair the devices then they should be able to scan for one another without needing to be 'discoverable' - this is the approach used by the Mac software I mentioned. I am not familiar enough with the Android BT APIs to know whether you can detect a paired device but then not connect.
Also, taking the device MAC from the advertisement rather than name is probably 'safer' - A user may rename their device, but they won't change the MAC.
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.
I am trying to detect my iPhone on my Android 1.6 device using Bluetooth without interaction.
I can do it when the iPhone is discoverable, meaning I have to interact with the iPhone, going through menus to Bluetooth section.
For what I have searched so far, it's seem impossible to detect the iPhone, even if it has been previously paired (paired is only a kind of shortcut to avoid the heavy discovery process).
Does anyone know any solution ?
Thanks
Antoine
In my experience, if the iPhone goes out of range or otherwise disconnects a BT connection, there is no automatic reconnect, you have to go in to the BT menu in the iPhone.
I have not worked on iPhone vs android on this, but I know a lot of the car stereo and gps manufacturers are having problems with the iPhone not reconnecting automatically.
At the moment they don't have a solution, so I doubt there is one.
Short edit for clarification: This is not an android problem, I work on BT certification and licensing, and android can drop a connection and reconnect automatically. (Under the condition that the phone supports that BP profile, but they all do.)
I'm contemplating the development of an Android app that detects all or most nearby mobile devices (iPhone, Android, etc) in the immediate neighborhood that are turned on. I don't need to interact with these devices, just detect them, and a requirement is that the detected devices can't need to have any special / unusual apps installed on them. The app only needs to work for typical U.S. devices and networks.
I've thought about a few ways to do this (somehow detecting bluetooth, wifi, or cellular transmissions / identifiers), but I'm looking for specific implementation methods for a way to detect a relatively large proportion of nearby devices. I'm not sure which of these methods is possible / feasible or how to put them into practice...
Perhaps using Bluetooth: Is there a way using the Android SDK to detect non-discoverable Bluetooth devices (not in discoverable mode)? The Nokia Developer site seems to suggest this is possible using Service Discovery Protocol (SDP), but I'm not sure if this is possible more generally in Android.
Perhaps using cell tower mast switching simulation? Ok, this is almost certainly beyond the reach of Android, but this article suggests that there may be a way to "mimic cell mast switching process to trigger quiescent phones into transmitting. Phones respond with their ID and authentication signals...".
I think you should see this, it is a paper, and you cannot view it for free, but in the summary, it clearly states:
Concerns about Bluetooth device security have led the specification of the “non-discoverable” mode, which prevents devices from being listed during a Bluetooth device search process. However, a nondiscoverable Bluetooth device is visible to devices that know its address or can discover its address. This paper discusses the detection of non-discoverable Bluetooth devices using an enhanced brute force search attack. Our results indicate that the average time to attack a non-discoverable Bluetooth device using multiple search devices and condensed packet timing can be reduced to well under 24 hours.
But for an android application, you need the detection time to be well under a few seconds instead of less than 24 hours, so a practical solution may not yet be available.