On the Edge of the Network

Single post

A Fix for the “Bluetooth Share Has Stopped” Error

At the Wearable Worlds’ hackathon event this past weekend, I encountered problems with the Bluetooth functionality on my Galaxy Note II. Specifically, I was encountering force close errors (“Bluetooth share has stopped”) while testing out the iBeacons with the FLUX Android app that our team was developing.

After doing some Googling on the issue, apparently there’s a significant bug on Android 4.3 – 4.4.2, in which the BLE module is unable to store any MAC addresses after a certain point.

David G. Young, a developer over at Radius Networks, explains the issue throughly:

Lots of folks using iBeacons with Android devices have been suffering from repeat error dialogs saying “Unfortunately, Bluetooth Share has Stopped”. These annoying dialogs are caused by low-level bug #67272 in the Bluedroid stack, which is a layer between the operating system and the Bluetooth hardware.

While the bug has been around since Bluedroid was put into Android 4.2 over a year ago, reports only started commonly showing up recently. Today, some folks report that the dialog appears so frequently when doing Bluetooth LE scans, that the technology is effectively unusable. What changed?

Some companies are now distributing beacons that are a significant cause. By default, the beacon shown below has a proprietary security feature that rotates its Bluetooth MAC address every 0.8 seconds. This creates big problems for Android devices doing Bluetooth scans. Due to the bug mentioned above, Bluedroid can only handle seeing 1,990 different Bluetooth MAC addresses before the Android BluetoothService crashes. This might take months or years under normal conditions; however, Qualcomm Gimbal beacons (shown below) spit out a new MAC address every 0.8 seconds which crashes Android in just 42 minutes. To be fair to Qualcomm, this is not a Gimbal problem. It is an Android problem.

What’s worse is that Android periodically saves its list of recently seen Bluetooth devices to internal storage, and reloads it after a crash. Eventually, this stored list will contain all 1,990 allowed MAC addresses, causing the Android BluetoothService to crash as soon as it sees a single new device. Once this state is reached, Android devices are completely unable to scan for new Bluetooth LE devices without an immediate crash of the BluetoothService. Lots of frustrated users have reported having to do a factory reset to clear the condition.

Radius Networks – A Solution for Bluetooth Crashes

While David mentions that a factory reset will fix this issue, it’s not really an ideal solution, as (anyone knows) a factory reset can be cumbersome and time-consuming. Aside from performing a factory reset, Radius Networks has an app on the Google Play Store (BLE Crash Resolver) that addresses this issue. However, it seems to be “hit or miss”, as it fixes the “Bluetooth share” issue for some and fails for others. Unfortunately, BLE Crash Resolver did not work for my Galaxy Note II running on Android 4.3.

At that point, I had almost committed myself to performing a factory reset, but fortunately, I had found another solution here.

I temporarily fixed this problem by doing the following:
1. Root your phone and install a file explorer, such as Root Explorer.
2. Turn off Bluetooth.
3. Open your file explorer and mount the filesystem as read/write. Navigate to {root}/datamedia/misc/bluedroid.
4. Make a backup of the file bt_config.xml.
5. Open bt_config.xml in a text editor.
6. The tags between <N2 Tag=”Remote”> and the corresponding </N2> are the cached Bluetooth devices. Delete them. Save the file in place and return to the folder.
7. Delete the file bt_config.old.
8. Rename bt_config.xml to bt_config.old.
9. Turn Bluetooth back on.
10. Check your Bluetooth settings. If all your paired devices are gone, the fix worked. Otherwise, repeat from step 4.

On the commit section for iBeacon, ZackFreedman posted a detailed list of steps to resolve the BLE crash issue. Zack’s solution involves editing the bt_config.xml file in the root/datamedia/misc/bluedroid folder and removing all the registered MAC addresses from the file. Once done, Bluetooth functionality should work normally without any force closes. Please note that this solution requires you to have ROOT access on your device, as you need the proper permissions to access and edit the bt_config.xml file.

It’s not a permanent solution, as the issue will pop up again if you hit that 1,990 MAC addresses limit, but at least this solution will get your Android device back in working order without having to perform a factory reset. It certainly worked great for my Galaxy Note II, as I am no longer encountering the “Bluetooth share has stopped” issue. Kudos to ZackFreedman for this fix.

Write a Comment