So, here’s all I found after reading blogs, threads, documentations, SO answers etc. regarding Android’s bluetooth discovery. Thought this might be useful to post my findings here.

So before someone starts reading, I want to clarify that, I could not find any way to detect a bluetooth device nearby which is turned on but not discoverable.

Detect all nearby Bluetooth devices

My primary target is to detect all nearby bluetooth devices. To do so, we have a BluetoothAdapter class in Android which has a startDiscovery function to scan for bluetooth devices nearby. Hence, this doesn’t serves my purpose, as the bluetooth devices need to be discoverable to be detected by a bluetooth scan by Android. What I want is to detect all Bluetooth devices nearby without forcing them to be discoverable. I started searching for a solution to achieve this goal.

I started with studying Bluetooth protocols and found the underlying protocols used for bluetooth detection, connection and pairing. For Android, I found no API to discover/detect BT devices which are turned on but not in discoverable mode.

Bluetooth devices with class 0x00 are ignored

Digging into this detection problem without forcing the bluetooth devices to discoverable mode lead us to a point where we found Bluetooth device which advertises itself as class 0×00 is ignored automatically while running scan for nearby BT devices. This problem is stated in several places. Here I have listed some.

1. Stackoverflow question
2. Google group
3. Discuss DEV
4. Found in HTC devices

I tried to find a work-around of this problem and yes, I found one, though the documentation and reviews along with this work-around says, it doesn’t work for all kind of Android devices. Anyway, the alternate scan is the same as the default BT scan, but it does some additional works. It reads the Android log after a successful BT scan and check if there’s any BT device is skipped through out the operation. This is a simple hack described here . There’s a google group discussing about the same work-around here.

The work-around above doesn’t solve my problem either. Bluetooth headsets need to be discoverable for being detected by a BT scan. They are not skipped while Android is scanning nearby BT devices. They are simply not found.

Bluetooth Page Scan

However, I started searching for a solution again and found something interesting again! This is from another Stackoverflow answer which says, It is possible to know whether a bluetooth device is around, even if he is in an undiscoverable mode, by knowing his full MAC address in the first place. I’m quoting again from his answer for future reference,

The technique is to try a PAGE request, sending all the 6 bytes that are composing the seeked Bluetooth host MAC identifier. A PAGE request allows one to connect with a Bluetooth slave when knowing his BT ADDR. Devices that are in undiscoverable mode does not respond to inquiry scan (device discovery intent), but they do respond to page scan which is used by a device wanting to connect to an another previously known device.

I found hope and started searching for, how can we initiate a page scan in Android but failed this time too. Couldn’t find any kind of APIs to initiate page scan. From Android documentation of BluetoothAdapter class, I came to know that, when a BT scan starts,

This usually involves an inquiry scan of about 12 seconds, followed by a page scan of each new device to retrieve its Bluetooth name.

There is an indication of page scan in Android documentation, but, surprisingly, there is no other documentation regarding page scan anywhere. I put a Stackoverflow question for inquiry.

Can we “fool” android by appending a list of BTIDs to the “already paired” list?

No, I did not find any way to do so. I read about how Android’s bluetooth pairing works. Here is a nice flow diagram along with detailed reading manual. We were trying to use Android’s hidden APIs and could use some hidden APIs using Reflection. Then we started to look for hidden APIs which we might use to serve my purpose. But, unfortunately, we failed to find any hidden APIs to add a BT device in Android’s already paired list programatically.

Here are some helpful links to check for bluetooth pairing, hidden APIs and how to invoke them via reflection for future reference.

1. How to initiate pairing
2. How to use reflection to work with Android’s hidden APIs
3. Here’s a google group discussion I followed, some people are facing the same problem we’ve here

So I could pair a BT device when it was in discoverable mode and was not in the paired list in Android. In my case, I used a bluetooth headset. It was turned on and put in discoverable mode. The BT Address (MAC address) of the headset was known. So I called the function createBond from my code using reflection and it worked perfectly. The device was added in the “already-paired” list of Android successfully. While roaming around for solutions to serve my purpose I found something interesting…

Interesting observation about already paired devices

I found that, android preserves a previously paired device in its memory even if I remove it from the already-paired list. Let us share a case study along with the findings here for a better understanding. In my case the headset was paired previously.

1. Unpaired/forget the headset from Android
2. Then turned the headset off.
3. Then started scanning for bluetooth devices nearby
4. Of course, the headset was not found
5. But we went through the Android logs and found that, Android remembers the change of bonding state (paring state) of that headset.
6. It scanned for the previously bonded headphone and reported remote device is down

Here is the log that printed along with the MAC address of the headset we paired before and then unpaired.

PREV_BOND_STATE = 11 // BOND_BONDING    (BluetoothDevice.java)
BOND_STATE = 10      // BOND_NONE
REASON = 4           // UNBOND_REASON_REMOTE_DEVICE_DOWN

Then again, I ran the same test, but this time we turned the bluetooth headset on (not discoverable). The headset was not found in this case too, but the interesting thing is, this time a different log was printed.

PREV_BOND_STATE = 11 // BOND_BONDING    (BluetoothDevice.java)
BOND_STATE = 10      // BOND_NONE
REASON = 2           // UNBOND_REASON_AUTH_CANCELLED

The REASON is changed and hence I can understand Android tried to connect with the bluetooth headset. The headset was not in discoverable mode, yet Android could find it and tried to connect with it as it was in paired list before.

This log was printed while a bluetooth scan was running with adding ACTION_BOND_STATE_CHANGED action with intent.addAction.

Can Android be used as beacon?

Yes, but in that case Android needs to advertise itself as a BLE too. This is what new in Android and not all devices support this functionality till now. Here is a list of devices which support Bluetooth LE advertisement capability. But, as Bluetooth LE advertisement has a very low power consumption along with a high performance, I think this will be the next big thing in Android.

Here are some helpful links for future research.

• Can Android act as an iBeacon?
• Android 4.4 as an iBeacon
• Android Beacon Library
• AltBeacon library in Github
• Learning more about AltBeacon
• Rooting your phone to advertise

Helpful functions and libraries for bluetooth operations

• Helpful library for easy Bluetooth operations, named BTWiz.
• Bluedroid – native bluetooth functions
• More about native APIs for bluetooth communication