Fused Location Provider unexpected behavior
this is how I register my app to receive location updates:
mLocationRequest = LocationRequest.create();
mLocationRequest.setInterval(Consts.ONE_MINUTE * 10);
mLocationRequest.setPriority(LocationRequest.PRIORITY_BALANCED_POWER_ACCURACY);
mLocationRequest.setFastestInterval(Consts.ONE_MINUTE);
Builder builder = new GoogleApiClient.Builder(context);
builder.addApi(ActivityRecognition.API);
mGoogleApiClient = builder.addConnectionCallbacks(this)
.addOnConnectionFailedListener(this)
.build();
mGoogleApiClient.connect();
....
....
@Override
public void onConnected(Bundle connectionHint) {
LocationServices.FusedLocationApi.requestLocationUpdates(mGoogleApiClient, mLocationRequest, locationUpdatespendingInent);
}
my pending intent been invoked in background almost in the exact requested intervals...
so far so good.
the problem: When WIFI is disabled/ not connected to any network, or when there is no 3G/4G network data enabled - the fused location provider not providing new location updates!!
my Location access settings are turned on, and GPS satellites and WI-FI & mobile network location is checked.
the even bigger problem: sometimes in that case, I do receive location updates callbacks via the pending intent, but with the last location it knew (even if it was an hour ago, and I'm long long gone away miles from that place)
according to the documentation of PRIORITY_BALANCED_POWER_ACCURACY :
Used with setPriority(int) to request "block" level accuracy. Block level accuracy is considered to be about 100 meter accuracy. Using a coarse accuracy such as this often consumes less power.
I'm expecting that the fused location provider will open the GPS when it have no other choice, or at least won't provide a new location updates if he don't have any.
another unpredictable and disturbing issue:
I changed PRIORITY_BALANCED_POWER_ACCURACY to PRIORITY_HIGH_ACCURACY in order to see how it behaves (for 24 hours). all the intervals stayed the same (10 minutes interval between updates). accurate location indeed received even in phones with no network/sim card, but - the battery drained out fast! when I looked on the battery history, I was surprised to see that GPS radio was on full transmission mode all the time!!!! and I saw also in my log that loction was received every minute, even that I requested location each ten minutes (I don't have any other installed apps that opens GPS to receive locations..)
I noticed this behavior on several devices (such as Moto X 2013, HTC One X, Nexus 5) , all with latest Google Play Services (version 6.1.11) , and android KITKAT 4.4.4
my application depends a lot on the user current location, and periodically receives location updates in the specified interval as long as the user logged in, so I don't want to use the PRIORITY_HIGH_ACCURACY mode, to prevent battery drain..
my questions:
is the fused location provider suppose to use GPS at all if it set to receive updates with
PRIORITY_BALANCED_POWER_ACCURACYand don't have any WI-FI or cell towers info ?if it does, then what am I doing wrong?
why I'm getting this misleading location updates that are not correct? (as I explained in the the "even bigger problem" section..
why GPS radio is opened all the time instead of been opened for the 10 minutes interval when I used the
PRIORITY_HIGH_ACCURACYparameter? (I don't have other installed apps that triggers location updates faster..)
Solution 1:
For the questions specified,
1. is the fused location provider suppose to use GPS at all if it set to receive updates with PRIORITY_BALANCED_POWER_ACCURACY and don't have any WI-FI or cell towers info ? &
2. if it does, then what am I doing wrong?
Apparently no explicitly unique source is specified anywhere within documentation. With either PRIORITY options, even through code, the "source" of obtained location is "fused".
[location.getProvider() returns :"fused"]
I have seen GPS being used only when the LocationRequest has PRIORITY_HIGH_ACCURACY. So it does not use GPS under other conditions.
4. why GPS radio is opened all the time instead of been opened for the 10 minutes interval when I used the PRIORITY_HIGH_ACCURACY parameter? (I don't have other installed apps that triggers location updates faster..)
The fastest interval has been set for 1 minute. From what i understood, the setFastestInterval is given precedence over setInterval when the value for fastest interval is shorter in duration than the value of setInterval.
In your case, 1 minute against 10.
About not having other installed apps that triggers location updates, its just given as an example and not specified that only that case explicitly.
This controls the fastest rate at which your application will receive location updates, which might be faster than setInterval(long) in some situations (for example, if other applications are triggering location updates).
So, what happens is with PRIORITY_HIGH_ACCURACY, it requests location on the fastest interval set - 1min, by using GPS(kind of exclusively).
3. why I'm getting this misleading location updates that are not correct? (as I explained in the the "even bigger problem" section..
Need to check the code for pendingIntent mechanism also. Though there could be a few things to take note of:
You can add a location.getTime() to ensure and verify the time of obtained location. Very likely it is not being updated, if there is no wifi-cell towers in range and PRIORITY_BALANCED_POWER_ACCURACY is used.
A block level accuracy of location on the first place, which is being used when "lastKnown" is called wouldn't help.
The battery consumption was because of the combination of GPS and 1 min updates. Try setting the fastest interval as 5 or 10 mins, if that is suitable for your implementation but PRIORITY_BALANCED_POWER may not help if you need absolutely accurate location. I normally add a check for the location obtained in onLocationChanged and depending on that, switch the priority in LocationRequest. It helps in, surely, obtaining a location generally, unless i am inside a building with no line-of-sight for GPS and Wifi-Network are off.
Solution 2:
I would suggest you to use AlarmManager and FusedLocationProvider together in such a way that your AlarmManager fire alarm on every 10minute with a view to start location updates.
Once you get updated location, disconnect the location client. You don't need to keep it running for all the time by setting interval time in LocationRequest, Instead you can invoke the process on each time interval by using AlarmManager.
In such kind of mechanism, you will have following benefits which will resolve your problems:
- GPS radio will stay open only for few seconds while retrieving location because you are going to disconnect after getting first location update. Thus GPS radio will not stay open all the time so the battery will be saved.
- You will be able to get new location on each 10minutes without messing around with old location or something.
I hope it will be helpful.
Solution 3:
Cell towers cover a several mile area so they aren't the best for getting a location from. Look at the location accuracy when you are working with locations.
@Override
public void onLocationChanged(Location location) {
//it happens
if (location == null) {
return;
}
// all locations should have an accuracy
if (!location.hasAccuracy()) {
return;
}
// if its not accurate enough don't use it
// this value is in meters
if (location.getAccuracy() > 200) {
return;
}
}
You could put a broadcastreceiver on the network status and when there is no connection you could restart your location provider with priority_high_accuracy which will use the GPS only when the user has the GPS enabled otherwise it falls back on the wifi and cell towers.
<action android:name="android.net.conn.CONNECTIVITY_CHANGE"/>
/** Checks whether the device currently has a network connection */
private boolean isDeviceOnline() {
ConnectivityManager connMgr = (ConnectivityManager) activity
.getSystemService(Context.CONNECTIVITY_SERVICE);
NetworkInfo networkInfo = connMgr.getActiveNetworkInfo();
if (networkInfo != null && networkInfo.isConnected()) {
return true;
}
return false;
}