How accurate is Android GPS? Part 1: Understanding Location Data

There are many different ways for developers to get access to location information using the Android SDK, and there are already plenty of code examples on the internet showing how to do that. This post, on the other hand, focuses on putting the location data into context and offers suggestions on how to use it in the best possible way. In this series I’ll discuss various aspects of the Android SDK’s android.location package and how you can best take advantage of them to build a great end-user experience.

To try out GPS different usage scenarios, be sure to download the GPSTester app, both the .apk and source code are available on github.

Six types of location data

It’s not just about latitude and longitude. The great thing about the Android SDK is you get access to a ton of information related to location. The fun, challenging and sometimes frustrating part is deciphering the information. There are six types of location data that you have programmatic access to. This data comes from what’s referred to as a provider, and it will be either a cellular network-based or a GPS provider. As you’ll see, you can use these providers in a variety of different ways.

All locations derived from the LocationManager are guaranteed to provide a valid latitude, longitude and timestamp, all the other parameters are optional depending on who manufactured the handset and who is providing cellular service. However, if you have a device that doesn’t give you access to the accuracy parameter then the location data is practically worthless. I haven’t come across such a device yet, but I’m assuming it’s possible. My advice: always check for null location parameter values in your production code.

Cached GPS. Most Androids have the ability to store the last know GPS location. This is typically used when an application first starts up, and you can retrieve the timestamp, latitude, longitude and accuracy.


Cached Network. Android devices can also store the last known location as determined by the cellular carrier’s network location provider. The provider gathers information from the cell network and WiFi, if it’s turned on, then sends that off to a remote server-side process that crunches the information and sends back an approximate location. This is not available in all countries.  Just like the GPS, you’ll typically retrieve the timestamp, latitude, longitude and accuracy.


Real-time GPS. This is the raw information that is streamed off the GPS.  When a GPS is first turned on it won’t immediately return any information, it has to basically warm up first. The warm up time varies by device and can typically take from one minute or longer if you are inside a building. More on that in a bit. Depending on what your provider allows you can get access to timestamp, latitude, longitude, altitude, bearing, speed, accuracy and distance travelled.


Real-time Network. This is the raw network location provider information returned by the cellular carrier, such as AT&T in the U.S. Different carriers use different information to determine location such as WiFi data, GPS information, nearby cell towers, etc. Depending on what your carrier allows, you can get access to timestamp, latitude, longitude, altitude, accuracy and distance travelled.


Passive. This option just means that your application can listen for location updates while it is in a minimized state. The idea is to save battery power, such that your applications providers aren’t running full speed ahead while the app is miminized. That would be huge battery drain. Passive location can listen for another application to request location updates. You may be able to get access to timestamp, latitude, longitude, altitude and accuracy. As far as I know, you won’t be able to determine from which provider this information was derived.

<receiver android:name=".PassiveLocationChangedReceiver" android:enabled="true"/>

NMEA. Although it’s not human readable, you can get access to the raw NMEA strings. Typically these strings are used for programmatic access and would only make sense to a developer or engineer. This data is often used in maritime apps. The data is only available once the GPS has warmed up, which is a concept discussed in more detail below.


Working with cached locations

Working with cached locations is an interesting problem because the first location you get is not going to be the most accurate, and typically it can be wildly inaccurate compared to your actual, physical location. Think of the location capabilities on the device as being similar to a car engine on a cold morning. The engine needs to warm up first before it can perform optimally, and this typically takes a few minutes. And once the engine is warmed up, if you make a quick stop at the grocery store the engine will still be mostly warm when you come back out.  

Location provider components act in a very similar way. When an app is first launched the providers may be “cold”. The only information that is immediate accessible will be via cached network, cached GPS and the passive listener.  Alternatively, if the app is launched when the providers are still warm or even hot, then you will get better accuracy with the cached results and the real-time locations may start streaming sooner.

Cached locations aren’t always best 1st choice. When an app first launches, the inclination of many developers is to simply grab the cached location data and use that as a starting point, but as implied above…be careful! Caveat emptor applies here. Cached locations are simply the very last result stored on the phone and it’s not always what you expect. As you can see from the Cached Network Provider screenshot taken from the GPSTester app, the accuracy of that data snapshot is 1780 meters (1.1 miles). Keeping that in mind, consider these use cases:

