Over the last few months, the Google library has become more a burden than an ally for us, reporting a lot of issues for location and geofencing detections causing many problems to our customers.
Today, we are proud to announce the development of our own Location and Geofencing Engine, removing Google Play Services from our Android SDK. This significant change in our development approach will let our customers use location-based marketing services in markets where non-Google-licensed devices are popular (e.g. Asia).
From now on, by using our Android SDK, digital marketers can provide a more accurate mobile engagement campaigns and get more reliable real-time locations insights about users.
MOCA Mobile Location Engine Design
The Role of Google Play Services in Location-Aware Mobile Applications
Although Android itself is an Open Source project, (called literally “Android Open Source Project” or AOSP), Google provides several libraries to enhance the experience of both Android users and software developers through a suite of resources called Google Play Services (GPSS for short); these services ranges from APIs to interact with the Google Sign In APIs, Mobile Vision, detect faces or QR Codes, to APIs to better interact with the built-in location radios.
There is another crucial role of the GPSS in the Android ecosystem: it helps to tackle fragmentation by allowing to use certain features of the new OS versions, in a retrocompatible manner. But all these advantages also have a price: Google Play Services itself is not open source, it is the way Google has to ensure its key role in the Android ecosystem; and developers are also limited to publish the applications that utilize GPSS only in devices or markets where Google has control.
This is the wall we hit here at MOCA when we found out the GPSS location library was not working as expected and, after several weeks of trying different approaches, we took a drastic decision.“If something is not working within GPSS, only Google can fix it and no one else.”
Detecting errors and alarms using GPSS
Some months ago, one of our clients in middle east (1M+ mobile users) reported that their Android version of the app was triggering alarms in Android Vitals dashboard. Android Vitals is part of the Google Developer Console from where you can track your app performance. Specifically, the report said that for more than 50% of the users an “excessive number of wake ups” occurred. The name of the wake up was:
com.google.android.location.ALARM_WAKEUP_ACTIVITY_DETECTION
After investigating a variety of sources, we concluded that the alarm was being caused by the Google Play Services - Location library. Naturally, we thought it was our fault and we thought we were not using the library properly. We invested days fine tuning our calls to ensure we made the minimum necessary requests to guarantee fast and accurate geofencing detection... but it did not work. At the end of the day it turned out to be a problem with the library itself: we found that the issue was already reported in the Google bug tracker, so we opted to report it as well in order to see if we can add a little more pressure to the matter.
Weeks later, an official response from a Google employee was posted in the thread:
“... From my initial discussion with the Vital team, looks like there is an update in the definition of wake-ups, and eventually that should reduce the wake locks complaints.”
So their approach is to fix the Android Vitals threshold but not the library itself. It does not seem like the best approach to the problem but ...OK, it could work: it’d sort out the pressure, right?
Well, it does not. Although Android Vitals will no longer complain about these excessive wake ups, there is another system that started to trigger alarms because the same reason: The built in Samsung Device Care application that comes with most of the latest phones of the Korean brand. Other brands have similar apps, with similar alarm thresholds.
Due to the design problem of Android 7.0 (and lower) of not having full control over the processes that run in the background, many device manufacturers added applications to their mobile devices that constantly monitor the background running apps, maintaining the resource-hungry apps at bay. The main problem with the approach is that these apps, many times, violate the design contracts the developers have with Android (for instance by cancelling, arbitrarily, all the alarms in the Android AlarmManager), and sometimes these apps have bizarre rules such as blocking all alarms, unless they have the word “calendar”, “alarm” or “clock” in their name. In our case, the problem was not that bad, however the “Samsung Device Care” application started to show alarms for excessive wake ups on Samsung Devices. So the problem, in a way, persisted basically because Google didn’t fix the root cause of it, but only added a patch to their own monitoring dashboard.
Exploring Location APIs: AOSP vs GPSS-Location
We decided to explore the built-in AOSP APIs for location and geofencing in order to avoid GPSS completely. This is what we found:
Location API: Reliability is almost the same, however, the GPSS API itself is prettier and more developer-friendly. GPSS implementation seems to be just a wrapper of the AOSP implementation with additional features such as taking more sensors into account in order to detect movement.
Geofencing API: GPSS Geofencing was never that reliable. However the AOSP version of Geofencing is even worse. After reading the source code of its implementation, we understood why: It has not been updated in a while, it has little to no attention due to the fact that almost all developers use GPSS-APIs. GPSS implementation seems to be way more than just a wrapper. Actually it probably reimplements completely the geofencing logic from AOSP, however, this is only speculation because these libraries are not open source.
Things did not look good!
Removing Google Play Services from MOCA’s Android SDK
After learning that AOSP version of the location APIs was not an option, we had only one choice: To create a custom location and geofencing module from the ground up.
We used GPSS-Location library in two ways:
- Get device's current location.
- Monitor geofences.
For some weeks, we dedicated effort to re-engineer these two modules, with the advantage of now having full control over the geofencing algorithm, its precision, power consumption and more importantly the number of wake-ups needed to make it work.
After publishing the first version of our Android SDK with the new implementation in our customer’s app, Android Vitals Alarms suddenly went down. This means that our Location and Geofencing Engine turned out to be not only more reliable than Google Play Services (i.e. in many cases the geofences were not detected or detected with too much delay with GPSS) but it is also better in terms of resource utilization.
We are proud of the outcome, it was worth the effort!
Testing MOCA’s Geofencing algorithm
This change also removes the vendor-lock we had with Google in terms of location. Now, MOCA’s software can be used in markets where non-Google-licensed devices are popular (for either political, business or technical reasons), such as in many Asian countries. We expect to keep improving our Location and Geofencing Engine to provide even more accuracy with smaller geofences and more reliability while maintaining the resource utilization at a minimum.
Thank you for reading! If you want to share with us your thoughts about the Google Play Services libraries or problems you might have had with location in Android, please feel free to leave a comment below!
