Background Scans on Android9 Samsung Devices

Hello and first of all, thank you all very much for this library.

Expected behavior

I use a foreground service for scanning for beacons, with a notification. I am using BLE Beacons as a Geofence. Fortunately I have many devices to test. The application works perfectly fine with Pixel3 (Android Q), Xiaomi Mi9SE (Android P), Oneplus 7 (Android P), Xiaomi Pocophone F1 (Android P), Motorola G6 (Android O).

Actual behavior

The beacon scan on Samsung Galaxy S10 and Galaxy Note 10 works fine if the screen is on. However the scan stops immediately if I turn the screen off, only to resume if it turns on again, even if the device is locked. Those two are the only phones where I see this behaviour.

Steps to reproduce this behavior

The same problem occurs with the beacon reference application. So by uncommenting the code for the foregroundservice, you can reproduce this issue using a Galaxy S10 or Note 10 and trying to turn the screen off - the phone won’t receive beacons any more.

setDebug(true) shows the following when in background:

D/IntentHandler: got ranging data D/CycledLeScanner: Waiting to stop scan cycle for another 97 milliseconds D/CycledLeScanner: Done with scan cycle D/ScanHelper: Beacon simulator not enabled D/ScanHelper: Calling ranging callback D/Callback: attempting callback via local broadcast intent: org.altbeacon.beacon.range_notification D/CycledLeScanner: Not stopping scanning. Device capable of multiple indistinct detections per scan. starting a new scan cycle We are already scanning and have been for 54231 millis D/CycledLeScanner: Waiting to stop scan cycle for another 1100 milliseconds Scan started

Mobile device model and OS version

Test device is a Samsung Galaxy Note 10, Android 9.

Android Beacon Library version

Latest, 2.16.3

I highly appreciate any help. Thank you in advance!

[davidgyoung]

Yeah, I originally had the same thought about the runtime exception. The problem is that an app might come across an beacon with a non-standard manufacturer id in the wild. This would often cause unexpected crashes for end users after app release, which would be awful. This could often happen even if the developer never saw such a crash 😦

I think your other suggestions are good. The trick is balancing any change vs:

1. Keeping the API simple for the 99% use case (iBeacon only always Apple manufacturer id of 0x004c)
2. Backward compatibility of the API to prevent a breaking change

[davidgyoung]

Radius Networks is the company that invented Altbeacon, so their Bluetooth SIG assigned company ID of 0x118 is usually what is put in AltBeacon manufacturer advertisement headers. This library was not originally designed to require or enforce a specific manufacturer Id. In most cases any manufacturer id is allowed.

But when BLE hardware scan filters are used (which Samsung started requiring two years after this library’s API was designed) the manufacturer Id must be explicitly specified for a match. The library defaults it to 0x118 which works the vast majority of the time as most all AltBeacons use 0x118 by historic convention. But as you have noticed with FeasyBeacon if you change this, it breaks this library’s detections with scan filters.

I am sorry for the trouble this gave you. Any thoughts on how to prevent others from running into this same problem or finding the answer more easily? The library is designed to make it easy for the 99% case. Unfortunately you are the other 1% (or less).

I suppose the library could detect the case where a non-standard altbeacon manufacturer code is detected (in the foreground without scan filters at least) and put a warning in LogCat. But my guess is that you would not have noticed that.