Is a consumer smartphone GPS good enough?

When I presented at OSCON  (O’Reilly’s Open Source Conference) in Portland, Oregon this last week on native Android GPS and Geolocation, I was repeatedly asked the question “is the GPS in smartphones good enough?” In general the answer is “yes”. But, I should back this statement up by looking at several everyday types of scenarios to help illustrate my answer.

What does accuracy mean? First lets briefly look at what accuracy means. Accuracy, in a technical sense, means you get a latitude, longitude and accuracy number from the GPS. Then you can draw a circle using the accuracy number as radius around the latitude/longitude point. It’s highly likely that your actual location is somewhere within that circle. It’s unfortunate that consumer GPS devices don’t also come with a probability factor that would indicate how much to trust the accuracy number. As it is, we will have to take it on a certain amount of faith that our real location is, in fact, somewhere within the accuracy circle.

Under absolutely perfect conditions your typical smartphone GPS chip will deliver around 3 meters (~10 ft) in accuracy for several minutes at a time.  Standing on the highest mountaintop in the Rocky Mountains with no clouds in the sky might come close to being a perfect condition. Under what I’ll call “average” conditions, which reflect everyday in-city usage patterns, you can expect accuracy from 3 – 150 meters (10 ft – 500 ft) or greater and the accuracy number typically fluctuates quite a bit over a period of minutes or hours. GPS signals are affected by anything that interferes with your smartphone receiving the weak transmissions from GPS satellites circling above us. Nearby trees, cars, buildings, big weather storms can all reduce accuracy, and so can being inside a building or underneath trees.

Getting the weather. Now back to the everyday scenarios I mentioned. I bet that most people who own smartphones use them to check the weather at least once per day. Furthermore, weather is typically affecting a large geographic area so the vast majority of forecasts cover cities, counties, States, regions or even entire countries.

I’m going to argue that for this scenario a GPS accuracy of 1000 to 2000 meters, or 0.6 to 1.24 miles is good enough to get started with a finding places app. Values in this accuracy range can be easily and quickly retrieved by a typical smartphone.

Finding places around me. Almost everyone that owns a smartphone has used an app to search for food, gas, groceries etc that are nearby.  There’s no hard written rule, but I think most people would agree that users who are looking for places around them tend to be less concerned about high levels of accuracy. Some applications let you choose target levels of accuracy such as 1 mile, 10 miles or even up to 100 miles for the search radius.

I’m going to argue that for this scenario, as well, that a GPS accuracy of 1000 to 2000 meters will also work perfectly fine.

Real-time driving directions. There are only a handful of applications that do this on smartphones, and even fewer apps do it really well. There’s a lot of hidden math involved in making everything look smooth to the user. These apps wipe away all of the complexity: simply give it a starting point and an endpoint and then away you go.  We’ve all used these types of applications so we know they work well the majority of the time even with the occasional navigational glitch, hardware lockup or low battery.

Social Media location. Hundreds of millions of people use location-aware social media apps every day. Some of these apps provide you with discounts, give-aways and coupons for retail locations that are around you.  For a typical big box store, it’s easy for an app to place you in the parking lot of a Target, Walmart, or a large supermarket and promotions can be based on your location, time of day or day of the week. It’s more challenging for stores with smaller storefronts to use targeted advertising unless someone is simply “in the vicinity”.  For example, tiny stores, kiosks and shops trying to compete in high traffic tourist areas have to compete with many other vendors. In a crowded marketplace area, even with 3 meter accuracy you could be standing next to four or more different storefronts.

A final few words

Hopefully these short examples have successfully illustrated the point that for typical consumer-focused applications smartphone GPS is simply good enough. Certainly there are many, many more scenarios that could be examined so I tried to pick the most common ones. Because of the lower accuracy requirements you can get less accurate results faster from a GPS. Speedy results can mean everything for today’s consumers who have high levels of intolerance for application delays.

The opposite is also true, the greater the accuracy requirements the longer it can take to get a more precise GPS measurement. As I’ve mentioned in my others posts on this subject, it’s takes time for a GPS device to get a fix and then it will try its best to hold onto it as you move around. I suspect that most consumers are significantly less demanding about accuracy as compared to commercial and government users. If consumers were more demanding then there would be a greater uproar about GPS accuracy.

