Android network location provider

Android Location Providers (gps, network, passive)

Oct 20, 2010 ∙ Nazmul Idris

• Hi, I’m Nazmul, a Google software engineer, entrepreneur, leader, designer, dancer, TaiChi’er, Yogi, racer, healer, and storyteller. I leadership, authenticity, empowerment, lifelong learning, , & 😃.

Introduction #

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:

Accuracy	Power Usage	Technology
20ft	High	Autonomous GPS, Provider: gps uses GPS chip on the device line of sight to the satellites need about 7 to get a fix takes a long time to get a fix doesn’t work around tall buildings
200ft	Medium — Low	Assisted GPS (AGPS), Provider: network uses GPS chip on device, as well as assistance from the network (cellular network) to provide a fast initial fix very low power consumption very accurate works without any line of sight to the sky depends on carrier and phone supporting this (even if phone supports it, and network does not then this does not work)
5300ft / 1mile	Low	CellID lookup/WiFi MACID lookup, Provider: network or passive very fast lock, and does not require GPS chip on device to be active requires no extra power at all has very low accuracy; sometimes can have better accuracy in populated and well mapped areas that have a lot of WiFi access points, and people who share their location with Google

Android layers these underlying techniques and technologies into the 3 network providers listed above. There is no good way know exactly what Android will use, since all phones are different. Eg, on VZW network, the LG Ally does NOT have AGPS! The Droid 2 has all providers (AGPS, GPS, CellID, etc). On ATT network, almost all phones tend to have AGPS enabled by default, etc. Varies by network, by coverage area, and by country, and by device. Also, on VZW, the passive provider ends up using Verizon Location Services, which are very inaccurate (less accurate than 1 mile).

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 RainOrShine, showing the “network” provider accuracy. Our 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.

In all our code (for ScreamingToaster products), we 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).

Code samples #

Here is the code that you have to run in order to create a GPS enabled app, using an Android Activity or Service:

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.

Summary #

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

Источник

Location services on Android

This guide introduces location-awareness in Android applications and illustrates how to get the user’s location using the Android Location Service API, as well as the fused location provider available with the Google Location Services API.

Android provides access to various location technologies such as cell tower location, Wi-Fi, and GPS. The details of each location technology are abstracted through location providers, allowing applications to obtain locations in the same way regardless of the provider used. This guide introduces the fused location provider, a part of the Google Play Services, which intelligently determines the best way to obtain the location of the devices based on what providers are available and how the device is being used. Android Location Service API and shows how to communicate with the system location Service using a LocationManager . The second part of the guide explores the Android Location Services API using the LocationManager .

As a general rule of thumb, applications should prefer to use the fused location provider, falling back the older Android Location Service API only when necessary.

Location fundamentals

In Android, no matter what API you choose for working with location data, several concepts remain the same. This section introduces Location Providers and location-related permissions.

Location providers

Several technologies are used internally to pinpoint the user’s location. The hardware used depends on the type of location provider selected for the job of collecting data. Android uses three location providers:

GPS Provider – GPS gives the most accurate location, uses the most power, and works best outdoors. This provider uses a combination of GPS and assisted GPS (aGPS), which returns GPS data collected by cellular towers.

Network Provider – Provides a combination of WiFi and Cellular data, including aGPS data collected by cell towers. It uses less power than the GPS Provider, but returns location data of varying accuracy.

Passive Provider – A «piggyback» option using providers requested by other applications or Services to generate location data in an application. This is a less reliable but power-saving option ideal for applications that don’t require constant location updates to work.

Location providers are not always available. For example, we might want to use GPS for our application, but GPS might be turned off in Settings, or the device might not have GPS at all. If a specific provider is not available, choosing that provider might return null .

Location permissions

A location-aware application needs access a device’s hardware sensors to receive GPS, Wi-Fi, and cellular data. Access is controlled through appropriate permissions in the application’s Android Manifest. There are two permissions available – depending on your application’s requirements and your choice of API, you will want to allow one:

ACCESS_FINE_LOCATION – Allows an application access to GPS. Required for the GPS Provider and Passive Provider options (Passive Provider needs permission to access GPS data collected by another application or Service). Optional permission for the Network Provider.

ACCESS_COARSE_LOCATION – Allows an application access to Cellular and Wi-Fi location. Required for Network Provider if ACCESS_FINE_LOCATION is not set.

