2

I am working on an application with a requirement to track the current location, rather precisely over a long period of time.

I decided to use the Fused Location Provider API for that purpose since it is designed for battery saving and efficiency.

Over some time of testing now I have ended up with a couple deal- breaking issues in the fused location provider api or even deeper down the software stack in the NETWORK_PROVIDER ( which I believe is being used by the fused location provider ).

  1. Non- stationary wifi hotspots are setting the user off sometimes by thousands of kilometers. It seems to be the case that WIFI hotspots are used for triangulation even if they are portable devices. (Tethering/ Train wifi/ Airplane wifi) In that case the device thinks with great accuracy that it is exactly at the wrong location. One could argue that that can be filtered out but what makes things even more tricky is, that some magic including sensors is going on in the fused location provider so it appears the phone is being moved at those locations.
  2. Sometimes old locations are coming back I have observed that after a period of 2 weeks of uninterrupted location updates old locations start to resurface. This is especially weird since the locations in the callbacks are coming with a new timestamp.
  3. Locations with timestamps in the future: It took a lot of time to figure that one out, but I have also observed that users have been receiving timestamps in the future through their locations callbacks. I am in doubt wether the user's device is set to an incorrect time, because the timestamps are usually some weeks in the future. The fix for that is rather obvious, I am just gonna write it down here so you guys can take it into account when filtering out stuff.

I have tried all types of LocationRequest priorities and a lot of various parameters for them. The non-stationary WIFI issue remains in all scenarios and affects all apps on the device including google's own.

What came to mind first was to just try to ignore location locks coming in through WIFI triangulation but since there no way of knowing where the location comes from using the Fused location api, that idea was a deadend.

Filtering out those locations is also really tricky since well, the device often stays at wrong locations for hours/days and moves there.

I have found that there are already quite some google bug tracker issues that have been opened mentioning at least issue 1. (https://issuetracker.google.com/issues/37123060 for example) None of the issues has ever been addressed.

I am thinking of ditching the Fused Location provider for good since everything I try is a deadend. That leads me to ask the following questions:

  1. Is nobody else having these really blocking issues?
  2. Does anyone of you have experience with alternatives to the fused location provider? I have tried https://github.com/mapzen/lost, but I have found that general location noise is rather big and will require some work to get it to the state of google's api, and since it is also using the WIFI location provided by google, will probably have the same issue.
  3. Would you go down the path of falling back to a GPS only approach, probably sacrificing battery efficiency?
  4. Since the wrong locations effect all apps on the device including google's own location based apps, why is this issue not being prioritized by the tech giant who should have the greatest interest in being able to know where their customer currently is?

Thanks for any help.

EDIT: The issue is now being discussed as well at https://issuetracker.google.com/issues/37058437

**EDIT (August 8 2017) Added another strange finding in location callbacks

saberrider
  • 585
  • 3
  • 16

2 Answers2

0

First off, you need to stop thinking of location as a single coordinate. Nothing will get you that. Location is a probability field. Even using GPS, the location it gives you comes with an accuracy in meters. There's a 67% chance that the user is within that many meters of the location it gives you. Which means there's a 1/3 chance they aren't. Sometimes the difference is great- if you run gps all night, you'll get a couple of fixes that are hundreds of meters off. You just have to deal with this.

Secondly- Fused is a compromise. Its lower battery than GPS, but lower accuracy. Its good enough for most purposes. It may or may not be good enough for yours. The real questions are do you really need to be hyper accurate, and does being so add value to your users? Is the occasional bug in location worth draining their phone? This answer changes based on how frequently you need location data- if you need it all the time, the answer is more likely to be that battery is a bad idea.

Any method of location tracking has issues. You just need to decide which are the least painful to use. Here's a partial list:

GPS- high accuracy, high battery use, high startup time, doesn't work indoors, accuracy can be reduced by the government

Beacons- extremely high accuracy, requires bluetooth, only works in a specific area, requires external hardware, possible to spoof by 3rd party (setting his beacon ids to yours)

Network based- low accuracy, low resources required, possible to spoof by 3rd party if in isolated area (setting fake wifi network SSIDs)

Fused- uses a combo of gps and netork data. SO you have a mix of the problems of each.

Gabe Sechan
  • 90,003
  • 9
  • 87
  • 127
  • 1
    Thanks for the quick reply. I am aware of all these considerations but I strongly believe this has nothing to do with a problem coming from one of the technologies being used. It is simply a bug in the design/ implementation of the WIFI lookup implemented by google. Non-stationary wifi sources must be excluded from location determination and not considered being a strong indicator for a very specific location ( accuracy ~= 30 meters ) - I hate to say it but... it works perfectly fine on IOS. – saberrider May 01 '17 at 15:53
  • I don't disagree with that statement (if not excluded, at least given lower weight). But how do you know that a given wifi network is non-stationary? Its not a trivial problem. – Gabe Sechan May 01 '17 at 15:55
  • That is probably true. Still, I have reproduced the issue with a simple tethered wifi hotspot from another stock android device. Even if the issue is hard to solve for a great quantity of manufacturers, in that specific case it cannot be that big of an issue to flag a certain wifi hotspot as "ignore for location" since the control lies by google themselves. Again, this is not a niche scenario, it happens quite frequently that a device is in the range of a portable hotspot. – saberrider May 01 '17 at 16:04
0

I think it is understood that there are trade-offs between accuracy and battery consumption. But this smells more like a bug. Here is an example why I say that: my phone knew perfectly well that I was no longer in Honolulu when I reconnected to my home WiFi, because I had used it extensively over the return trip in Dallas, Boston and other places, including using Google Maps to get me to intermediate places. Yet, somehow the Google data base ended up with the bogus location Honolulu for my home WiFi so that when someone else connected to my home WiFi they started sporadically getting weather updates for Honolulu! Now if my phone had been in Airplane Mode all the way, this would make slightly more sense. But even then, the overwhelming evidence is that my home WiFi is where it is, a single phone momentarily reporting a wrong location should not be able to change that.

Berthold
  • 21
  • 1