Fused Location Provider

In the high day of location-based mobile deals and offers, the question of defining user’s location for specific services, collecting statistics or keeping track of a user’s movement for specific purposes remains as relevant as ever.

Since the early versions of Android, location tracking API has gained much in terms of effectiveness. There is some payback, of course: location tracking API was moved to Google Play services, so the integration with an app is painful but surely worth it.

Main benefits

As I mentioned before, location API was available when the very first versions of Android OS emerged. API calls were simple, and location tracking algorithm was fairly straightforward: you could choose one of the location providers (network or GPS) and request location updates or set up proximity alert.

But there were two main issues with this approach:

1. In case you need to define precise location, you had to switch between network and GPS location providers (as GPS doesn’t work indoors).
2. Proximity alerts were used to notify a user about proximity to a location, and this took its toll on the battery life.

Having worked on location implementation (tracking application, notifying users about proximity to certain locations), we’ve discovered that proximity alerts seemed to be the perfect solution. The only but was that the phone’s battery wasn’t taking it well, which inspired us to implement our own location tracking algorithm based on both GPS and network location providers (using sensors to define if a user is moving and at which speed). In fact, it was a rough sketch of the Fused Location Provider, represented in the new Android API.

Fused Location Provider analyses GPS, Cellular and Wi-Fi network location data in order to provide the highest accuracy data. Also, this provider uses different device sensors to define if a user is walking, riding a bicycle, driving a car or just standing in order to adjust the frequency of location updates.

Fused location provider can be used to get periodic location updates (Google provides us with the perfect tutorial on this, so there is no need to reinvent the wheel). It can notify us when a user is entering/leaving some area (this feature is called geofencing. More information about implementation details can be found here). What’s more, using geofencing an application can track up to 100 targets. In fact, geofencing uses cellular location data to avoid tracking distant targets (there is no point in tracking proximity to target which is 100 miles away using expensive GPS if we can use cellular location, which gives 0.7-1.5 miles’ accuracy).

A user can define one of the 3 main fused location provider modes by setting priority:

HIGH_ACCURACY, BALANCED_POWER or NO_POWER

During the Google IO presentation, a chart was presented showing effect of different priorities of the recognition algorithm as tested multiple times on Galaxy Nexus.

Priority	Typical location update interval	Battery drain per hour (%)	Accuracy
HIGH_ACCURACY	5 seconds	7.25%	~10 meters
BALANCED_POWER	20 seconds	0.6%	~40 meters
NO_POWER	N/A	small	~1 mile

Activity recognition

If you remember, Fused Location Provider uses different sensors to adjust the necessary location updates frequency, for which purpose it relies on the User activity recognition service. Even though this service is used inside of the location provider, you can use it for your own purposes (fortunately, Google has provided us with  the appropriate Guide).

The Guide reads that this service can be used to define one of the 5 user states (activities):

IN_VEHICLE
ON_BICYCLE
ON_FOOT
STILL
TILTING

Of course, sometimes a user’s action cannot be defined or is beyond this scope, thus the UNKNOWN state.

Integration details

It’s been noted before that the integration of this new API requires some additional effort:

1. First of all, in order to use this API we have to include Google services library into our project (see the guide).
2. Secondly, we cannot be sure if the new API is available on a particular device. So we have to check. Fortunately, all we have to do is call GooglePlayServicesUtil.isGooglePlayServicesAvailable().
3. Then we have to decide what to do if the service is unavailable (use an older version or prompt the Play Store update?).
4. And finally, this API is available for Android 2.2 and higher, so you won’t be able to use it with the older OS versions (and some developers still support even 1.6 OS).

There is one positive thing in moving location API to Play Services: they can be updated separately from the OS update. Which supposes more frequent updates