AltBeacon Library startLeScan of BluetoothAdapter and stopLeScan halts the UI thread.

[sanikaj]

I observed every time the StartLeScan of the BluetoothAdapter occurs the UI hangs for a while and so is the same on the StopLeScan. It is similar to the Estimote App issue people were facing. Link of the estimote app is as below:
Estimote/Android-Fleet-Management-SDK#85. It does it both to the One Plus and the Nexus 5 device.

OS Version: CyanogenMod 4.4.4 (One Plus) Nexus 5 (5.0.1)

Devices tested: One Plus,Nexus 5

[yo-epicdavid]

I have the same issue 😟

[davidgyoung]

Can you please post sample code and steps to reproduce? This sounds like scanning is happening on the UI thread but I have never witnessed this myself on the Nexus 5, Nexus 9 or Moto G.

[tomacco]

I have experimented the exact same issue with Cyanogenmod 11.
Checked with Android Device Manager and indeed, bluetooth scanning was running on the UI Thread. I have switched to OmniROM (KitKat as well), and issue has disappeared...

[maxsof]

The issue was reproduced on the Motorola Droid Ultra 4.4.4 and Moto E 5.0.2
I guess it can be forced by another bug https://code.google.com/p/android/issues/detail?id=65455
Because when "GKI_exception: out of buffers" exception appears and beaconManager.startRangingBeaconsInRegion() starts to block the UI thread.

To reproduce "GKI_exception: out of buffers" just keep bluetooth scanning for a night.

[lkwjohn]

Have this issue been fixed? I am experiencing similar event that is blocking the main thread (list view) for Android on Nexus 5 as well.

[davidgyoung]

I think there may be a number of different issues here, which may result in a similar symptom of laggy UI when scanning for beacons. Multiple possible sources of a problem include:

• Device or device firmware-specific BLE implementation
• The Android OS version
• The Android Beacon Library version
• Application-specific implementation details

In order to get a good reproducible test case that eliminates application-specific differences, it would be great to get steps to reproduce using this library's reference application, and documenting the specific Android version and library version used to reproduce the problem and how it is determined that the UI thread is blocking.

It is possible that some of these reported cases may be due to application-specific implementation issues, if you think there is a chance that is the case, I'd suggest posting a question on StackOverflow describing the specific problem and showing the code that processes the beacon detections starting with the ranging callback.

[marcosalis]

I am experiencing the same issue with AltBeacon version 2.8.1, it happened on a Motorola XT1080 Droid Maxx with Android 4.4.4 and I think I might have identified a potential reason for this to be happening.
As we all know, the BluetoothAdapter implementation in Android were terrible up until a few years ago. If you look at the source code of that class in Android 4.4.4 you'll see lots of explicit synchronization, with nested synchronized blocks using different lock objects, which is generally risky and very deadlock-prone.
It always struck me how they state "This class is thread safe" in the BluetoothAdapter header documentation, but what they should really say is "This class should be used off the main thread".

In particular, this is the method trace on the main thread in the moment several ANR were triggered by the application that's using AltBeacon:

Thread main
Handler.dispatchMessage
Handler.handleCallback
CycledLeScanner.scanLeDevice
CycledLeScannerForJellyBeanMr2.startScan
BluetoothAdapter.startLeScan
BluetoothAdapter.startLeScan
BluetoothAdapter$GattCallbackWrapper.scanStarted
BluetoothAdapter$GattCallbackWrapper.waitForRegisteration
Object.wait

Taking a quick look at CycledLeScannerForJellyBeanMr2, you could see that there are cases where 'scanLeDevice(true)' is called from the main thread (deferScanIfNeeded(), line 35):

            mHandler.postDelayed(new Runnable() {
                @Override
                public void run() {
                    scanLeDevice(true);
                }
            }, millisecondsUntilStart > 1000 ? 1000 : millisecondsUntilStart);

The Handler used is using the main thread Looper, since it's initialized when CycledLeScannerForJellyBeanMr2 is instantiated, which is from the BeaconService.onCreate() method.
I don't know if this is intentional or a bug in the library, but it would definitely be better if all the BLE scans (or at least in Android < Lollipop) were started off the main thread, posting then the result callbacks back to it via a Handler.

[cupakromer]

Can this issue be closed now that #430 is merged?