Android Location Providers – gps, network, passive – Tutorial

Posted: April 11, 2011 in Android


There are 3 network providers in Android (ranging from 1.5 to 2.2). They are:

  • gps –> (GPS, AGPS): Name of the GPS location provider. This provider determines location using satellites. Depending on conditions, this provider may take a while to return a location fix. Requires the permission android.permission.ACCESS_FINE_LOCATION.
  • network –> (AGPS, CellID, WiFi MACID): Name of the network location provider. This provider determines location based on availability of cell tower and WiFi access points. Results are retrieved by means of a network lookup. Requires either of the permissions android.permission.ACCESS_COARSE_LOCATION or android.permission.ACCESS_FINE_LOCATION.
  • passive –> (CellID, WiFi MACID): A special location provider for receiving locations without actually initiating a location fix. This provider can be used to passively receive location updates when other applications or services request them without actually requesting the locations yourself. This provider will return locations generated by other providers. Requires the permission android.permission.ACCESS_FINE_LOCATION, although if the GPS is not enabled this provider might only return coarse fixes.

This is what Android calls these location providers, however, the underlying technologies to make this stuff work is mapped to the specific set of hardware and telco provided capabilities (network service).

Here is a table that maps/lists the underlying technologies in a different way:


How to think about it

The most important thing to keep in mind is to provide some level of service, even in a situation where a user has the worst device, and the worst network service. It’s great that you can get low battery consumption and 20ft accuracy, when conditions are great. However, you can’t plan on that, and you can’t rely on that. Not in 2010 anyway  .

The following is a screenshot of the application RainOrShine, showing the “network” provider accuracy. This dynamic movement algorithm takes care of switching back and forth between different providers during a single session, and also it takes care of accuracy’s changing all the time, in a single session. In fact, network providers can be switched from fine to coarse grain and back depending on the task being collected.


What it looks like on a real device

Here is a screenshot from the Droid 2, that shows the location provider settings:

  • When only “use wireless networks” is checked, then CellID/MACID lookups are used first, and the “network” provider uses this, and gets about 200ft-1mile accuracy.
  • When only “enable assisted GPS” is checked, then AGPS is used first, and the “gps” provider uses this, and gets about 10ft-20ft accuracy.
  • When only “use GPS satellites” is checked, then, GPS is used, and the “gps’ provider uses this, and gets less than 10ft accuracy.

A good practice is first try and use the “network” provider, because it will always work on anyone’s device, and the location fix will be acquired immediately. And the accuracy is quite good – 200ft or so. You can also try “passive” first. Just keep in mind that not all providers are available on all devices, carriers, and user configurations.

If a user disables “use wireless networks” in their settings, then “network” or “passive” is not available. Then “gps” is the only option (assuming it is turned on).

Implementation notes

  • When attaching a location listener to a location provider (regardless of the exact kind of provider), it is important to execute this listener code in the main thread of your activity or service. If you run this in any background thread (like using an executor) then this will not work. The listener code itself has to be on the main thread. You can kick of a task in an executor in the listener, but the listener itself must run in the main thread of the app.
  • Some devices will require you to detach the listener and then reattach it periodically. This is not a bad idea, since it eliminates the possibility of the listener going stale.
  • You can switch providers at any time, and switch out a fine provider with a coarse one to save battery life, for example. There is really no limit to how often you can switch out providers. You can also do this when you discover that a provider is unavailable, via a call to the registered location listener.
  • Finally, the parameters you pass to the location provider, when you attach your location listener are totally optional. The device you are running on will decide whether to respect those parameters or not. So it’s best never to rely on them. Also, different devices behave differently with reporting location movements. Eg, the Droid X and Droid 2 are very zippy about providing location updates, they will do it every second and provide you with a very high level of accuracy. The Samsung Galaxy S is less zippy with the location updates. The HTC Incredible is better than the Galaxy S, but not as zippy with the frequent updates as the Droid X and Droid 2. Finally, the LG Ally is one of the worst with location updates, providing very infrequent updates, and very poor accuracy (even on autonomous GPS). So don’t make any assumptions about the accuracy and frequency of updates – you have to test it on real devices on real networks in real life situations.


The best way to handle GPS is to use the “network” or “passive” provider first, and then fallback on “gps”, and depending on the task, switch between providers. This covers all cases, and provides a lowest common denominator service (in the worst case) and great service (in the best case).

Let’s dispel the myth that mobile development is ‘EASY’, beginner-friendly, and suited for ‘web developers’. This is marketing crap and media hype. Mobile development is VERY difficult – it’s much more difficult and more complicated than web or server app development. If you have experience in web or server app development, this experience will NOT help you with mobile. Sample code you find on the Internet, books, tutorials (even good ones) will not come close to getting you ready for the minefield that is mobile development, deployment, and testing. The code you copied and pasted might simply stop working on a real device (even though it compiles and runs in the simulator) due to a carrier limitation, device limitation, or user configuration choice.

You cannot just read the API docs for a mobile platform and start coding, they do not give you any idea what really happens on a real device, on a real network. No API docs, books, or tutorials can give you experience on multiple handsets, carriers, and OSes. If your mobile app works perfectly in the simulator, this means nothing at all, and you have just gotten started (not finished).

Mobile is a whole different ballgame full of hardware capability divergence, screen size & form factor divergence, carrier limitations, DPI independence issues, and it all gets increasingly more difficult when you get into cloud-connected multiplatform-mobile.



Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s