All the Beacon BLE phenomenon exploted since Apple introduced the iBeacon support on iOS 7. However, all the Bluetooth Low Energy technology and the possibility of creating stand-alone devices emmiting its own ID 24/7, were available before the iBeacon support on iOS. Most modern Android Phones have the necessary hardware and software to detect BLE Beacons, however Android does not provide developers the tools to facilitate the work in order to create an App that does not drain the battery (except in the not-yet-released Android L), like iOS does.
Google is aware of the need to provide a native support for Beacon scanning and discovery, so they have dramatically improved Bluetooth Low Energy beacon detection on the latest iteration of the Android Operating System (Android L). This version of the OS will allow developers to rely on the OS the beacon detection , like iOS does. However, Android will provide more flexibility to developers regarding the kind of beacons detected. The main problem about going with Google solution is that it will be available only for the L version of Android. A version that has not been released yet and due to the nature of this operating system, its market share will not be relevant until a year from now, taking into account the adoption rate of the latest released version (KitKat).
We have been exploring different approaches to provide a reliable solution for Beacon BLE detection for current Android devices. Android OS has native support for Bluetooth Low Energy (BLE) since version 4.3 (Jelly Bean), however this version of Android has an imporant bug regarding Bluetooth that hampers the development of a quality solution.
Given that millions of current Android devices are able to detect BLE Beacons, we strongly believe that an almost universal abstraction layer should be present in all capable devices, and ready to be used by developer. Specifically, these are some key features we consider the most important:
Received signal strength pre-processing (RSSI): Due to the nature of the RF signals, there are several factors that affect the received signal strength making it less stable as device get farther from the BLE Beacon. By applying statistical methods to a sample of measured RSSIs (such as a Kalman filter), it is possible to get more realiable data about the approximate distance of a given beacon. On top of this, the device variables such as its hardware manufacturer should also be taken into account.
Battery-friendly background scanning: A service should always be running, scanning for visible BLE beacons in the background. If this service is not correctly implemented, it will dramatically drain the user's battery, creating a very poor user experience.
Unified solution: Alongside the significant growth of the micro-location Apps in both iOS and Android, chances are that several applications in the same device will be looking for BLE beacons, (or other BLE devices) at the same time. This situation may end up not only in a drastic battery impact, but in compatibility issues especially if Apps are running on Android 4.3 Jelly Bean, and each application has implemented its own libraries in order to detect beacons.
Although there are not too many options in town, fortunately there is a library that fulfills almost all the above mentioned requirements. We have decided to go with Radius Networks AltBeacon Library. We would like to take the opportunity to thank Radius Networks for their work, and show our support to their project by integrating their library in the upcoming version of MOCA SDK for Android.
MOCA SDK for Android will include the AltBeacon library for all the beacon detection tasks. All the logic regarding where to fire experiences, enabling or disabling campaigns, syncing experiences with the cloud, providing the UI for the pre-defined experiences and syncing analytical data with the MOCA platform will be carried out by the MOCA SDK itself.