Business traveler – You last opened the application on a business trip to San Francisco and you are now in Denver where you happen to live. When you start the app in Denver the cached locations could very well be for San Francisco.

Consumer –You last used the app at home and now you have traveled to the other side town, or even to a nearby city to visit friends. The last cached locations will be from near your home and not very helpful to your immediate surroundings.

Cached locations vary considerably because you almost always never leave the location provider services running constantly. Leaving them on all time can easily kill the battery in a few hours, and end users will unanimously reject that kind of battery life.  Therefore cached locations represent the fact that either your app or another app had explicitly turned on location providers at some point in the past.

Timestamp and accuracy. You will also want to compare the timestamps and accuracy of the cached network and cached GPS. If network data isn’t available then look at the cached GPS results. If both are available then check to see which one is the most recent.  Here are several example use cases to demonstrate whether or not they would be valid for your requirements. Which one would you go with?

Date of cached network data is 7 days old and accuracy is greater than 1000 meters (or ~3/4 mile). No cached GPS data is available.

Timestamp of cached GPS  is the yesterday with accuracy of 1000 meters, and cached network data is from today with an accuracy of 1780 meters.

Timestamp of cached GPS is from yesterday and the accuracy was 250 meters. Cached network data is not available.

When you answered those scenarios did you take into account any behavior patterns? How would your answers differ if you were aiming for business travelers versus aiming for local consumers that frequently stay within a 50 mile radius?

Know Your Users Behavior Patterns. The bottom line is people move around a lot. You’ll need to be very aware of the persona that you are targeting with your app and understand their general behavior and geographic movement patterns that answer questions such as:

How often do they access the map from a different location: once a day, several times a day, once a month?

How far do they travel per each trip: getting groceries (1 – 3 miles?), going to work (5 – 20 miles), visiting client sites (20 – 100 miles?), etc.?

Are their trips always within a dense city limits? City center users may encounter many more stop lights and traffic jams in town but drive shorter distances. Urban users who are out in the suburbs might travel longer distances.

Do they travel or live near many canyons, mountains, tunnels or large buildings that might affect an accurate signal?

What country do they live in? Not all countries offer network provider services.

Are the use cases so varied that you simply can’t predict the behavior patterns? If this is the case then you may have to launch the app and build in ways to gather statistics so you can start to analyse the behavior.

As you can see, someone’s geographic behavior of a period of time can significantly affect the model you are using and force you to look at cached location data in new and different ways.

Wrap Up

That’s it for Part 1 of this series. We’ve looked at six different ways that Android can provide location information, and examined different scenarios on how you can use that information. We also briefly skimmed the surface on how geographic behaviors can affect what you do with cached location results. You’ve seen that cached results can be misleading and your users may have to wait until the phone can provide more accurate information. I hope you find this information useful. Stay tuned for Part 2 which will talk about different patterns for retrieving real-time data, and how to start applying use cases to validate your results.

Android GPS Testing Tool

The Android GPS Testing Tool is a must have tool for any Android developer using GPS or network location data. It’s intended to help developers, hobbyists and scientists understand the internal workings of smartphones and tablets so that they can build better applications.

It’s completely configurable via preferences so that you can quickly and easily cook up scenarios and test them out. Use it to compare cached results versus real-time data as well as plot all of it on a map.  The source code is included to see you can see how all of it works, and if you want to get started immediately simply grab the .apk file. So have at it and let me know what you think and what could be improved.

What are some example scenarios that I can test with this app?

  • Test how long it takes for GPS to provide it’s first update after the app is started
  • Compare and contrast Network locations with GPS locations
  • Study cached network and GPS data that is provided at app startup.

What data does it provide? Here’s an overview of the raw data you’ll be able to see:  

  • Cached Network location data (includes date/time, accuracy, time to retrieve)
  • Cached GPS data (includes date/time, accuracy, time to retrieve)
  • Real-time GPS (includes date/time, accuracy, time to retrieve, speed, heading, altitude)
  • Real-time Network location (includes date/time, accuracy, time to retrieve)
  • Best available provider
  • Most accurate provider
  • Satellite data dump
  • GPS NMEA string

What are some of the configuration options? Here are some of the configuration options:

  • Use GPS and/or Network provider data
  • GPS minimum update time
  • GPS  minimum update distance
  • Network minimum update time
  • Network minimum update distance
  • Use Criteria such as accuracy, power and cost

