microg
Fused location provider blocks, despite accurate GPS location
(originally opened here)
Describe the bug
Occasionally on /e/OS the fused location will take a very long time to update, despite the device having an accurate GPS location. My understanding of the Google fused location implementation is that fused location will always prefer GPS if the GPS is active for any reason, and I it seems wrong to me that the location fusing is blocked (probably by a slow network call) if the GPS is active and has an accurate fix.
To Reproduce We have had issues reproducing this bug but I strongly suspect that it's due to latency in the network location API calls, so I would start by artificially introducing latency there to see what happens to the fused provider.
Expected behavior I would expect the fused provider to emit GPS location updates despite the lack of accurate network location.
Screenshots I'm having some issues with the attachment upload but there's a video here:
https://drive.google.com/file/d/1c-byuhu9xTzSe1CMrnIm2YsRG1_VpqsN/view?usp=sharing
In this video, the device is on a moving train as you can see from the GPS provider, but the fused provider gave a stale location from many minutes ago.
System Android Version: 13 Custom ROM: e/OS 3.0.1
Additional context
I keep seeing stale locations while using TransitApp while riding a train; this looks like the same bug.
This has been a longtime issue of mine since before UNLP was deprecated in 2023-05. (And I've brought it up here before several times)
If a network location provider has wildly inaccurate data, it often "poisons" a good GPS fix.
That should never happen. Because unless you're in a war-zone where the combatants are jamming GPS, a good GPS fix should always be considered the highest-reliability geolocation source.
But I've had multiple people I support mention this is happening again now.
Turning off all the options in the microG utility's "Location" section (except for Nominatum) always fixes the issue. (Basically reverts to GPS-only geolocation)
I've noticed this manifests less reliably in apps that use the closed-source Google Play fused location provider client. I don't know what that library does on account of it being closed-source, but apps that use it seem to discard implausible network location results somehow. For my current work we're trying to keep all components open-source so we've run into this issue quite often working directly with LocationManager. We implemented an application-level mitigation for this that involves subscribing to both the fused provider and the GPS provider and discarding fused location updates if we've received a GPS update in the last 15 seconds. We could do so, so much better if this were fixed at the OS level, but this is the mitigation I had time to implement.
we've run into this issue quite often working directly with LocationManager.
Yes, LocationManager is deprecated by Google but since microG is taking over the role of their preferred FusedLocation provider on "degoogled" devices and many apps follow Google's directive to use Fused by default, and since as you've discovered microG's implementation of FusedLocation provider has a habit of "hanging on" to stale data even in the presence of a strong GPS fix, here we are.
My usual suggestion to users as a temporary workaround is to disable all settings in the "Location" section of the microG utility except Nominatum and restart, this essentially forces the location stack to "GPS only" mode and fixes the problem every time.
Of course you lose network location in that case but in many situations that's still much better than a completely broken location provider.
Sometimes if that works for them I will further suggest trying to enable "learn from GPS" switches along with changing the selected network location provider, depending on where they are this could work too.
I think the main problem is getting either completely wild data from a network provider or just "null response", which microG cannot handle (even with good GPS fix) so then it reverts to "last known location" instead, which is often wrong, sometimes blatantly so.
LocationManager is deprecated by Google
I don't think you're wrong to say this, but Google themselves may take issue with it. They don't list it as deprecated, they just say you should never use it because they want you to use their proprietary thing. But again, what's the difference? 😆
Regarding the open PR, thank you for pointing it out! I will investigate. I don't have the faintest idea what it would take to contribute to microG (I assume we can do better than having to reflash the phone to test changes?). This issue has been a thorn in my side for about a year now trying to develop a maps app for de-googled phones, and it would be incredible to simply fix it.
I don't think you're wrong to say this, but Google themselves may take issue with it. They don't list it as deprecated, they just say you should never use it because they want you to use their proprietary thing. But again, what's the difference? 😆
In case you're not aware, Google has been progressively migrating open source APIs and functionality that used to be core parts of AOSP into their proprietary apps and frameworks like Play and GMS, and then dropping further development or maintenance of their predecessors, for close to 15 years now. It's actually one of the main reasons that Marvin started the microG project (then known as the "NoGapps project") in the first place, about 13 years ago.
So I personally hold no illusions that Google will continue to support the old APIs and frameworks any longer than they absolutely have to. Especially at a time when they are basically waging an open war against users of custom ROMs based upon AOSP.
It may be that there are enough "important" users using AOSP derivatives to keep that hammer from coming down very soon, but the evidence at this point suggests that Google is putting significant effort into actually accelerating the demise of the entire community, if they had their way. 😏
Have you tried looking at the source from eg OsmAnd~ or CoMaps to see how they're doing it? Or even SatStat, which I presume is a lot easier to spelunk through?
I don't know if CoMaps does anything differently, but if I remember correctly OM's Google Play Store version actually uses Google's fused location provider client. 😔 Just about everyone seems to give up and use it.
I don't share quite as much pessimism about LocationManager being removed, because Google has added things to it as recently as API 31, but they're very hard to predict so you never know.
Google has added things to it as recently as API 31
Very interesting, hadn't noticed that. Same year they debuted "Clown UI", my nemesis. 😁