Wednesday, October 12, 2011

[android-developers] major problem with network location fixes and their timestamps

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+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en

No comments:

Post a Comment