I built v1.0 out of necessity to gain an understanding of the complexities and subtleties of the android.location package across different devices. No blog post can comprehensively explain how each individual smartphone or tablet will work as related to Location, GPS, GPSStatus, GPSSatellite, Criteria and LocationManager using different providers such as GPS and Network.

Furthermore, when I was first starting out building Android apps, I found all the different options confusing in terms of what they did and how to easily compare results both literally and on a map.

My wish list for future updates includes:

  • Fully flesh out the ability to use all of the Criteria settings. V1.0 uses a subset of all the possible Criteria.
  • Ability to monitor passive updates.
  • Ability to monitor battery usage.
  • Output all data in csv format so it can be graphed over time.

Get access to the source code on github

Get access to the application file (.apk)  – click on the “View Raw” button and it should download to your machine.

[May 29, 2013: changed URL to the downloadable .apk file)]

Android SDK sense of humor

The Android SDK contains one of the lowest level smartphone APIs available. What I mean by that is for the vast majority of things that it does there is very little abstraction. For instance, take a look at all the classes related to LocationManager that provide control or access to even the smallest details of the phones ability to derive a location.

Okay, back to why I’m writing this. In general, there really isn’t anything to laugh about within the SDK until earlier this week. The SDK does its job and it’s quite comprehensive. So, there I was digging around in the ActivityManager class documentation and lo and behold I came across a method called isUserAMonkey(). I nearly fell of my chair laughing. The SDK documentation states:

Returns “true” if the user interface is currently being messed with by a monkey.”

Call me crazy, but every time I accessed the method it returned true.

3 Steps for Shutting off GPS and LocationManager on Android

While the code for shutting off the LocationManager on Android is straight forward, sometimes just one misstep and you can spend hours trying to figure out why it doesn’t work. What will happen is you will see in your code that the LocationManager and perhaps even the listeners will be null and the GPS active icon will continue to display and your battery will drain faster than you ever thought possible. There are a bunch of comments already on Stack Overflow about this problem, so this post attempts to consolidate answers and provide some straight forward steps to help with the most common mistakes.

First let’s review the steps for properly shutting LocationManager down:

Step 1. Remove the listener or listeners. If you are using both GPS and network providers you have to remove both. It sounds oversimplified, but you can only remove the exact listener that is associated with a particular instance of the LocationManager. It’s a one-to-one relationship.

Step 2. Set LocationManager to null.

Step 3. Set listeners to null.

Here’s what the code looks like, the names should be self explanatory:

