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.
Related
I'm seeing in docs that the object Location has a method getTime().
In my app, I need the server time, but sometimes, app can be offline, so I have no choice to get cel time. I would gladly use Location.getTime, but it is not clear to me where this time is coming from?
The Cel or the GPS Satelite???
Is it a reliable data for getting the current hour when app is offline?
As discussed in this question, Location.getTime() returns either
the device time (System.currentTimeMillis()) if Location.getProvider().equals(LocationManager.NETWORK_PROVIDER)
or
the GPS (satellite) time (in milliseconds but with 1s precision) if Location.getProvider().equals(LocationManager.GPS_PROVIDER)
Since the GPS location determination is based on the knowledge of the precise time, I would say it is at least as reliable as the time you would get from a server.
You can apply your local time zone to the GPS timestamp to get a human readable time, which sould be equal to a properly synced device time (in my case most of the devices where not, so it was even better to use the GPS time).
It is useful when you don't need a very precise time and you just want to know the date only regardless to precise time. Since as the documentation says:
All locations generated by the LocationManager are guaranteed to have
a valid UTC time, however remember that the system time may have
changed since the location was generated.
Also take a look at getElapsedRealtimeNanos() it seems to be more precise.
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'm writing some android code to test out the geolocation libraries and I'm running into a problem with the android emulator. I am creating a LocationListener and when LocationListener::onLocationChanged is called I check the time of the passed in Location object to compare it to the current time. I use the DDMS emulator control window to change the location to trigger the call to onLocationChanged. Here is the code that I use in the onLocationChanged method to compare the passed in location time to the current time ("location" is the location that is passed into onLocationChanged):
float accuracy = location.getAccuracy();
long curTime = System.currentTimeMillis();
float lateness = (curTime - location.getTime()) / 1000;
The problem I'm having is that the time I get from location using getTime is always way off of the current time (curTime) even though the time between when I set the location using DDMS and the time I look at it in the debugger is a matter of seconds. Usually the difference is several hours, and sometimes the time from location is several hours ahead of the current time (so the time of the location fix occurs several hours in the future?!?). Additionally, the time diffference is not consistent. The documentation for the call to Location::getTime and System.currentTimeMillies both say that the returned time is given in milliseconds since Jan 1 1970 UTC, so it shouldn't be an issue of using different time zones. Is this a known bug with the emulator or is there something I'm doing wrong? Thanks!
GPS time is actually different from time on the device. So, they can differ by a huge amount. Wiki has a nice explanation here
More information about this can be found at Android emulator's GPS location gives wrong time as well as the bug report link. Additionally Android problem finding out how recent latest GPS fix is may be worth reading as well as to why system time and GPS time won't match.
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.
I am using the requestLocationUpdates method of LocationManager to get GPS location updates. I am using a minTime parameter of 60000 to indicate that I'd like a location update every minute - I don't care about minDistance (I use a value of 0 as minDistance).
If I can understand correctly the android documentation, my LocationListener will be executed every minute to receive the current location. This is what happens with the emulator.
However, I couldn't understand what would happen between executions: Will the GPS be turned off every time ? And If the GPS is turned off, what will happen with the time needed to get a GPS fix (that time could be more than one minute) ? Will I get updates every 1 minute + (time neede to get the GPS fix) ?
Unfortunately the emulator cannot help me with these problems and I do not have an Android device in my hands right now, so If anybody has experience with this stuff help me !
Thanks in advance!
It is not specified, because that is implementation-specific.
The latest GPS chipsets can usually get a lock in well under a minute, often less than 20 seconds, so you should be fine.