When application is initially launched, the beacons detecting works correctly. But after some time (didn't find exact pattern but we met it after 8-16 hours) iBeacons detecting stops.
We detected the issue particularly on OnePlus 8 Pro device and probably it may happen on other OnePlus devices.
We are using AltBeacon library 2.19 version implementation 'org.altbeacon:android-beacon-library:2.19'
We tried to kill the app and launch again, this doesn't help, iBeacons are not detected.
Rebooting of the Android device helps, app starts detecting iBeacons again
Turning Bluetooth Off and On helps, app starts detecting iBeacons again.
At the same time, we added some debug code, and when Beacons detecting doesn't work the function:
Added this code:
BluetoothMedic.getInstance().runScanTest(context)
and it still returns TRUE, which is meaning (at least I think so) that Bluetooth stack is in a good state. Which is also proved by the logs (below).
with the only change that we have incapsulated the Beacons detecting implementation into the BeaconsManager and initialize this manager object in the Application (inherited) class by means of Koin library (Kotlin dependency injection library)
by adding this code:
BeaconManager.setDebug(true)
And here is the logs related with the same particular beacon:
a) When the beacon is detected successfully we can see the following logs:
03-23 18:25:46.250 2629 2629 D CycledLeScannerForLollipop: got record
03-23 18:25:46.250 2629 2629 D CycledLeScannerForLollipop: with service uuid: 00001308-0000-1000-8000-00805f9b34fb
.... Here, there were some more logs for detection BLE device which is not iBeacon
03-23 18:25:46.286 2629 2629 D CycledLeScannerForLollipop: got record
03-23 18:25:46.286 2629 10587 D BeaconParser: Ignoring pdu type 01
03-23 18:25:46.286 2629 10587 D BeaconParser: Processing pdu type FF: 0201061aff4c00021554656c6c69512069426561636f6e545100010370c40c09432049442030303033373000000000000000000000000000000000000000 with startIndex: 5, endIndex: 29
03-23 18:25:46.286 2629 10587 D BeaconParser: Ignoring pdu type 09
03-23 18:25:46.286 2629 10587 D BeaconParser: Ignoring pdu type 43
03-23 18:25:46.286 2629 10587 D BeaconParser: Ignoring pdu type 30
03-23 18:25:46.286 2629 10587 D BeaconParser: This is a recognized beacon advertisement -- 02 15 seen
03-23 18:25:46.286 2629 10587 D BeaconParser: Bytes are: **0201061aff4c00021554656c6c69512069426561636f6e545100010370c40c09432049442030303033373000000000000000000000000000000000000000**
03-23 18:25:46.287 2629 10587 D m : Beacon packet detected for: id1: 54656c6c-6951-2069-4265-61636f6e5451 id2: 1 id3: 880 with rssi -96
03-23 18:25:46.287 2629 10587 D m : beacon detected : id1: 54656c6c-6951-2069-4265-61636f6e5451 id2: 1 id3: 880
03-23 18:25:46.287 2629 10587 D m : looking for ranging region matches for this beacon
03-23 18:25:46.287 2629 10587 D m : matches ranging region: id1: 54656c6c-6951-2069-4265-61636f6e5451 id2: null id3: null
03-23 18:25:46.287 2629 10587 D RangeState: adding id1: 54656c6c-6951-2069-4265-61636f6e5451 id2: 1 id3: 880 to new rangedBeacon
b) When the beacon detection stops working we can see the following logs:
03-23 15:06:42.795 11304 11304 D CycledLeScannerForLollipop: got record
03-23 15:06:42.795 11304 11304 D CycledLeScannerForLollipop: with service uuid: 0000fe9f-0000-1000-8000-00805f9b34fb
... Here, there were some more logs for detection BLE device which is not iBeacon
03-23 15:06:42.797 11304 11304 D CycledLeScannerForLollipop: got record
03-23 15:06:42.797 11304 22675 D BeaconParser: Ignoring pdu type 01
03-23 15:06:42.797 11304 22675 D BeaconParser: Processing pdu type FF: **0201061aff4c00021554656c6c69512069426561636f6e545100010370c40c09432049442030303033373000000000000000000000000000000000000000** with startIndex: 5, endIndex: 29
03-23 15:06:42.797 11304 22675 D BeaconParser: Ignoring pdu type 09
03-23 15:06:42.798 11304 22675 D BeaconParser: Ignoring pdu type 43
03-23 15:06:42.798 11304 22675 D BeaconParser: Ignoring pdu type 30
03-23 15:06:42.798 11304 22675 D BeaconParser: This is not a matching Beacon advertisement. (Was expecting be ac. The bytes I see are: 0201061aff4c00021554656c6c69512069426561636f6e545100010370c40c09432049442030303033373000000000000000000000000000000000000000
0
So, from the logs I can see that the library is actually able to detect the BLE devices, but for some reason it looks like, the library kind of resets beacon parser layout, and parsing only default AltBeacons? I make this assumption because I can see in the logs "Was expecting be ac"
In the beacon manager setup we have the following code:
beaconManager.beaconParsers.clear()
beaconManager.beaconParsers.add(BeaconParser().setBeaconLayout("m:2-3=0215,i:4-19,i:20-21,i:22-23,p:24-24,d:27-28,d:29-29"))
We also tried, as a workaround, to put the code above right before every starting of the ranging:
beaconManager.startRangingBeacons(region)
But it didn't help us neither.
It sounds to me like OnePlus is killing your app and then somehow the app is relaunching itself in the background, but when it does the code that sets the beacon parser never executes. This would cause the beacon parser you originally set to be lost.
A few tips to figure out why this may be happening:
Add an Android Application class if you do not have one already and log something and record a timestamp in the onCreate method. This will tell you if your app restarted when detections stopped.
Consider moving your initialization to the above method or do I another class executed from the above method to ensure it executes at every app start.
Log each item in beaconManager.getBeaconParsers() is I see when your app loses the one you set.
UPDATE June 15, 2022: Library version 2.19.5-beta5 adds changes to help prevent this from happening.