Hi, if someone could bear with me on this one i'd be most happy since i'm really disillusioned right now.
BOTTOM LINE (to be detailed further down): It seems as though the Location.getTime() sometimes isn't accurate, in that the system under certain circumstances just updates the time of an old fix and passes it on as though it was new. For us, this is very unfortunate. I think it has something to do with this logline (again in more detail below): 10-12 16:34:47.186: DEBUG/LocationMasfClient(1188): getNetworkLocation(): Returning cache location with accuracy 1072.0 >From what i can see, the same location is returned over and over again, just with its timestamp overwritten... EXPLANATION: Have an app that queries location. I register both network and gps, wait for a certain time and takes what comes back from either one and unregister both. Before i register i check the "latestknown" location and use that if it's not too old. All works fine, process wise, but there's one major issue. I *need* recent fixes, and for that i need to know how old the fix is. I therefore utilize location.getTime() against the system.currenttimillis to see how old it is. However, we see in certain scenarios, that the fix coming back, with a recent timestamp (often under a second!) is for a location where we know that the phone hasn't been at for over 30 minutes! LOCATION PROCESS EXPLANATION WITH LOG DETAILS: One VERY interesting thing can be seen by examining the debug log of a typical positioning process in my app: >>>1. first we check the "latest known" location: 10-12 16:34:47.166: DEBUG/nubaLocationService(6774): getLastKnownLocationForProviderWithinTimeSpan;now;1318430087165;time; 1318429486221;nowDate;Wed Oct 12 16:34:47 Europe/Stockholm 2011;timeDate;Wed Oct 12 16:24:46 Europe/Stockholm 2011;age; 600944;TooOld;true;tooBadAccuracy;true;lat;59.3267657;lon; 18.0428283;accuracy;1072.0 here you can see that the age about 60 seconds, my upper limit is 30 seconds, so i will discard it and register for "live updates": >>>2. register for location listening: 10-12 16:34:47.166: DEBUG/nubaLocationService(6774): requesting network updates 10-12 16:34:47.166: DEBUG/NetworkLocationProvider(1188): addListener(): com.karpet.nuba.android 10-12 16:34:47.166: DEBUG/NetworkLocationProvider(1188): setMinTime: 0 >>>3 NetworkLocationProvider log entries and onLocationChanged callbacks: Now HERE is something very interesting: 10-12 16:34:47.186: DEBUG/LocationMasfClient(1188): getNetworkLocation(): Returning cache location with accuracy 1072.0 10-12 16:34:47.196: DEBUG/NetworkLocationProvider(1188): onCellLocationChanged [142,9307015] 10-12 16:34:47.216: DEBUG/nubaLocationService(6774): onLocationChanged();new bestLocation! now;1318430087220;time; 1318430087178;nowDate;Wed Oct 12 16:34:47 Europe/Stockholm 2011;timeDate;Wed Oct 12 16:34:47 Europe/Stockholm 2011;age;42;lat; 59.3267657;lon;18.0428283;accuracy;1072.0;oldnull?;true It says "returning cache location", with the exact same accuracy, lon, lat, but CHANGED time! >>>4. We listen for 25-30 secs, but nothing more comes back, so eventually we >>>unregister: 10-12 16:35:14.216: DEBUG/LocationManager(6774): removeUpdates: listener = com.karpet.nuba.android.service.LocationService $NubaLocationListener@4582cb78 I have no idea why this happens, but sometimes we can start and stop our listening for quite a while, 20-30 times when we've travelled quite far, to another cell tower, but still get "old fixes as new" callbacks! Help/Pointers would be extremely appreciated! -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en