Any success stories of beacons with Android devices?

1

Hello all beacon fans!

I have been playing with Estimote beacons and Android devices for a while now, I am not convinced…
I have tried different CMS providers (Bleesk, Pushmote, Rover) and Estimote demo apps.

It is not working as I would expect. Sometimes I get notifications right away, sometimes it fires with 30 min delay with no reason. Customer could be on his way home by then :slight_smile:

I noticed it works differently across different handsets. On HTC M8 beacons “disappear” after a few minutes and device will not see it again for at least 30 min. Of course you can restart bluetooth…
On Sony E3, situation is a bit better, but has own flaws. It discovers beacons much better with a few random disappearances and you get notifications 10 min later.
I would understand if it happens with no-name Chinese devices, but it is HTC, Sony or even Samsung :wink:
Another extrema I’ve noticed with Pushmote and Rover, happens after that “silent period”. You suddenly get a few notifications immediately, it pays no attention to delay between notifications setting.

Where’s the problem? Is it SDK? Is it Android? Is it me?
I am very new in the field, maybe I am missing something. Different Android handsets have different characteristics. Maybe Bluetooth Low Energy technology is not mature yet across different devices?
All the SDKs for Android are usually < v1.0. The priority number one is iOS. Android seems to be behind.

Is anyone using beacons with Android in the real environment? Have you noticed any similar problems?

Thanks in advance!
Valdas

2

The answer to this is a bit of a cliche in the Android world … Device fragmentation.

Apple designs its Bluetooth software stack knowing exactly which Bluetooth chips they’re gonna use, what their capabilities are, and—being the inventor of iBeacon, they’ve been the first to add a ton of sophisticated mechanisms to make it work really well.

For example, the first iPhone with support for offloading Bluetooth scanning to the Bluetooth chip itself (which greatly improves responsiveness and decreases energy consumption) was iPhone 5 (2012)—a good year before iBeacon launched in iOS 7. Compare that, e.g., to Google’s flagship Nexus phones—the first one with offloaded scanning support was Nexus 6 (2014). The first Android OS to support offloaded scanning was 5.0 (2014).

We’re now slowly seeing the landscape improve, with the recent top-of-the-line Android phones (Nexus 6/6P, Galaxy 6, etc.) having already very solid Bluetooth hardware, and Android 5.0 adoption reaching 50%. And of course, Google entering the beacon scene with Eddystone.

We also try to keep up: recently, we added all the Android 5.0 BLE support to our Android SDK and Android app, so that when you run on a capable hardware, we utilize the new stack.

So to say though, once the Android hardware matures, and Android 5.0 adoption grows a bit more, it looks like the tides may turn: iOS has great hardware and software support for iBeacon, but much poorer support for any other BLE advertisers. On Android, starting with Android 5.0 (and with capable hardware), you gain direct control over the hardware-accelerated Bluetooth API, so you can essentially make any beacon advertisements perform very well. (Whereas on iOS, you’re stuck with iBeacon.)

Android 6.0 brought some more improvements (better permissions model for Bluetooth scanning to help with privacy concerns, or a bit controversial ability to use Bluetooth/WiFi for location even if the user disabled it—although that’s only available to the system right now, who knows, maybe in 7.0 they’ll open up the API?), so I personally am watching the Android beacon ecosystem very closely, since there’s a lot of potentially interesting stuff bound to happen (:

In the meantime, I encourage you to share more details about the issues you’re experiencing with M8 and E3, so that we can see if there’s anything to be done to work around this, and improve our SDK in the process. (We already handle a ton of Bluetooth quirks between all the different Android handsets, you have no idea!) What version of the app/SDK are you using, what scan intervals, ranging/monitoring, what Android OS version, what are the results of isOffloadedFilteringSupported and isOffloadedScanBatchingSupported calls on these two devices, etc.