To better understand how to make the most of location data check out the other posts I’ve written in the reference section below.

References:

Six most common use cases for Android GPS

How accurate is Android GPS? Part 1 – Understanding location data.

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

OSCON 2013 – Presentation on Android SDK Geolocation

If you are headed to OSCON, swing by my session on Mastering Android Geolocation. It’s a deep dive into the Android SDKs android.location package. If you’ve ever wanted to learn about the fundamental’s of the SDKs Geolocation capabilities then this is a must attend session. It will also give you a strong foundation to understand the underlying capabilities of the new Google Play Services SDK that includes Fused Location, Activity Recognition, and Geofencing APIs.

The presentation includes digging into the capabilities of my open source GPS Testing tool that lets you easily test different aspects of the Geolocation capabilities.

Here’s the details and I hope to see you there:

 Location, Location, Location: Mastering Android Geolocation
07/25/2013  5:00pm –  5:40pm PDT (40 minutes)
Room: Portland 251 (capacity: 200)
http://www.oscon.com/oscon2013/public/schedule/detail/28713

Smartphones aren’t getting any smarter

As an Android and mobile web developer, I feel compelled asking people I know or meet a lot of questions about their phones. One trend I’ve been seeing is feedback that smartphones, themselves, aren’t really getting any smarter. The ironman/crossfit marathon to add new features at warp speed has left behind a trail of cool phones that have some fundamental issues. So, I’m going to take a look at some of these here.

To put things in perspective, at Google I/O 2013, Sundar Pichai announced that there have now been 900 million Android activations world-wide to date. That’s not including iPhone activations, of course. But, Yeow, that’s a lot of phones! So, let’s look at some things that haven’t improved much. It’s almost like Newton’s Third Law of Motion can be applied to smartphones: while some things improve, other things must take a back seat.

Security. I can say this with certainty – I have yet to see or hear about a smartphone advertisement that says something such as “we’re striving to make this phone the most secure phone yet.” One thing is clear that Apple’s app vetting process helps reduce the level of malware compared to Google Play. Sure I understand that nothing is 100% secure, but the operating system vendors and the handset vendors could at least talk about it.  And, why don’t smartphones come with built-in, optimized versions of virus checkers and anti-malware tools like Windows PCs and laptops?

Most people’s lives could be seriously disrupted by the data stored on your typical smartphone, and we lose these and leave them behind accidentally by the thousands, and we inadvertently install malware.

Case in point – do a search on Google or bing using the term “smartphone security”, and see how many articles are published by the major phone vendors about security and securing your phone. The top result is by the FCC about their Smartphone Security Checker.

Restoring an Android phone. If you reset your droid or buy a new one, restoring everything back to the way it was and in it’s exact place, well…a very manual process. This is not very user friendly. Hey Android vendors, you should take a lesson from Apple on this one.

Display brightness and energy consumption. Phone displays appear to continue to be the “number one” draw on battery life. I’ve started to think most (many?) like their screens really bright. I mean realllly bright. It’s funny, I keep mine pretty dim to squeeze as much life out of the battery as possible, and I’ve lost count of the number of times people have said something like “how can even you see what you are doing??”

GPS energy consumption. My Garmin GPS lasts over 17 hours of continuous usage with two AA batteries. The battery on a typical smartphone has much greater storage capacity, but in actual field tests I’ve killed smartphone batteries in as little as 4 -5 hours of continuous GPS usage. GPS used wrong is a huge draw on the devices battery. Sure, a smartphone is doing a lot more work than a typical, single purpose GPS. But, my point is why hasn’t GPS battery consumption improved over five generations of smartphones? Those of us who build GPS-based native and web apps have to jump through hoops to optimize battery life in applications that do more than take a snapshot of the users current location. Some of the algorithms we write should simply be built-in to the firmware.