if(_locationManager != null){



    _locationManager = null;


if(_locationListenerGPSProvider != null) {

    _locationListenerGPSProvider = null;


if(_locationListenerNetworkProvider != null){

    _locationListenerNetworkProvider = null;


If these steps don’t work and the GPS icon continues to display, then there are potentially two reasons why:

Reason 1. You have instantiated intentionally or accidentally more than one copy of LocationManager and/or a listener. This is by far the most common and frustrating reason. The easiest way to avoid this mistake is to only start the LocationManager via the onResume() event, and shut it down using onPause(). Carefully control what is allowed to start and stop it. Be mindful when passing around instances of LocationManager between different Activities whether it is a singleton, static class or simply a reference to the actual object. If LocationManager is already running and you spin up a new instance, then you may not be able to shut it off programmatically and you’ll have to manually shut it off.

Reason 2. Something else other than your app is causing the LocationManager to run. This can easily give the appearance that it has not been turned off via your app. Repeated testing can eliminate this as a possibility, and to make sure you can shut off all other non-essential applications that use location.


Android Activity and Life Cycle

Migrating from Desktop to Mobile: 6 steps for success

If you have only one web site that is built for desktop browsers then you definately need to read this post. The one-size website-fits-all days are gone along with the AMC Gremlin. Mobile is a much different world than desktop and your visitors, users and customers will know that. This post is based on a presentation that I did at GIS in the Rockies 2012, and another blog post I wrote called 3 Steps for Determining if Your Website is Mobile Ready.

The presentation mentions GIS, or Geographic Information Systems, however it applies to anyone considering mobile.

Why care about mobile? For once the internet analyst firms are clear on one thing: mobile device sales have  surpassed desktop sales world-wide, yep I mean not just in the good ol’ U.S.A, around January’ish 2012. There are more than 835 million mobile users now, and studies show that people are spending the majority of their free time using their devices. And the patterns they use to interact with the devices are becoming ingrained and, for better or for worse, expected. And that expectation has reached a fervored pitch as the iPhone fanboys (and fangirls) demonstrated when the iPhone 5 launched. Everyone wants the latest and greatest even if it’s not all that different.

What about mobile user expectations? Mobile users have significantly different expectations on performance, look-and-feel, and capabilities. There are also differences between devices, for example as you may already know an Android user interface is fairly different from iPhone. Catering to those needs will boost your chances of success. So, here’s just a sampling:

  • Many different screen sizes. Typically smaller screen sizes and a wide vareity of screen pixel densities.
  • The mouse is gone. Navigation is done using fingers for gestures such as pinch and swipe. Greasy, french fry picking fingers are much less precise than any computer mouse.
  • Less memory. Phones have less memory and they can be slower than your high-powered laptop.
  • Poor internet connection. There are no gaurantees on a mobile internet connection, unless you happen to be dragging a CAT6 ethernet cable with you everwhere you go. Connections can be spotty and 4G connections can be inconsistent.
  • Battery life is awful. If you are at a conference, for example, using the phone heavily may kill the battery in  4 – 5 hours. Tablets are typically a bit better. In comparison, desktop computers are always plugged in.
  • Not all mobile devices are the same. iPhone and iPad run a different operating system from Android. Not only are the platforms completely different underneath, but users have different expectations of each platform. You can’t share the same code between iOS and Android, or even Windows Phone.

How about those six steps you mentioned? It’s these differences that really drive the six migration steps. And, these suggestions apply to all the different approaches to mobile whether you are building for mobile web, hybrid, native or responsive*:

  1. Start prototyping today. Let your developers loose to start playing and to get an idea the capabilities of different devices and operating systems. Have them use your existing web site content.
  2. Analyze your existing website usage. Use analytics tools such as Google Analytics to analyze what browser and operating systems your visitors are using. Look to see if there are any trends related to mobile usage. If you don’t use online analytics, there are also tools that can examine your existing web site logs.
  3. Reevalute all use cases and workflows. Mobile is so different from desktop. Refresh your approach on how to work your magic in that enviroment by taking into account how people use their smartphone everyday.
  4. Expect that you will need to rewrite code. Don’t try to make the code fit if it doesn’t meet the requirements. Besides, sometimes it’s a good thing to rebuild so that you clean house and bring a fresh perspective.
  5. Buy as many devices as possible. Since all devices are different, the more you can test on the better. For example, have as many types of Android and iOS devices running different OS versions on several different cell providers.
  6. Dig deep into browser differences. All browsers are different, especially mobile browsers. Check out as your next new best friend.

* A short note on Responsive websites. These use CSS3 media queries to detect and control what HTML content is visible to certain devices. CSS3 is generally considered to be one of the three technologies that together make up HTML5. Those three components are HTML (version 5) + Cascading Style Sheets (version 3) +  some new JavaScript APIs. NOTE: all three of these technologies are built into the browser by the browser vendors such as Google, Mozilla, Microsoft and Apple.

What do you really want in a future smartphone?

I’m voting for five simple things. Note, we are talking about smartphones here and not tablets. I look at the patent fights and all the junk functionality that is being crammed into the newest SDKs, and as a consumer all that I really want is all of the following bolted into one phone:

  • Significantly better battery life – My current phone won’t make it through a typical work day.
  • Faster battery charging time – My original Google Ion used to charge in less than an hour, my Atrix takes at least 2 hours and usually much longer.
  • Better default keyboard app – I probably make six mistakes typing one average length sentence because the tiny keys are so close together. Some third party apps have figured this out.
  • Better control over the camera app – I would stop carrying a separate camera if I could simply adjust f-stop and aperture.
  • Ability to read my screen in full sunlight with polarized sunglasses on – No chance of that on my current phone.

I’m fairly happy with the operating system software. And, my phone already has plenty of CPU horsepower and memory. It appears that in five short years the smart phone market has matured and the phone vendors are struggling to differentiate themselves. The current phone wars remind me of car ads on TV. Everyone is claiming incremental improvements that make your life better, easier or faster.  However, I propose there hasn’t really been any ground breaking innovation in smartphones since June 29th, 2007.

Now if there was a press release that said in the next version I could heavily use my phone for 3 days straight without a charge…that would get my attention!

What do you want in the next smartphone?