Android Geofencing is broken (and how we fixed it)

TL;DR - If you’re sick of Android's broken GeoFencing - the false positives/negatives, inconsistencies, and other bad behavior - you’re in luck - we fixed it! Grab the SDK.

Get the PathSense SDK

We started Pathsense to fix the issues we encountered in the iOS and Android location stacks at our last startup Trapster (which had ~20m users before Nokia pulled the plug). At the top of our list was addressing the inconsistency of Geofencing we observed on Android phones.

When we surveyed our beta group we were overwhelmed with data suggesting false Geofence positives were a daily occurrence on Android, and a consensus opinion that the supported Google Play Services 100m+ fence size was too broad. So we set to work quantifying the problem and putting together a fix.

Building our test parameters . . .

The problem with documenting Android bugs is the sheer number of devices to test and consider. To dig into this problem the first thing we did was build a "ruler" of sorts to create consistent device testing - we chose 6 parameters:

  • False egress at rest
  • False egress in motion
  • Ingress detection time
  • Egress detection time
  • Battery usage
  • Accurate geofence radius

Then we sent our our test lead - Pablo - to start collecting geofence data in different scenarios (city, suburbs, vehicles, etc. Good thing he didn't bring his test-backpack to the classroom :)

Pablo loaded the phones to run a test app loaded up with vanilla Google Play Services GeofencingApi, and collected the test data across a variety of the most popular Android devices.

Geofencing was even worse than we expected...

False positives = a mission critical fail for any number of apps (home automation, family trackers, advertising, event based), and in the data below you can see the extent of the issue.

Function Android GeofencingApi
False Egress at Rest 1 per 24 hours
False Egress in Motion 1 per 30 trials
Ingress Detection Time 46 seconds
Egress Detection Time 44 seconds
Battery Usage .67% per hour
geofence Radius 100m

On the plus side battery usage isn't half bad and we realize that there are always compromises between fidelity/latency vs. polling of wifi/gps etc.

But ~45 second latency sure feels awfully slow and a 100m geofence radius is a radius as large as an American football field. Seems like we could do better.

How we addressed the problem . . .

At our core we are a sensor fusion company, and leveraging sensors wound up being the perfect solution to this problem.

Our broad goal at PathSense is to build a true GPS replacement SDK targeted at reducing battery drain with amazing accuracy which would have made our lives very easy at Trapster.

We built our core technology using the sensors on the phone - the accelerometer, gyro, etc, to determine context and motion, and then combined this with real time map matching in our proprietary geospatial platform.

Now of course Google Play Services already has a detected activity API, but that service is not nearly sufficient for our needs. We require much greater fidelity and accuracy, and much lower latency.

So we built our own technology in house, to replace and go far beyond the detected activity API in Google Play Services (incidentally, this project is in closed beta right now – drop us a line if you’d like an early look).>

Next our scientists create and train machine learning models to determine both context and motion using our sensor core.

Most of this research takes place in MATLAB or Python. We collect reams of data from many places on Earth, across many scenarios, to train these models.

Our software engineering team then incorporates these models into algorithms that run on the mobile platforms. The trick is doing this in a very efficient manner so we don’t wind up draining too much battery.

This approach is particularly effective for geofencing, where motion is bounded by a simple radius or polygon - far less complex than a directed graph such as a roadway system or aisleways inside Nordstrom or Walmart.

By using real time context and motion, we avoid the problems with both accuracy and latency that impact standard geofencing, such as those seen with Google Play Services.

With this approach in mind, the problem becomes one of deviations and balancing the need for location / latency improvement across multiple Android Phones that all leverage slightly different sensors.

Once in place, we tested our solution head-to-head . . .

After dozens of test cycles and tweaking we arrived at what we consider to be a truly useful beta - we’re seeing improvements in latency and accuracy by 2x, and more importantly, no more false positives. Here's a look:

Function PathSense Android Play Services
False Egress at Rest 0 per 24 hours 1 per 24 hours
False Egress in Motion 0 per 30 trials 1 per 30 trials
Ingress Detection Time 21 seconds 46 seconds
Egress Detection Time 29 seconds 44 seconds
Battery Usage .77% per hour .67% per hour
geofence Radius 50m 100m

We anticipate continuing to improve on all of the metrics, especially battery usage, over the course of the next few weeks. Want to give it a try yourself? Download the free SDK...

Help us build a better Android location stack - join the beta!

Preliminary feedback has been very positive so we're opening up our beta test more broadly. Please join our beta group and we’ll send you a link with the SDK, documentation, and known issues. It's a simple drop-in replacement.

With our success in driving Geofencing forward we’re also planning other improvements to the core Android Location Stack so if you’d like to be updated in the future please Follow us on Twitter right now.

  • Our Investors

  • Keshif VenturesTaner Halicioglu Keshif Ventures
  • Data CollectiveMatt Ocko Data Collective
  • Vertical VenturesDave Schwab Vertical Ventures