cell tower based location is delayed by 30s, valid for just 5s and again not for 30s

[starbrights]

This location (I use GSM location service) is with newer GmsCore delayed. I SatStat I have to wait for 30s until I see the rough estimated blue location. This keeps blue for 5 seconds, and becomes grey after that. Again there is 30s to wait until position is valid and blue again.

That behavior is not like that in 0.2.10.

[celle1234]

I have the same problem. Version is self build current commit. How cat i troubleshoot the problem?

[deveee]

I just tried current GmsCore package and I have very similar behavior. Well, I didn't count these 30s but the fact is that location is not available most of the time. It's with gsm location service and I tried mozilla location too. It works fine with UnifiedNlp 1.6.8 (package from fdroid).

[deveee]

And @starbrights from what I see in changelog since 0.2.11 it uses UnifiedNlp 2.0 alpha version so maybe it's the reason why 0.2.10 works fine for you.

[starbrights]

Mh, this Nlp is part of the mircoG core, so I didn't do anything with that. The question is - is there some reason that the quys creating that microG (got it via FDroid) using that older alpha or did they just forget to put the newer version into it.

[jwrdegoede]

I'm seeing similar network location timing issues on a lineage-17.1 + latest micro-G config. I've run several tests and the amount of time between updates (and the amount of time when only a "stale" location is available) seems to depend on which Nlp providers are used:

• With GSM location service the network location is ok for 5 seconds and then shown as stale in SatStats for about 55 seconds for me.
• Networklocation works with 5 seconds ok + 10 seconds stale data when downgrading mozilla NLP (IchnaeaNlpBackend) to version 1.3.3 (and using this as the sole NLP provider)
• Where as with mozilla NLP 1.5.0 I only see a proper up2date network location once every minute / couple of minutes and when starting an app inside the cooldown window it seems no data is provided instead of the last location with a flag that it is old-data, breaking many apps
• The mozilla NLP 1.5.0 issue is likely caused by: https://github.com/microg/IchnaeaNlpBackend/commit/174e736fef2e3d465da86b3054cbf983d2b9c83f . Maybe in combination with GmsCore including the UnifiedNlp v2.0-alpha# versions
• Networklocation works fine when using Apple Wifi NLP as sole provider

If you have no objection against using the Apple Wifi webAPIs (and thus sending some data to Apple) then using the Apple Wifi NLP provider from F-Droid is a good workaround for the timings issues. At least this seems to work well for me.

[jwrdegoede]

A quick update on this, I just retried this on a fresh install and for the apple backend to work properly I also need to disable the "throttle wifi scanning" option under developer options and then disable + re-enable the apple wifi backend in the microg location settings.

Without this the apple backend was behaving quite similar to the mozilla NLP (IchnaeaNlpBackend) version 1.3.3 case, where Networklocation works with 5 seconds ok + 10 seconds stale data. Unfortunately disabling "throttle wifi scanning" does not help for the 1.3.3 mozilla NLP backend.