Charging times. Now I admit this varies from phone-to-phone but it’s still not very fast in general. I know I have said before that many people are never more than 10 feet from a charger, but for those of us who aren’t that attentive to charging I can say charging times can be an issue. For example, my iPad (okay it’s more of a tablet than a smartphone) is the slowest charging device on the planet compared to my original Google Ion which charged from dead to full in about an hour and a half. Sure, I understand there is a huge difference in battery size, but my point still stands. The cute, itty-bitty charger for iPad is way under-powered for the needs of charging a larger battery.  And, maybe some people are okay with that?

Planned Obsolescence.  This one is totally on Android. I’ve lost track of the number of Android phones that I have sitting around that have been rendered obsolete because the handset manufacturer provided one or maybe even two OS updates to the phone, and then they stopped. They become obsolete in the sense that some apps don’t run on older versions of the operating system. Sure, the upgrades are enticing (better camera, more memory, faster processors, etc. etc.) but what if someone doesn’t want or need to upgrade?

This may become more of an issue for people as some carriers are stopping their subsidies of phones and pushing users to carry the cost of a new phone directly. And new phones can give you sticker shock. If you have to pony up $350 – $600 for that new phone and all it’s advertised features, you might not be inclined to upgrade phones as often as you used to.

Wrap-up. So, I’ve written a mish-mash of different things that should be improved for both Android and iPhone. What I’d really like to see, and it probably won’t happen, is for Android, Apple and Microsoft to take a step back from the feature/functionality marathon and work on some fundamental issues to build an even stronger foundation for the next generation phones.

 

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.

References

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

Android emulator vs actual device

Native Android apps and web apps need to be tested on multiple phones and tablets before being placing into production. Period. Sure you can use the emulator to do some very basic UI sizing validation, but there is no substitute for testing on actual devices.

Typically, I have one phone with the latest version of the OS and the rest of my phones are WiFi-only and have no carrier agreement. Buying used devices with no cellular contract is one way to save money, and can help budget strapped shops to do more thorough cross-device quality assurance (QA) tests. Obviously there are too many different types of Android devices on the market for the typical shop to have all of them in house, but having a few different models and versions gives you a huge QA advantage.

Why not use the out-of-the-box emulator? I’m not saying you shouldn’t use the emulator at all. It can be a valuable tool for check UI differences across various screen sizes and resolutions. But, in my opinion that’s about it. Personally I don’t use the out-of-the-box Android emulator much at all for daily coding since I almost always have a phone handy. Here are a few things that an emulator cannot help you test:

  • Exact look and feel
  • Application load times
  • Application performance
  • UI performance (View transitions, orientation changes, scrolling)
  • Browser differences (for web apps)
  • Subtle differences in UI touch events
  • Real-world GPS testing
  • Battery usage/consumption
  • Unique characteristics from the handset manufacturer and carrier.

My final beef with the Android emulator is it is awfully slow even on powerful laptops. It’s simply not a feasible test platform if you have to do multiple builds in a reasonable amount of time. Waiting for the emulator to load can be a painful experience. Granted, under some circumstances you can leave a single instance of the emulator running and push multiple builds to it, it can still seem sluggish. From a productivity standpoint, my experience has been its cumulatively much faster to simply push builds to a phone. And then, as mentioned above, reserve the emulator for specific instances of testing screen sizes and resolutions.

Recommended bare-bones set up. I don’t have a particular manufacturer recommendation because that’s a personal choice. My bare-bones recommendations are more focused on Android SDK version and having at least one phone with the major versions. Since Donut-based v1.6 phones now represent 0.2% or less of all phones I no longer recommend testing on it. Having a v2.x phone is a really good idea for general distribution apps as it’s a fact that roughly 50% of the phones in circulation are still running it:

  • V2.x smartphone
  • V3.x smartphone
  • V4.x smartphone
  • V4.x tablet

If you have experience with testing across different versions please post your comments!

References

Using the Android Emulator

Android Version Dashboard

Supercharge your Android Emulator

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.

locationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER,0,0,listener);

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
     }
     else{
          //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.

References

Google Developer docs – Location Strategies

Android blog – Deep dive into location

GPS Testing Tool (open source)

HTML5 Geolocation API – How accurate is it, really?