-
-
Notifications
You must be signed in to change notification settings - Fork 217
Stale location reported when backend calls report(null) #75
Description
This came out of an issue in the openBmap backend, openbmap/radiocells-nlp-android#13: After getting stale locations under some circumstances, I did some investigations and introduced some modifications into the backend.
The backend does a combined cell/wifi lookup, either online or using an offline DB (all my tests were done with the offline DB).
Steps to reproduce:
- Fire up an appropriate app in an environment with known wifis. I used SatStat, available on F-Droid, which visualizes both GPS and network location along with their accuracies. Check location, then return to home screen making sure no other app requests location updates).
- Move to a location with no known cells and wifis at all, and fire up the app again.
The first step behaved as I expected: the modified backend gave me a crisp (+/- 20 m) location. The second step was performed some 5 minutes after leaving the previous location. SatStat claimed I was still within 20 meters of the old location, even after I killed and restarted it (to rule out any caching in SatStat).
Analyzing the logcat, I find that I originally had 26 wifis in range, from which the backend calculated a location and reported it. In the metro station, the backend reported that no wifis were in range and the only visible cell was not in the DB. It reported a null location, resulting in a call to . Then, however, UnifiedNLP (specifically NlpLocationBackendFuser) reports the same location it has given out 5 minutes before, with the same et=+15d21h34m50s905ms (which I suppose is the timestamp) and the same accuracy acc=20.report() with a null argument
Are backends supposed to call report(null) when they are unable to determine the current location, or should they simply not call report() at all? This should probably be documented in the API README.
In any case, the fuser probably should not give out old locations unmodified: when processing any location, its accuracy should be penalized based on its age (if you're interested, I can provide a link to my branch of the openBmap backend for an example on how to fuse locations of different ages) and the resulting location should have a recent timestamp.