I am experimenting with Androids location updates. The requestLocationUpdates is responsible for providing the updates. With the following code:
locationManager.requestLocationUpdates(provider, 300000, 10, this);
I am only supposed to receive updates 5 minutes and 10 meters apart. But the updates just keep coming in seconds apart and even when I am sitting still.
GPS is the provider I am using.
I need to space the updates out. What can I try?
The 10m is too small - I would increase that. GPS accuracy isn't great, and so every time it senses a small difference you will get another location. I'd bump it up to 100m and I expect you will then get a sensible number of locations coming through.
If you do want it more specific, then you'll need to handle the volume as more accurate means more volume.
Hers what i'd do:
First of all I check what providers are enabled. Some may be disabled on the device, some may be disabled in application manifest.
If any provider is available I start location listeners and timeout timer. It's 20 seconds in my example, may not be enough for GPS so you can enlarge it.
If I get update from location listener I use the provided value. I stop listeners and timer.
If I don't get any updates and timer elapses I have to use last known values.
I grab last known values from available providers and choose the most recent of them.
The 10m is too small for a GPS reading, try 100m. You'll also have issues with power saving mode, and app battery optimisation on most Android phones.
Android 10 and above has very strict background location updates, and may kill apps that run in the background. Later versions will also remove apps that have not be used recently.
Related
Android 8 only allows background location updates a few times per hour. This isn't a problem since I only request them about once an hour and only if the device isn't STILL and there arn't already passive updates doing the job. So maybe a few times a day. No detectable battery use on Android 7.
However, I do have an accuracy requirement and I discard locations with horizontal accuracy worse than about 1000 feet (Basically cell tower locations). The problem is that the network location comes almost instantly, and then the app is throttled and never receives the next update which might come from the GPS. Typically I would wait a minute to get a location with the desired accuarcy and then give up. On Android 8, even if I wait an hour I just get the network location every 20 minutes or so because of the throttling.
I can't find any LocationRequest setting for miniumum accuracy which would solve the problem entirely. PRIORITY_HIGH_ACCURACY absolutley does NOT do this. It is only a "hint". setSmallestDisplacement() doesn't help because it doesn't affect the first update. Batching updates helps on rare occasions in my testing but not with any reliability.
Further, waiting in PRIORITY_HIGH_ACCURACY for any length of time is not reasonable from a user perspective since the location indicator will be active on the device the whole time, even if the app is being throttled.
Does anyone have suggestions on how I could solve this problem? Perhaps Android does not intend for PRIORITY_HIGH_ACCURACY to be used in the background at all, although I can find nothing about this in the documentation.
If you need GPS, just use the GPS provider. Don't screw around with the Criteria, request what you really need.
I am developing an android application wherein I need the user location updates pretty frequently. Say 2 times a minute.
Earlier I had been using Google Play Service's "Fused location service" but the location updates were not received as requested.
The location updates got stuck for sometime, the interval between updates jumped to 10min or so.Sometimes even if I put my priority to "PRIORITY_HIGH_ACCURACY" the same happened.
I then went back to the old "Location Manager" and when I used the "NETWORK_PROVIDER", I noticed that the location updates got stuck due to this provider. Also the GPS does not get activated immediately, it takes some time. I am trying to build my custom fused location provider. How can I efficiently switch between providers, without getting lags on location updates.
I want to know what are the best practices for getting location updates regularly, all the time, be it either NW, GPS or both. Like it should work for an application where location updates getting stuck cannot be afforded.
Battery drain is not an issue for me right now.I am aware of all the supporting docs that Google provides regarding location access.
Any help would be much appreciated.
Thankyou !
FusedLocationProvider really is the best option for obtaining locations at the moment, because it uses a lot more than just GPS or Network data to obtain location fixes. I have experienced issues regarding intervals being missed as well, but ultimately this is something down to luck depending on availability of GPS, Network, etc. etc.
My favourite usage of FusedLocationProvider so far is in conjunction with the AlarmManager class: Basically, the idea is to start location tracking at intervals specified by the Alarm Manager (this can be set to every 30 seconds such as in your case). Once the interval is hit, the location provider is to obtain a location fix as soon as possible (so in the setInterval method or whatever it's called, the parameter is a 0). This way, you can avoid having to wait another 30 seconds for a new location, instead having the location tracker attempt to provide a location as soon as possible after the interval specified by the Alarm Manager is hit.
By the way, when making custom location tracking wrappers, be careful of using the .getLastKnownLocation() method as it only uses cached locations - you could end up sending the same location to the user every 30 seconds.
Good luck!
I have a background service which works periodically by timer.scheduleAtFixedRate.
It wakes up every amount of time (let's say 60 seconds for example) and checks for the location.
The location is checked by locManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 60000, 5, listener); and the actual location is collected from the listener's onLocationChanged.
Now, when the phone is outside and GPS reception is good, this works fine.
But, if the phone is inside, the GPS is almost always active - looking for a signal, and the battery is drained rapidly.
I created another thread using a Handler and a Runnable in order to conrol the GPS active time accurately:
I used locManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, 0, 0, listener); and locManager.removeUpdates(listener); so I can open and close the GPS as I want.
In this case, I can open the GPS for the exact amount of time, but found out that it doesn't lock in an area with good reception even after 10 seconds. So here I'm draining the battery again...
I'm using API level 7, hence I cannot use locationManager.requestSingleUpdate.
I have two questions:
Is there any way to optimize this process?
Will upgrading to API level 9 (and use locationManager.requestSingleUpdate) improve the process significantly? I mean, does it worth upgrading?
How about NETWORK_PROVIDER explained here?
You could have a system that if you cannot find a location in limited set of time, which means you are inside or GPS reception is not good enough, you can use the network location instead. Since that uses less battery, it would at least be a workaround or alternative. But the presicion would be lower.
My app uses LocationListener to keep track of the current location. So long as the GPS Provider is providing regular fixes this works well. However, I want my app to alert the user if the location is no longer reliable because the fix is no longer current. I have therefore used a timeCheckHandler to call getLastKnownLocation every few seconds.
My problem is that even when accurate fixes are being received frequently the time returned by applying getTime() to the location returned by getLastKnownLocation is generally older than the current time returned by System.currentTimeMillis(), often by about 20 seconds.
I have investigated the problem further by adding code to onLocationChanged(arg0) to log the time of the fix (arg0.getTime()) and the current time (System.currentTimeMillis()). Again I see a difference of about 20 seconds.
The code currently reads as follows:
public void onLocationChanged(Location arg0) {
mapview.handleLocationChanged(mapview, arg0.getLatitude(), arg0.getLongitude(), arg0.getBearing(), arg0.getAccuracy(), "GPS fix");
addDebugNote("Fix received at time: "+Long.toString(arg0.getTime()/1000)+" Now: "+Long.toString((System.currentTimeMillis())/1000));
}
and typical output to my Debug file reads:
Fix received at time: 1292091908 Now: 1292091928
Why should I be seeing this difference between the fix time and the current system time?
Do I have to accept that a difference of around 20 seconds is normal?
GPS location time comes independently of your network provider time/device time. System.currentTimeMillis() will give you device time set on your device.
If you want to know how recent the point is you can:
Synchronize both the times ( GPS and device ) in your code at application start by taking the difference between both as soon as you get first GPS location update. At that instant query device time and see what's the difference in both. Save this difference in variable.
Use this as a correction factor in subsequent location updates to know the exact time based on the reference frame you need. ( Device time or GPS)
Also I had found that using NETWORK as location provider you may get device time only. So if you are listening on updates from both ( GPS and network ) , you may also need to distinguish this using location_obj.getProvider() and filter out GPS provider.
Repeating the test today I have found that the difference between the GPS time and the System time is 22 seconds. This issue is discussed elsewhere on the web and it seems that it is normal for there to be a difference between GPS time and the phone's system time (which in my case is set to be updated automatically from the network.) One factor is that GPS time is about 15 or 17 seconds (depending on which source is correct) from UTC time ... it is out-of-sync because GPS time has not been updated since 1980 for periodic "leap seconds."
Bearing this in mind I think the answer to my need to check how current the latest fix is will be to compare the current system time with the system time (not the GPS time) of the latest fix.
I'm trying to limit my program to take location updates every 10 seconds instead of constant updates in order to reduce battery drain. This works fine when i'm debugging indoors and the signal is weak (i.e. the GPS icon flashes), but if the phone gets a proper fix (i.e. the GPS icon is static) the update interval increases to roughly a second.
I know that the code mLocationManager.requestLocationUpdates(LocationManager.GPS_PROVIDER, updateInterval*1000, 0, this); will not force the GPS to take updates exactly at the given interval, but in my opinion it shouldn't depend on the strength of the signal and fluctuate that much.
Any ideas?
UPDATE: see comment
I suspect that the GPS radio works in a manner where either it's connected to GPS satellites or it's not. When it's connected, the Android SDK sends you updates as frequently as they're available from the GPS hardware. When it doesn't have a full GPS connection it falls back to sending AGPS updates according to what you've requested.
If you only want updates every 10 seconds, you should save the last received Location's time value in your listener, and when you receive a new Location check its time against the old value; ignore it if it's too frequent (or do something smarter like checking the accuracy and replacing the old value, etc).
Maybe it works slower because you are debugging, but not because your signal is weak! Try to make tests with disconnected debugger indoors...