For apps that target API version 21 (Android 5.0 Lollipop) or higher, you can enable ACCESS_FINE_LOCATION and still run on devices that do not have GPS hardware. If your app requires GPS hardware, you should explicitly add an android.hardware.location.gps uses-feature element to the Android Manifest. For more information, see the Android uses-feature element reference.

To set the permissions, expand the Properties folder in the Solution Pad and double-click AndroidManifest.xml. The permissions will be listed under Required Permissions:

Setting either of these permissions tells Android that your application needs permission from the user in order to access to the location providers. Devices that run API level 22 (Android 5.1) or lower will ask the user to grant these permissions each time the app is installed. On devices running API level 23 (Android 6.0) or higher, the app should perform a run-time permission check before making a request of the location provider.

Note: Setting ACCESS_FINE_LOCATION implies access to both coarse and fine location data. You should never have to set both permissions, only the minimal permission your app requires to work.

This snippet is an example of how to check that an app has permission for the ACCESS_FINE_LOCATION permission:

Apps must be tolerant of the scenario where the user will not grant permission (or has revoked the permission) and have a way to gracefully deal with that situation. Please see the Permissions guide for more details on implementing run-time permission checks in Xamarin.Android.

Using the fused location provider

The fused location provider is the preferred way for Android applications to receive location updates from the device because it will efficiently select the location provider during run time to provide the best location information in a battery-efficient fashion. For example, a user walking around outdoors gets the best location reading with GPS. If the user then walks indoors, where GPS works poorly (if at all), the fused location provider may automatically switch to WiFi, which works better indoors.

The fused location provider API provides a variety of other tools to empower location-aware applications, including geofencing and activity monitoring. In this section, we are going to focus on the basics of setting up the LocationClient , establishing providers, and getting the user’s location.

The fused location provider is part of Google Play Services. The Google Play Services package must be installed and configured properly in the application for the fused location provider API to work, and the device must have the Google Play Services APK installed.

Before a Xamarin.Android application can use the fused location provider, it must add the Xamarin.GooglePlayServices.Location package to the project. In addition, the following using statements should be added to any source files that reference the classes described below:

Checking if Google Play Services is installed

A Xamarin.Android will crash if it tries to use the fused location provider when Google Play Services is not installed (or out of date) then a runtime exception would occur. If Google Play Services is not installed, then the application should fall back to the Android Location Service discussed above. If Google Play Services is out of date, then the app could display a message to the user asking them to update the installed version of Google Play Services.

This snippet is an example of how an Android Activity can programmatically check if Google Play Services is installed:

FusedLocationProviderClient

To interact with the fused location provider, a Xamarin.Android application must have an instance of the FusedLocationProviderClient . This class exposes the necessary methods to subscribe to location updates and to retrieve the last known location of the device.

The OnCreate method of an Activity is a suitable place to get a reference to the FusedLocationProviderClient , as demonstrated in the following code snippet:

Getting the last known location

The FusedLocationProviderClient.GetLastLocationAsync() method provides a simple, non-blocking way for a Xamarin.Android application to quickly obtain the last known location of the device with minimal coding overhead.

This snippet shows how to use the GetLastLocationAsync method to retrieve the location of the device:

Subscribing to location updates

A Xamarin.Android application can also subscribe to location updates from the fused location provider using the FusedLocationProviderClient.RequestLocationUpdatesAsync method, as shown in this code snippet:

This method takes two parameters:

Android.Gms.Location.LocationRequest – A LocationRequest object is how a Xamarin.Android application passes the parameters on how the fused location provider should work. The LocationRequest holds information such as how frequent requests should be made or how important an accurate location update should be. For example, an important location request will cause the device to use the GPS, and consequently more power, when determining the location. This code snippet shows how to create a LocationRequest for a location with high accuracy, checking approximately every five minutes for a location update (but not sooner than two minutes between requests). The fused location provider will use a LocationRequest as guidance for which location provider to use when trying to determine the device location:

Android.Gms.Location.LocationCallback – In order to receive location updates, a Xamarin.Android application must subclass the LocationProvider abstract class. This class exposed two methods which maybe invoked by the fused location provider to update the app with location information. This will be discussed in more detail below.

To notify a Xamarin.Android application of a location update, the fused location provider will invoke the LocationCallBack.OnLocationResult(LocationResult result) . The Android.Gms.Location.LocationResult parameter will contain the update location information.

