Scan failed with unknown error (errorCode=-99)

[mannodermaus]

Expected behavior

The user's device is able to scan for beacons after updating to 2.13.1.

Actual behavior

The user's device can't start scanning for beacons at all since updating to 2.13.1.

Steps to reproduce this behavior

Unclear, since I don't have access to this device. However, it seems to be a hardware limitation of that particular model or series, based on some prior investigations.

Mobile device model and OS version

Samsung Galaxy J (SC-02F), 5.0

Android Beacon Library version

2.13.1

---

First of all, thank you for the great work on this library!

We have received a report from one of our users, who can't scan for beacons at all with their device after updating to the latest version of our app, which increased its AltBeacon dependency from 2.9.2 to the version mentioned above. Prior to the update, we can see that they were able to detect beacons correctly. The user's application logs show the vague error code -99 repeatedly, which causes the scan to not start.

It was pretty trivial to find a bit more information about this error, which led to a similar issue on another BLE SDK's Issues page. The description of the maintainer fits the device in question here, since it's also a Samsung device running on a similar API level, and they tracked it down to limitations regarding the scanning filters on this kind of device. They recommend to check for started scans that aren't stopped properly. However, since altbeacon abstracts the repeated start/stop cycles away with its start/stopRangingBeaconsInRegion API, I'm at a loss trying to figure out where the integration might fail. I can verify that the application only calls each of those methods exactly once, and the intermediate scan operations are performed by the SDK itself.

I'm attaching an excerpt of the user's logs related to BLE. Unfortunately, I can't ask the user to provide more detailed logs with enabled verbose logging, so I'm aware that this might not be much to go off of.

2018-05-15 15:24:38.064 BLE (i): This is Android 5.0. We are using new scanning APIs
2018-05-15 15:24:38.095 BLE (i): beaconService version 2.13.1 is starting up on the main process
2018-05-15 15:24:38.143 BLE (w): Cannot find match for this device. Using default
2018-05-15 15:24:38.145 BLE (w): Cannot find match for this device. Using default
2018-05-15 15:24:38.149 BLE (i): binding
2018-05-15 15:24:38.965 BLE (i): start ranging received
2018-05-15 15:24:39.117 BLE (e): Scan failed with unknown error (errorCode=-99)
2018-05-15 15:24:41.142 BLE (e): Scan failed with unknown error (errorCode=-99)
2018-05-15 15:24:41.452 BLE (e): Scan failed with unknown error (errorCode=-99)
2018-05-15 15:24:42.456 BLE (e): Scan failed with unknown error (errorCode=-99)
2018-05-15 15:24:43.548 BLE (e): Scan failed with unknown error (errorCode=-99)
(...)

A few more pieces of information about our configuration:

• BluetoothMedic#enablePowerCycleOnFailures()
• BeaconManager#setForegroundBetweenScanPeriod(100)
• BeaconManager#setScannerInSameProcess(true)
• BeaconManager#addRangeNotifier() hooks in 1 listener

Thanks in advance!

[davidgyoung]

Thanks for this well-documented report, @mannodermaus

I believe the problem is an issue with scan filters not being supported by this device or not being recycled by this device after scans are stopped. The issue was probably introduced by this PR, which fixed an 8.1 scanning limitation by adding empty scan filters:

#637 (comment)

Two thoughts on fixing this by modifying the above change:

1. We could only use the empty scan filter on 8.1+

2. We could look for a -99 error and disable scan filters if we get one.

I'm not sure which is better. Option 1 might keep a similar problem happening on 8.1+ devices. Option 2 might let a similar problem happen if a slightly different error code is returned on other devices.

[mannodermaus]

Thanks for the quick response! Your observation sounds reasonable - if the newer versions of AltBeacon add empty scan filters at regular intervals, it will probably hit the limit on this class of devices after some time. About your Option 2, I don't exactly know how the Bluetooth stack behaves after it reaches the dreaded error state, and if it is corrupted for good once it hits the limit. What would "disabling scan filters" look like - aren't they removed after the scan operation is done? Other than that, Option 1 would probably solve this particular issue at least. But you're right in saying that we can't really know if there isn't a weird phone running 8.1 with this hardware limitation out there. Just based off the small sample size, at least the two devices we can reference are running 5.x, but I'm unsure if this is enough to go by...

[davidgyoung]

I'm a little reluctant to put in a change like this without knowing its effects. @mannodermaus what are your thoughts on pushing an app update with just this change to the library to see what results you get? I'm not sure how you are getting the feedback from your users in this case. Ideally, I'd like to be able to determine of the change has any detrimental effects on others.

[mannodermaus]

I agree that blindly implementing a "maybe-fix" into the library without any proof or verification can be detrimental, and we shouldn't go that route. I'll reach out to the user in question and ask for their participation regarding this, so I can't say right now if they are going to be interested in helping out or not. In any case, let's go with preparing a special build of the library with this change in place - we're currently checking the prominence of this particular device type, and we might just outright buy one of them if the impact is decided to be significant enough to our clients.

[davidgyoung]

@mannodermaus, please find a test release with usage instructions here:

https://github.com/AltBeacon/android-beacon-library/releases/tag/2.14.1-beta1

Please let me know if you can have your client test a build of your app with this change, or if you can get a device to test on yourself.

[mannodermaus]

Thank you for providing the modified library. I communicated back to the user, and they are willing to give it a go and participate. I'll prepare a special variant of our application to them, and will report back as soon as I have some more results for you!

[mannodermaus]

Update: The user can successfully scan for and connect to beacons with this modified version of the library! It looks like the scan filter buffer on that device really did fill up after a while, and the phone stopped connecting.

Now, the question is if we can reasonably rule out that your previously mentioned Option 1 can't happen on 8.1+ devices. From my findings, this problem is prevalent on old, "circa Lollipop era" Samsung phones. Personally, I'd say that the fix could be integrated as is, although it's up to you to allow an opt-out via a configuration parameter, of course.

[davidgyoung]

Glad to hear it worked, @mannodermaus. I agree this is the best fix we know of. Any alternatives are riskier and harder to test.

[davidgyoung]

Fixed in #693

[mannodermaus]

@davidgyoung, I wanted to reach out again to inquire about any plans to publish this change in the next version of the library. Do you have a timeline for when we can expect to use this fix in a stable release?

[davidgyoung]

Hi, @mannodermaus. I just published a 2.15 release that includes this change.