Improving beacon monitoring

[wiktor]

This is tracking bug for improving monitoring.

It aggregates multiple Dev Portal topics: https://forums.estimote.com/t/monitoring-region-extremely-buggy/2552 https://forums.estimote.com/t/scaning-beacon-when-phone-is-sleeping/2339/7

Progress so far:

• in v0.9.3 - we changed default background scanning time to 10s and waiting time 20s between scans
• we are internally testing new alarm mechanism for more reliable invoking scan in background

The problem boils down also to one significant problem. If at some later time app is invoked from background to perform scan, there is possibility not to find beacon even if it is nearby. That causes onExitRegion callback.

[nomisRev]

Maybe you can add this, or look into his. Since it's related to the monitoring bug. https://forums.estimote.com/t/beaconmanager-monitoringlistener-list-of-beacons/2567

PS: The bug also occurs when the app is not in background. But scanning is done in a bound service (bound to Application that is).

[nomisRev]

By implementing a simple debounce on the onExitedRegion (onExitedRegion has to be triggered twice before I show trigger my out of region "alarm", I don't seem to have the issue anymore)

[wiktor]

@vergauwen-simon Is you debounce time based?

[nomisRev]

@wiktor My debounce is purely based on how many times the onExitedRegion is triggered. In other words, I force it to trigger two consecutive times before I rely on it being onExitedRegion.

[wiktor]

We made a progress with v0.9.4 (https://github.com/Estimote/Android-SDK/releases/tag/0.9.4).

AlarmManager is now used in AndroidManifest.xml via broadcast receiver and not set up programatically. This will substantially help with reliability

[kendrak24]

Apologies if this is the wrong issue to comment on this, but we see a ranging problem (tested on Samsung Galaxy S4 and S6 with Android 5.0.1 and 5.1.1 respectively), using Estimote SDK 0.9.7 as well as 0.4.3, where our setForegroundScanPeriond for ranging is ignored when the app is put in background. We want a scan done every 1 minute, but we get a scan every 5 minutes. When Googling this, it seems like AlarmManager.set is (since API 19) inexact and can cause scheduled alarms to be deferred. If an exact firing is needed, AlarmManager.setExact should be used.

http://developer.android.com/reference/android/app/AlarmManager.html

Note: Beginning with API 19 (KITKAT) alarm delivery is inexact: the OS will shift alarms in order to minimize wakeups and battery use. There are new APIs to support applications which need strict delivery guarantees; see setWindow(int, long, long, PendingIntent) and setExact(int, long, PendingIntent). Applications whose targetSdkVersion is earlier than API 19 will continue to see the previous behavior in which all alarms are delivered exactly when requested.

[maddie]

Things are pretty bad here..

01-25 11:46:53.422 13239-13239/com.example.app D/MyApplication: entered
01-25 11:47:36.332 13239-13239/com.example.app D/MyApplication: exited
01-25 11:48:23.420 13239-13239/com.example.app D/MyApplication: entered
01-25 11:49:04.982 13239-13239/com.example.app D/MyApplication: exited
01-25 11:49:37.442 13239-13239/com.example.app D/MyApplication: entered
01-25 11:49:50.493 13239-13239/com.example.app D/MyApplication: exited
01-25 11:51:21.058 13239-13239/com.example.app D/MyApplication: entered
01-25 11:53:25.243 13239-13239/com.example.app D/MyApplication: exited
01-25 11:58:15.647 13239-13239/com.example.app D/MyApplication: entered
01-25 11:59:05.375 13239-13239/com.example.app D/MyApplication: exited
01-25 12:02:19.644 13239-13239/com.example.app D/MyApplication: entered
01-25 12:03:06.649 13239-13239/com.example.app D/MyApplication: exited
01-25 12:04:27.672 13239-13239/com.example.app D/MyApplication: entered
01-25 12:06:05.092 13239-13239/com.example.app D/MyApplication: exited
01-25 12:08:15.723 13239-13239/com.example.app D/MyApplication: entered
01-25 12:09:04.977 13239-13239/com.example.app D/MyApplication: exited
01-25 12:10:31.741 13239-13239/com.example.app D/MyApplication: entered
01-25 12:16:08.029 13239-13239/com.example.app D/MyApplication: exited
01-25 12:19:35.807 13239-13239/com.example.app D/MyApplication: entered
01-25 12:21:05.390 13239-13239/com.example.app D/MyApplication: exited
01-25 12:22:55.819 13239-13239/com.example.app D/MyApplication: entered
01-25 12:24:25.835 13239-13239/com.example.app D/MyApplication: exited
01-25 12:25:39.849 13239-13239/com.example.app D/MyApplication: entered
01-25 12:27:06.097 13239-13239/com.example.app D/MyApplication: exited
01-25 12:28:23.893 13239-13239/com.example.app D/MyApplication: entered
01-25 12:29:46.537 13239-13239/com.example.app D/MyApplication: exited
01-25 12:40:58.005 13239-13239/com.example.app D/MyApplication: entered
01-25 12:41:46.697 13239-13239/com.example.app D/MyApplication: exited
01-25 12:45:40.048 13239-13239/com.example.app D/MyApplication: entered
01-25 12:46:27.212 13239-13239/com.example.app D/MyApplication: exited
01-25 12:47:02.063 13239-13239/com.example.app D/MyApplication: entered
01-25 12:47:47.406 13239-13239/com.example.app D/MyApplication: exited
01-25 12:48:58.911 13239-13239/com.example.app D/MyApplication: entered
01-25 12:49:47.645 13239-13239/com.example.app D/MyApplication: exited
01-25 12:53:32.102 13239-13239/com.example.app D/MyApplication: entered
01-25 12:55:05.070 13239-13239/com.example.app D/MyApplication: exited
01-25 12:55:35.756 13239-13239/com.example.app D/MyApplication: entered
01-25 12:56:27.236 13239-13239/com.example.app D/MyApplication: exited
01-25 12:58:22.158 13239-13239/com.example.app D/MyApplication: entered
01-25 12:58:34.952 13239-13239/com.example.app D/MyApplication: exited
01-25 13:02:38.195 13239-13239/com.example.app D/MyApplication: entered
01-25 13:03:27.587 13239-13239/com.example.app D/MyApplication: exited
01-25 13:07:59.963 13239-13239/com.example.app D/MyApplication: entered
01-25 13:08:48.324 13239-13239/com.example.app D/MyApplication: exited
01-25 13:12:10.280 13239-13239/com.example.app D/MyApplication: entered
01-25 13:13:35.135 13239-13239/com.example.app D/MyApplication: exited
01-25 13:22:07.242 13239-13239/com.example.app D/MyApplication: entered
01-25 13:23:44.978 13239-13239/com.example.app D/MyApplication: exited
01-25 13:24:18.395 13239-13239/com.example.app D/MyApplication: entered
01-25 13:25:05.154 13239-13239/com.example.app D/MyApplication: exited
01-25 13:25:36.027 13239-13239/com.example.app D/MyApplication: entered
01-25 13:26:27.528 13239-13239/com.example.app D/MyApplication: exited
01-25 13:29:00.423 13239-13239/com.example.app D/MyApplication: entered
01-25 13:29:47.977 13239-13239/com.example.app D/MyApplication: exited
01-25 13:30:30.456 13239-13239/com.example.app D/MyApplication: entered
01-25 13:31:34.961 13239-13239/com.example.app D/MyApplication: exited
01-25 13:33:50.475 13239-13239/com.example.app D/MyApplication: entered
01-25 13:34:35.742 13239-13239/com.example.app D/MyApplication: exited
01-25 13:39:18.520 13239-13239/com.example.app D/MyApplication: entered
01-25 13:40:05.598 13239-13239/com.example.app D/MyApplication: exited
01-25 13:41:24.536 13239-13239/com.example.app D/MyApplication: entered
01-25 13:42:48.264 13239-13239/com.example.app D/MyApplication: exited
01-25 13:45:26.294 13239-13239/com.example.app D/MyApplication: entered
01-25 13:46:27.744 13239-13239/com.example.app D/MyApplication: exited

I put the "entered" and "exited" debug message in onEnter/onExit callbacks, and you can see they're being triggered randomly, but in very short interval. During the test I placed the device in a stationary place with good reception to the beacon (I can detect the beacon in the same place using the Estimote app from Play Store).

Since I rely on enter/exit event to log user's activity within an area, this renders my app useless.

Using latest SDK (v0.9.7)

[heypiotr]

What Android device and OS is that?

[maddie]

@heypiotr It was Xperia Z with official Lollipop 5.0 ROM, and I've also tested on Nexus 6P with stock latest firmware, with the same problem.

Thank you.

[nomisRev]

@maddie Work a round is to implement a debouncer... It's well not very pretty, but a debouncer of 2-3 seemed to do the trick for me.

[maddie]

@vergauwen-simon Thanks for the suggestion. The enter/exit events are being triggered too close to each other here I'm not sure how should I implement a debouncer for a situation like this.. but I'll take a shot at it.

Thanks again!

[whollacsek]

Debounce is not an acceptable workaround, because the number of trigger and the timing are not consistent. I've been using Estimote SDK from time to time since 2014 and I feel that Android does not receive enough attention from Estimote. With this bug, the SDK is basically useless...

[heypiotr]

Wall of text warning. For a TL;DR, skip to the last two paragraphs.

I can assure you we're paying more attention to Android now than ever. Android ecosystem is just much trickier for us to work with, so some features and bugfixes take longer to develop. [Ask any Android library maintainer, and especially when it come to libraries that have to touch the hardware. I'm 200% sure they'll tell you the same. We :heart: the openness, customizability and extensibility of the Android platform, but we have to acknowledge that it comes at a price.]

Example: Google made a huge step forward in Android 5.0 with rewriting their Bluetooth Low Energy API from scratch, with support for modern features such as batch scanning, hardware-level filtering, etc. First, we had to wait for Android 5.0 adoption to grow beyond a few percent it had for months after launch. Then, we a few months ago, we implemented the Android 5.0 API in our SDK, only to immediately be showered in bug reports—turned that there are huge implementation differences between devices. Samsung Galaxies for example won't report RSSI changes when doing batch scanning, etc. So we have to patiently investigate each case and add a ton of "if (isSamsungGalaxy())" workarounds to the SDK. All so that the beacon developers don't have to worry about those nuances. But this takes time.

At Estimote, we've doubled the size of our Android team in the past months, we work closely with Google on Eddystone and beacons, we're rolling out full support for our newly-announced Location Beacons to Android—100% feature parity with iOS. Android is extremely important for us, and we remain committed to its support.

About that monitoring bug though—this is something we've been working on for weeks now. Fixing bugs is not just "oh, there's a bug, let's fix it." We've been building better understanding of what's going wrong, gathering debugging logs from reporters, buying devices to be able to reproduce the bug, etc.

If you want to help speed things up, we'd appreciate your help! Tell us the exact device model, Android OS version, and SDK version that you experienced the problem with. (We'll always kindly ask you to see if the bug is reproducible with the latest version of the SDK.) If you could also enable debug logging (EstimoteSDK.enableDebugLogging(true), put it before all the other beacon code) and send us the output from logcat (plus, write at what time you got a "false" exit, so that it's easier for us to navigate the logs), that'd also help tremendously.

We're really sorry for all the trouble—believe me, we're also quite disappointed this is taking so long. Personally though [this is me speaking for myself now], I think saying that Android does not receive enough attention from Estimote is terribly unfair to both Estimote (as I'm writing this comment, two desks from me, our firmware engineers are working on new Eddystone features) and our Android team.

[whollacsek]

hi @heypiotr, sorry if I hurt your feelings, I was just expressing my frustrations. The new SDK 0.10.0 works well, I'm not having the onEnter/onExit events randomly anymore. The testing device was HTC One M9.

[heypiotr]

No feelings were hurt in the process (: I just felt it's important to add some context to this discussion, because otherwise, it's very easy to draw wrong conclusions—and it's naturally our job to explain the intricacies of building beacons support, so I'm glad you brought it up.

Glad to hear the new SDK works better!

[rodrigator]

Hi,

I'm new at developing with Android Estimote SDK and I've just came across the same issue that Maddie.

I've tried several Android SDK versions and the only one that seems to work fine is 0.10.0. But I've tried 0.10.04 and 0.11.00 and with both encountered the same bug.

I'm using a Samsung S5 Mini (SM-800G), Android Version 4.4.2

Any ideas?

Thanks in advance for your help.

Rodrigo

[AnthonyKoueik]

I have the same Issue , the beacon still entering and exiting, i have tried it on all devices from API 19 till 25 ! Anyone have a solution for this !

[luclx]

Hello everybody, I have same problem. My beacon exit and enter a few seconds. My device note 3 android 6.0. I find out this blog. http://blog.estimote.com/post/149409589655/estimote-monitoring-more-reliable-notifications. But no suggestion. Anyone have solution?