Inside Google’s new location APIs for Android

Inside Google’s new location APIs for Android

Setting: Large ballroom in Moscone. Large enough that two sets of projected screens are on, one up front, and one pair amidset. Crowded, one or two open seats per long row. Two bright-shirted Google employees in blue. We start on time.

Today during the I/O developer conference, Googlers Waleed Kadous and Jaikumar Ganesh walked developers through the now-live location API improvements that the company has released for the Android platform.

New York, are you ready?

We’re building Momentum: an all killer, no filler event this November.

The news had broken yesterday, during Google’s stem-winding three and a half hour keynote extravaganza. During that speech, it was announced that Google had built new ways for applications to better track location, user activity, and employ geofences.

Google has three broad goals regarding location, according to Kadous: Power, accuracy and coverage. Or, limiting power consumption, improving accuracy, and expanding where location information can be provided.

The more accurate your location, the more power you are using

If the company can do that, apps for the Android platform will (in its estimation) be stronger, and able to do more. This is a good for Google, as the better the Android ecosystem is, the more smartphones it can likely sell that use its suite of services.

Putting the importance of location into context, Kadous stated that of around 28 cards that Google Now contains as of yesterday, 21 of the mix use location data. That’s three-fourths, if you wanted to divide.

Accuracy, however, is relative. When indoors, for example, precision is key. When driving, it is less so. There is a power-accuracy ratio that is simple to understand. The more accurate your location, the more power you are using, generally.

Sensor data can be helpful in boosting the accuracy of location information. Where GPS may fail, inside for example, data from the sensors on a phone can help to dictate location. Google listed the current set of sensors that can be useful in finding where a person is as including a gyroscope, a compass, or a barometer.

Quickly, here is a summary of the new tools that Google has released, all of which are backwards compatible to FroYo. They are live, in the most recent APK. So if you’re a developer, this isn’t theoretical information.

Fused Location Provider

The goal of Fused Location Provider (‘Fused’) is to lessen the workload of developers who want to interact with location information. Instead of having an app talk to different location data sources, and provide them with — given that I grokked the slides — a single programmable interface to talk to; Google thus does the hard work in sourcing location, simply feeding it to developers’ applications.

Google does appear to want to drive location usage directly; one simple way to do that is to improve the quality of the signal, and make that signal simple to access. Fused is the embodiment of that ethos, bringing together cellular, WiFi, GPS, and sensor data.

Demos showing off the power of different single systems — WiFI and GPS – compared to the Fused collection showed that Google’s new method is superior to a current single system. That said, while a material improvement, it remains imperfect.


Developers will have access to three levels of location-information priority. Keep in mind that the more accurate your location data, the more power you are using.

  • High Accuracy:  5 second check interval, consumes 7.25% per hour, accurate to within  around 20 meters, uses GPS when outside, and WiFi when inside.
  • Balanced Power: 20 second check interval,  0.6% battery usage per hour, and accurate to within 40 meters. This method is what it appears that Google envisions as a way to bring location into a host of new applications, without sacrificing end-user device satisfaction.
  • No Power: No poll interval, no power consumption, accurate to within around one mile.


The new geofencing API will allow for 100 geofences per application. In short, a geofence is a digital boundary around a physical location. If your user enters or exits, your applications knows. For example, if your user enters a Hardees, you could send that individual a coupon.

A function by the name of addProximityAlert() already exists, but it drains around 8% of battery life on a phone per day. The geofencing function — addGeoFences() — will use around two-thirds less, or around 2.4%.

Geofencing, according to Google, is all but a background application.


And finally, Google has released a new way for developers to track the physical activity of their users, whether they are in a vehicle, on foot, still, or on a bicycle. This naturally uses on-device sensors.

According to Ganesh, the company used machine learning classifiers to parse signal data to discover what inputs corresponded with what sort of activity.

The above APIs are certainly promising, but given how troublesome (battery intensive) it can be to constantly pull location data, Google’s APIs must truly live up to the above promises. Otherwise, Google will end up with frustrated developers and angry users.

For more new from Google I/O , you can head here.

Read next: Billions: How exactly do Apple and Google count app downloads?

Shh. Here's some distraction