How Accurate is HTML5 Geolocation, really? Part 2: Mobile Web

Where Part 1 focused on non-GPS enabled devices, Part 2 is totally focused on mobile web geolocation. The great news is that the usage of HTML5 location services along-side the fact that there is a GPS chipset in most, if not all, modern smartphones and tablets dramatically improves the chances of getting an accurate location. And, besides that fact — mobile geolocation is simply a lot of fun to work with.

I also want to point out that there are an increasing number of really good blog posts covering the topic of “how to use” the API that look at the nitty-gritty of how the code works. This post is different in that I’ve tried to focus on “how to build successful applications” with the API, and how to get the most out of the API so that you can successfully implement your unique requirements.

What’s different about desktop vs. mobile HTML5 Geolocation? With mobile you can access the GPS if it’s available. It’s important to note that in order to access a device GPS you have to set the optional enableHighAccuracy property in your code. Contrary to what is shown in some samples on the internet, you can use this property with both the getCurrentPosition() and watchPosition() functions.

//One time snapshot
     // Optional settings below
         timeout: 0,
         enableHighAccuracy: true,
         maximumAge: Infinity

//Tracking users position
watchId = navigator.geolocation.watchPosition(
     // Optional settings below
         timeout: 0,
         enableHighAccuracy: true,
         maximumAge: Infinity

How accurate is it??? This is the million dollar question, right? When using enableHighAccuracy() on a phone where all the appropriate permissions have been selected and granted, I’ve typically seen accuracy readings as low as 3 meters (~10 feet) that were obtained within 10 – 30 seconds of kicking off the geolocation functionality. I’d consider that excellent for most consumer and retail applications. You should be aware that like any location-based functionality you will get spurious (abnormal) results that fall way outside the norm, and sometimes these results are wildly wrong.

I’ve seen claims that using the enableHighAccuracy() property slows down the phones ability to deliver a location. I’m going to argue that those claims are misleading. It is true that the GPS, itself, can take a significant amount of time to warm up and start delivering high accuracy results. For an in-depth look at that topic see my post on the Six Most Common Use Cases for Android GPS. However, there are conditions where simply enabling the enableHighAccuracy() property doesn’t affect the speed in which you can get the initial result. More on these topics below.

What is the best way to try out various configuration scenarios? I’ve built an HTML5 Geolocation Testing tool that can be used in browser, or it can be repurposed to work in PhoneGap or Titanium. It is a jQuery-based mobile application that includes a map and settings view were you can adjust all the different properties and try out different configuration scenarios. It’s a work-in-progress so I welcome suggestions and pull requests.

 Why HTML5 Geolocation rather than native? Applications using HTML5 Geolocation typically have slightly different requirements than native GPS-based applications. Each platform has its advantages and disadvantages and it all comes down to your requirements, budget, timeframes and skill sets:

  • Ability to re-use existing JavaScript and HTML5 skills to build a high-accuracy mobile application.
  • Don’t have access to native platform developers or skillsets on Android, iPhone and/or Windows Phone.
  • Need a cross-platform stand-alone web app, or a web app that has been repurposed to work with PhoneGap or Titanium.
  • Quickly locate the user/consumer within a reasonable expectation of accuracy.
  • Typically it is a non-commercial, consumer grade application that does not have extremely high accuracy requirements (e.g. < 1 meter).

How fast can I get an initial location result? The answer is very fast, potentially within a few seconds, given the following scenarios:

  • If there was a cached GPS or Network location stored on the phone. The GPS location is, of course, from the GPS chipset. The Network location comes from your wireless carrier and is dependent on your phone and their capabilities.
  • How the timeout and maximumAge properties are set. If you set timeout = 0 and maximumAge = Infinity it will force the application to grab any cached location, if one is available. Other settings may result in delays.
  • If the phone or tablet has decent internet connectivity and Wifi enabled.
  • If the device is in an urban area with many wifi nodes broadcasting their SSIDs nearby.
  • The device has a clear and uninterrupted view of the sky. GPS’s listen for a very weak signal from multiple satellites. These signals can be partially or completely blocked by buildings, thick foliage, vehicle roofs, etc.

 How accurate is the initial location result? Hah, you might have guessed I’d say that it depends.  When you first kick off a geolocation request, accuracy does depend on a number of different factors that are mentioned above. And it’s safe to say that, in the vast majority of cases, the first location is not the most accurate and typically not the most dependable. If you want the fastest, most accurate location possible then you will most likely need to either do multiple snapshots, or use watchLocation until your desired level of accuracy is met. It’s important to note because I’ve been asked about this many times, you cannot expect the GPS, itself, to have enough time to lock onto a satellite and deliver a fast, accurate initial location. It may take dozens of seconds or even minutes. Yep, it’s true. Factors that affect initial location accuracy include:

  • Cached locations – how recently the user accessed location functionality. For example, applications like Facebook typically grab a location when you open the app. So frequent users of social media are more likely to have a fresh, cached location that non-social media users. If you are targeting business travelers, the cached location might the last city before they got on a plane. Or, it could be your home neighborhood and not where you work or go to games.
  • Wifi turned “on”. If the Wifi is turned on then the device can access the location service and there is a much greater chance that the initial result is fairly accurate. If you didn’t have a chance to read Part 1, when the Wifi is on your browser gathers local Wifi node information from your Wifi card, and it can use that information in a location service provider request over the internet to try and triangulate your position. Typically this means your initial location can be within a block or two of the actual position. Also, it is possible if Wifi is turned on that you can get a significantly more accurate initial location than if you were using GPS by itself with no Wifi or internet.
  • Internet connectivity strength. If you have a poor internet connection and no Wifi, then the browser’s requests to the location service can be delayed, blocked or even interrupted.
  • No VPN. Take note commercial application developers: as mentioned in Part 1, if VPN software is in use it can wildly affect accuracy and even place you in another State (or Country).

Can I use HTML5 Geolocation for mobile tracking? Yes, with caveats. Typically HTML5 tracking applications are built inside a native wrapper framework such as PhoneGap or Titanium. There are several immediate problems with stand-alone, browser-only HTML5 tracking applications. First, there is no built-in functionality to keep the screen from going to sleep. Second, when the screen goes to sleep the HTML5 Geolocation functionality also goes to sleep. Native-based tracking applications can work around these limitations and listen passively in the background when they are minimized. Third, you have little control over the GPS settings to help management battery consumption.

Can I use HTML5 Geolocation offline? Yes! If there is no cellular connection or Wifi available, then HTML5 Geolocation can still access cached locations and real-time GPS information. This is vastly different from what was discussed in Part 1 as related to applications targeted at laptops, desktops and tablets that may or may not have GPS. If a device does not have a built-in or externally available GPS then your offline application will not work.

Handling abnormal location results. Your application will occasionally encounter widely inaccurate results and you need to handle these gracefully for the best user experience possible. My recommendation is to check the timestamps and distance traveled between the current geolocation object and the previous one. If the distance or speed seems excessive then you’ll need to reject the result. In the reference section below is a link to more information on calculating the distance between two points containing latitude and longitude. As an example, see the attached screenshot with the spurious results indicated by red circles. Also note in the screenshot the accuracy level was 3 meters, so it’s important to understand that even at high accuracy levels you still need to very that each location meets your minimum requirements. This way your results will always look polished and professional to the end user.

Spurious results

What are some of the downsides of using HTML5 Geolocation versus native? The bottom line is that for simple location gathering and basic tracking HTML5 Geolocation is just fine. This should meet the requirements for most consumer applications. For anything more complex than that you should consider looking at going native.

  • It may not work on older phones and older browsers (depending on your definition of old). See below in the references section for a link to a fallback library to handle these situations.
  • HMTL5 Geolocation offers significantly less control over GPS settings. This can have an unacceptable impact on more complex applications.  Because of this, I also suggest that HTML5 Geolocation is not suitable for long-running tracking applications.
  • Battery life management. This is a direct result of bullet #2. It’s more challenging to manage battery life with HTML5 Geolocatoin if your requirements call for continuous use of the GPS.  Your control is very limited with respect to these two properties: timeout and maximumAge.
  • Cannot use it when the application is minimized. If your requirements calls for the ability to passively receive locations while in a minimized state then, as mentioned earlier, you will have to go native.
  • Very little control over how often you want location updates. You’ll need to do a bunch of custom coding to emulate what is already built into native application APIs. For example, the native Android API offers very detailed control over what type of geolocation data you can get access to, how you can access it and how often. Read more on that topic in my post on How Accurate is Android GPS Part 1 – Understanding Location Data and also take a look at Android’s LocationManager Class.


W3C Geolocation API Specification 

HTML5 Geolocation Test Tool

Mozilla – Using Geolocation

Calculating distance between two points.

Geolocation fallback library for older browsers

Six Most Common Use Cases for Android GPS

This post summarizes the six most common use cases associated with using GPS and location services on an Android device. It also continues the series on using the open source GPSTester tool to build better location aware Android apps. So not only can you read about what works and what doesn’t you can also try various scenarios out yourself using the tool rather than having to build code from scratch.

I’m striving to make this information freely available because adding location to your apps can be fun, and it can also be an important part of the applications that you build. By taking into account these six use cases you will be able to build applications that better meet your requirements and make for a more enjoyable end user experience.

Use Case 1 – Cold Start. Application launches from a completely stopped state. Cached GPS  and Network location values may be unreliable. As a developer you don’t really have any control over this but you need to plan for it. The screenshot from the GPSTester tool below shows a typical cold start where the cached network location has better accuracy than the most recent GPS location. You can see from the timestamps that even though the GPS location is more recent than the network location, it’s the network location that has better accuracy.

Use Case 2 – Warm Start. Application launches from a minimized state. Cached GPS values may be reliable depending on how much time has passed since application was last running, and the total distance traveled away from when the app was last used. Like the cold start, the user that decides how and when to start the app and you just have to plan for this use case. The screenshot below represents a typical warm start scenario where the cached GPS result has better accuracy than the cached network provider.

Use Case 3 – Minimized. Requirements may call for location listeners to continue to run in the background, or to be shut off when the application is minimized. There is also the option of using what’s called passive listeners which rely on other applications to call location services. Note, if you listen for location changes in  a minimized state you typically won’t benefit from this information until the application is opened again. In my previous posts I’ve stated that if your target demographic uses retail and social media apps this use case may be of benefit if the person uses the device constantly during the day. Many retail and social media apps access location. However, in many commercial use cases using passive location listeners may provide less than desirable results since there is much less of a chance of another application using a location service.

Pros: Running location services while app is minimized can speed up acquisition time when app starts, but only if your requirements call for always-on accuracy at a moment’s notice. If you shut off location then you will save battery life.

Cons: If active location services are left on in a minimized state this can sap the battery without the user really knowing it.

Use Case 4 – Snapshot. Application only needs to hit a minimum level of accuracy before shutting off location services. The screenshot below shows that it took approximately 2 minutes for the device to reach an accuracy of 12 meters. Yep, you heard that right…2 minutes! Also note how much the latitude and longitude of the different providers wandered around the map. The blue dot indicates network locations and the red dot indicates GPS locations. This is just a reminder that consumer-grade Android devices may or may not be accurate enough for your unique requirements.

Pros: Maximizes battery life.

Cons: May cause user interface delays if user needs to refresh the location during a single application session.

Use Case 5 – Continuous duty. Location services need to be constantly on while application is running. The screenshot below shows a use case of the user being in a downtown area with lots of tall buildings, the apps was run for about 10 minutes, then minimized briefly, then opened again for a warm start. The accuracy didn’t change much even after 10 more minutes of testing. As you can see, the GPS provider accuracy has suffered significantly at 153 meters, while the network provider is offering 45 meters of accuracy.

Pros: Best for constant, up-to-date, always on accuracy. Accuracy available instantly (after the device has ‘warmed up’).

Cons: Huge drain on the battery, but you can adjust the minimum distance property needed to trigger a location update.

Use Case 6 – Intermittent duty. GPS is only needed to run at intervals. To test these types of scenarios you can adjust various settings from within the GPSTester Tool’s preferences. Specifically you can modify the GPS and Network properties for minimum update time and distance. This is very powerful as you can easily toggle these settings to test various settings on-the-fly versus have to write custom code.

Pros: Depending on your use cases such as delivery driver tracking application, this can provide a good compromise on battery usage and accuracy.

Cons: You will have to write algorithms to constantly adjust the location service settings to meet the users movement patterns. This may also involve cycling the location services on and off to maximize battery life.

A few comments on testing your use cases. In the GPSTester tool there are a number of settings you can use to adjust how the device will receive location information.

You have full control over which providers are being used whether it’s GPS, Network or Critera.

Location provider indicators on the main screen will show which providers are being used. You can also see which provider is providing the best accuracy as determined by comparing available providers.

There is a list of available providers available on the GPSTester tool as well as table row showing what the device considers to be providing the best accuracy.


Android GPS Testing Tool

GPSTest Tool Github Repo

How accurate is Android GPS Part 1 – Understanding location data

How accurate is Android GPS Part 2 – Consuming real-time locations

How accurate is Android GPS? Part 2 – Consuming real-time locations

In part 1, we looked at the six types of location data available through the Android native SDK and talked about how to work with cached location data. As others have also discovered, there is a ton of information to say on this topic and way more than you could pile into a single blog post. So, this post focuses on working with real-time locations. Once you activate the location listeners they will start sending you information and knowing how to handle that data is what this post is about.

The most important take away I hope to leave you with is take time to understand your accuracy requirements and your user’s basic geographic behavior patterns. I’ve tried to liberally sprinkle example use cases to help illustrate some of the concepts.

Time and distance properties. The first thing you’ll notice when you start building location aware Android apps is you can set time and distance properties that affect how often the device will request a location update. This is accomplished using the overloaded LocationManager.requestLocationUpdates() method. These properties adjust how aggressively the device will request location updates by minimum time elapsed and minimum distance traveled. How you adjust these settings significantly affects the battery life. The equation for battery life is straightforward and simple: the shorter the minimum time interval the faster the battery will be drained.

In the code snippet below, the time and distance properties are both set to zero, which is the most aggressive setting.  You’ll get a location update if any change in location is detected at any time. This setting can result in your app accessing the GPS provider as often as 50 – 60 times or more per minute.


I’ve experimented with this setting by leaving it running, and it drained a fully charge Samsung Galaxy SIII in less than 3 hours. The phone also got very hot to the touch. It takes considerable power to run the current generation of GPS chips. Even using network location requires that the phone use its radio to make an internet request to the location processing server. So, carefully evaluate your use cases and be conservative about the time and distance properties that are needed.

Except for high performance situations, it will be rare when you need location access every second at a zero distance delta. You can also adjust these properties if your app detects a change in the usage pattern. For example, if the user slows down for a period of time then you might restart the listener using a longer time interval. The listener does not have to stay static and be set only once. Hopefully this is your “ah-hah!” moment. In fact I encourage you to make dynamic adjustments to the intervals as your usage scenarios change. The GPSTester tool allows you to easily experiment with different configurations.

Here are some use case examples:

  • Real-time tracking app for use when walking, running, biking or driving.  As expected, this app will require the most aggressive settings for time and distance.
  • Delivery vehicle tracking app. The delivery vehicle will be starting and stopping all day long. Minimal ability to plug phone into charger. This app should dynamically adjust its time and distance settings.
  • App only needs a one-time snapshot location to find nearby coffee shops. This requires that the app run until a minimum accuracy value is received and then it can turn off the location listeners. Other examples are placing a geotagging a photo, tweet or Facebook posting. You could also try your luck using the overloaded Location.requestSingleUpdate() method.

And, here’s a very basic set of technical requirements for dynamically changing requestLocationUpdates() settings:

  • Start application using minTime = 0 and minDistance = 0. Use an aggressive setting to get accurate location as quickly as possible.
  • Once accuracy is less than 50 meters and speed less than 45 mph set minTime = 5000 and minDistance = 25.
  • Speed equals 0 for greater than 1 hour. Shut off location listeners and notify user.
  • Battery gets low. Shut off location listeners and notify user.

Time to 1st real-time location. It can take up to several minutes to get the first GPS or Network location result. Use effective notifications to let your users know there will be a delay in getting this information. For example, many Android mapping apps use an accuracy circle around the current location indicator to give a sense of accuracy level. 

As you can see in the GPS Provider screenshot taken from the GPS Tester app, using a warm GPS it took ~9 secs to get the first GPS result from the device and then 1450ms to get the next update for an accuracy of 3.0 meters.  By warm I’m referring to a device where the GPS and Network location have been accessed recently.

How long it takes to start getting accurate results depends on many different factors of which you, as the developer, will have very little control over but you’ll need to plan for accordingly. As discussed in Part 1, many developers lean heavily on the cached locations to try and work around these types of delays. Yet, depending on your use cases and the end user personas these results can either be very useful or fantastically inaccurate.

According to Google user interface responsiveness guidelines 100 to 200 milliseconds is where users will start to perceive slowness and we are talking about 9 whole seconds here that the user had to wait. Of course 9 seconds is “fast” for a GPS acquisition. And, you can typically expect much longer time frames, especially on a cold device, and until the accuracy drops down to within a few hundred meters or less.

I’ve seen differences in acquisition times between two phones of the same exact model and same settings even though they were placed right next to each other. Other factors that affect acquisition times can be as simple as where you placed the phone in the car such as down by the gear shift between the seats or up on the dashboard. Or the user could be standing just inside a restaurant under a metal awning because it’s raining outside.  The list goes on and on. Cement, bricks, metal, car bodies, heavy foliage and buildings are some other examples of things that can interfere with GPS signal accuracy and the time to first acquisition. Like the Boy Scouts say, “Be Prepared” and be kind to your users by using user interface notifications to let them know of location acquisition delays.

Streaming real-time locations. Once the device starts providing real-time locations, my suggestion is to check the accuracy of each result and consider rejecting those greater than a certain amount that are based on your requirements. The longer the location provider runs, and if the device has an unobstructed views of the sky and good cellular connection, then typically the accuracy will improve up to a certain point and then level off, and then it will fluctuate.  Here’s a pseudo-code snippet showing how to check the accuracy of each GPS location result:

public void onLocationChanged(Location location) {
     if(location.getAccuracy() < 100.0 && location.getSpeed() < 6.95){
          //Do something
          //Continue listening for a more accurate location

Here are some rough examples of accuracy thresholds I used for a project last year. Your requirements may vary as to how these different thresholds will affect the behavior of your application; these were examples that required geocoding that converted the current location to an approximate address. Depending on the result the application gave different feedback to the user:

  • Rooftop  <= 10 meters (desired result)
  • Street >10 meters and <= 100 meters (let user know it’s close but not perfect. Good enough?)
  • Neighborhood > 100 meters and  <= 500 meters (give visual feedback that accuracy is low)
  • City > 500 meters and <= 2000 meters (ask user to verify city name from a list)
  • County > 2000 meters (prompt for manual location input)

Take into account your own unique use cases. You might completely reject any accuracy value greater than 100 meters (328 ft) if your app simply helps people find open parking lots at NFL games. You could have an app that returns a list of Dentist offices within a 5 mile (8000m) radius. Or a weather app could only need to know approximately what city you are in. These are just ideas to help get you thinking.

Not all real-time location data is alike.  Continuing on the theme of consuming real-time location, let’s dig into a few more examples of why it should be looked at closely. Here’s one thing that I keep forgetting even though I’ve blogged about it: you can get null location values and if not properly handled they will crash the app. That’s an easy one to forget until your users start to report random application crashes.

You can also look for what I’ll call spurious results. These are results that are way outside what you might consider a running average. Check the distance between the last location result and the current location result using the Location.distanceBetween() method. If the distance and speed required to cover that distance is significantly greater than the running average, then you can reject that result.

I also want to mention that simply holding the device in one location while standing outdoors can result in the latitude/longitude wandering over a reasonable distance. Even if you set the phone on a rock the results can wander. Just keep this in mind if you have accuracy requirements. Just because the user is standing still outdoors doesn’t mean that the indicated location will stay exactly the same. It could wander over a 10 to 50 meter radius or more.

I have occasionally seen wild location fluctuations that were enough to make a mapping application nauseatingly jump back and forth between different center points. Unfortunately, when it happened I didn’t have the device on a debugger, but I suspect it had to do with the phone detecting various WiFi end points when I stopped at stoplights along my route. It’s possible the phone tried to resolve those WiFi locations using the Google Network Location service and that there was some lag time in processing those results.

Are Android, off-the-shelf, retail smartphones as accurate as something like a Trimble Pro Series Receiver? No way, not all, definitely not! If you have high accuracy, field-usage requirements calling for sub-meter results you should not be using a typical retail Android device. For example, if you are standing in an intersection with four manhole covers that are two feet apart and form a circle, you could not accurately map which manhole cover is the right one that you need to be working in if you are using an off-the-shelf Android. Using my own phone as an example, on a good day my Samsung Galaxy SIII occasionally has down to 3 meters GPS accuracy for short periods of time and then it can start wandering.

Comparing Network and GPS locations and using Criteria. Yes, you should definitely compare the results between these two. The more data you have the better. There’s not a whole lot to say about this other than look at timestamps, accuracy and distance traveled factors. In my experience, just something to keep in mind is the network locations happen much slower than the GPS. I expected this because of the lag time involved with the phone sending information to the remote location service and then waiting for a result to come back. You can read more about how location services work in this article.

The use of android.location.Criteria can also be used to control which listener(s) are used. You can experiment with Criteria using the GPSTester tool. The only minor caveat is it doesn’t include all possible criteria in the current version (v1.2.1.1). My general recommendation is to skip Criteria and hard code in the validation rules. I don’t currently subscribe to the idea that the Criteria will know what’s best for my end users. Please comment below if you feel otherwise, but in my own experience I haven’t come across a use case where Criteria gave what I thought was the right answer. In one use case, the Criteria was set to not incur costs, yet the value returned was to use the network provider even though GPS was available. Using the network location service would have incurred bandwidth costs.

What to do when app is minimized? A common workflow is for a user to minimize the app and then either forget about it or come back to it later. I’ve included this because it’s common for the user to get a phone call or a text message that results in the app being minimized. In most of the use cases I work with, the requirements call for both the GPS and Network Location services to be shut off when the app is minimized. It’s just way too easy for the user to forget about the app and then it could kill the battery in a very short time.

There is the option of using a passive listener. I rarely use these because it assumes some other unknown application will spin up the GPS or Network Location providers.  Your use cases will help you decide whether or not implementing a passive listener is a good idea. If your target audience is a 20-something student who is constantly using location based social media such as Facebook every hour and eighteen hours a day then there’s a good chance the passive listener will return recent and mostly accurate results. However, if you are building a commercial-grade application on a work-related phone then a passive listener is significantly less likely, or even highly unlikely, to speed up the applications ability to get a fast fix on startup.

Use Intents when implementing a passive listener, this involves adding directives in the AndroidManifest.xml as well as writing some code. A great example of how to do this can be found here, so I’m not going to reinvent the wheel. Just don’t forget to add the receiver tag to your manifest:

 <receiver android:name=".receivers.PassiveLocationChangeReceiver"/>

When the app restarts you can use information from the passive listener and consider whether or not it meets your accuracy criteria. You can also use the passive listener to run background processes within your app while it is minimized. You’ll use the Location timestamp once the app is opened again. If the timestamp is very recent, such as less than one hour old, then you could consider using the passive location immediately. Otherwise, you’ll be back to waiting for a real-time location result. For this approach consider comparing Location.getRealtimeNanos() to SystemClock.elapsedRealtimeNanos(). If your target audience are business travelers, then for example you might want to reject cached results that are greater than 8 hours old because chances are the user has hopped on a plane.

Privacy, data storage and data consumption. Yeh, it’s a bummer I even had to bring this up. I’m not a lawyer, but every lawyer I’ve worked with on these types of production applications strongly reminds me to have a Privacy Policy and to be transparent about how the data is stored and how the data is used. Don’t try to do this on your own, hire a lawyer or the equivalent of a lawyer in your country, as the case law is constantly changing and can vary from State-to-State and Country-to-Country.

And, that’s the wrap-up for Part 2. Stay tuned for additional posts on this series that cover using the GPSTester tool and how to interpret the results.


Google Developer docs – Location Strategies

Android blog – Deep dive into location

GPS Testing Tool (open source)

HTML5 Geolocation API – How accurate is it, really?

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)]

Minimizing Wild GPS Fluctuations in Flex Mobile Apps

Under low accuracy situations, I’ve noticed on both iPhone and Android that the GPS location can fluctuate wildly over a short period of time, sometime jumping 2500 ft (762m) or more within several seconds. By low accuracy I mean the GPS result indicated a horizontal accuracy of greater than 1000ft (305m). This creates a really poor user experience, so I quickly implemented a very rough algorithm to minimize these fluctuations. Here’s some psuedo-code that demonstrates the concept:

private _currentTime:Date;
private _lastUpdateTime:Date = null;
private const _DISTANCE_ACCURACY_THRESHOLD:Number = 2500; //feet
private const _TIME_ACCURACY_THRESHOLD:Number = 1000; //msecs

_timer = new Timer(100,0);
	_currentTime = new Date();

//Calculate time elapsed since last update
var f:Number = _currentTime.time - _lastUpdateTime.time;

if(_lastUpdateTime != null)

	//Minimize annoying fluctuations.				
        //accuracy is a property from GPS result (horizontalAccuracy)
		isValid = true;
		_lastUpdateTime = _currentTime;

The theory is that the distance and time between fluctuations calculate out to speeds greater than 2500 ft/1 second. You can adjust the parameters as you see fit. I also assumed that under normal driving (or walking!) conditions you wouldn’t be going that fast, right?

You could also write a native extension, but I didn’t have enough time to do that. The native Android SDK offers many ways to use the GPS that could eliminate these problems.

This could certainly use some tweaking, so if you have suggestions for improvement please post a comment or send me an email!