When the fused location provider detects a change in the availability of location data, it will call the LocationProvider.OnLocationAvailability(LocationAvailability locationAvailability) method. If the LocationAvailability.IsLocationAvailable property returns true , then it can be assumed that the device location results reported by OnLocationResult are as accurate and as up to date as required by the LocationRequest . If IsLocationAvailable is false, then no location results will be return by OnLocationResult .

This code snippet is a sample implementation of the LocationCallback object:

Using the Android Location Service API

The Android Location Service is an older API for using location information on Android. Location data is collected by hardware sensors and collected by a system service, which is accessed in the application with a LocationManager class and an ILocationListener .

The Location Service is best suited for applications that must run on devices that do not have Google Play Services installed.

The Location Service is a special type of Service managed by the System. A System Service interacts with the device hardware and is always running. To tap into location updates in our application, we will subscribe to location updates from the system Location Service using a LocationManager and a RequestLocationUpdates call.

To obtain the user’s location using Android Location Service involves several steps:

1. Get a reference to the LocationManager service.
2. Implement the ILocationListener interface and handle events when the location changes.
3. Use the LocationManager to request location updates for a specified provider. The ILocationListener from the previous step will be used to receive callbacks from the LocationManager .
4. Stop location updates when the application it is no longer appropriate to receive updates.

Location Manager

We can access the system location service with an instance of the LocationManager class. LocationManager is a special class that lets us interact with the system location Service and call methods on it. An application can get a reference to the LocationManager by calling GetSystemService and passing in a Service type, as shown below:

OnCreate is a good place to get a reference to the LocationManager . It’s a good idea to keep the LocationManager as a class variable, so that we can call it at various points in the Activity lifecycle.

Request location updates from the LocationManager

Once the application has a reference to the LocationManager , it needs to tell the LocationManager what type of location information that are required, and how often that information is to be updated. Do this by calling RequestLocationUpdates on the LocationManager object, and passing in some criteria for updates and a callback that will receive the location updates. This callback is a type that must implement the ILocationListener interface (described in more detail later in this guide).

The RequestLocationUpdates method tells the system location Service that your application would like to start receiving location updates. This method allows you to specify the provider, as well as time and distance thresholds to control update frequency. For example, the method below requests location updates from the GPS location provider every 2000 milliseconds, and only when the location changes more than 1 metre:

An application should request location updates only as often as required for the application to perform well. This preserves battery life and creates a better experience for the user.

Responding to updates from the LocationManager

Once an application has requested updates from the LocationManager , it can receive information from the Service by implementing the ILocationListener interface. This interface provides four methods for listening to the location Service and the location provider, OnLocationChanged . The System will call OnLocationChanged when the user’s location changes enough to qualify as a location change according to the Criteria set when requesting location updates.

The following code shows the methods in the ILocationListener interface:

Unsubscribing to LocationManager updates

In order to conserve system resources, an application should unsubscribe to location updates as soon as possible. The RemoveUpdates method tells the LocationManager to stop sending updates to our application. As an example, an Activity may call RemoveUpdates in the OnPause method so that we are able to conserve power if an application doesn’t need location updates while its Activity is not on the screen:

If your application needs to get location updates while in the background, you’ll want to create a custom Service that subscribes to the system Location Service. Refer to the Backgrounding with Android Services guide for more information.

Determining the best location provider for the LocationManager

The application above sets GPS as the location provider. However, GPS may not be available in all cases, such as if the device is indoors or does not have a GPS receiver. If this is the case, the result is a null return for the Provider.

To get your app to work when GPS is not available, you use the GetBestProvider method to ask for the best available (device-supported and user-enabled) location provider at application launch. Instead of passing in a specific provider, you can tell GetBestProvider the requirements for the provider — such as accuracy and power — with a Criteria object. GetBestProvider returns the best provider for the given Criteria.

The following code shows how to get the best available provider and use it when requesting location updates:

If the user has disabled all location providers, GetBestProvider will return null . To see how this code works on a real device, be sure to enable GPS, Wi-Fi, and cellular networks under Google Settings > Location > Mode as shown in this screenshot:

The screenshot below demonstrates the location application running using GetBestProvider :

Keep in mind that GetBestProvider does not change the provider dynamically. Rather, it determines the best available provider once during the Activity lifecycle. If the provider status changes after it has been set, the application will require additional code in the ILocationListener methods – OnProviderEnabled , OnProviderDisabled , and OnStatusChanged – to handle every possibility related to the provider switch.

Summary

This guide covered obtaining the user’s location using both the Android Location Service and the fused location provider from Google Location Services API.

Источник