Can't say that I've seen that before. I've only used the GPS a small to medium amount, but seems a little weird.
Is the GPS hardware not able to get a fix and causing your logic to drop back to the network GPS? If so, it might be that. Is it happening on multiple different devices and how many devices have you tested it on? You might want to check out the GPS Status app on the market and see if it gets a fix. If it does, it will tell you the time it got it and other information about the fix. Good way of testing the hardware and see if you have an issue there. Steven Studio LFP http://www.studio-lfp.com On Wednesday, October 12, 2011 9:44:54 AM UTC-5, Mathias wrote: > > 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
