getCurrentPosition seems to return cached location in android

[lclrobert2020]

🐛 Bug Report

I am running the example in the flutter-geolocator/geolocator/ and installed to my android the getCurrentPosition() method seems to return cached location when called in quick successions , but after some time, it will return a new gps coordination, while getPositionStream() returns live location

Expected behavior

return the live gps when calling getCurrentPosition()

Reproduction steps

When walking, I open the example app, I manually tapped the getCurrentPosition() floating Botton (the open with gps logo) at a frequency of 5s, it keeps returning the last location, until at some point, it will return a new position. But if I tap the getPositionStream() button and then tap it again to pause it, the getCurrentPosition() floating Botton will always return live gps coordination. Is there a way to ensure the getCurrentPosition() always request new and live gps position instead of a cached one ? I have seen some report on the board but they are reporting cached issue on IOS. The android emulator seems to have the same issue

Configuration

Version: 1.x same as the example Platform:

• [ ] :iphone: iOS
• [x ] :robot: Android SAMSUNG a71 ONE UI 3.1 Android 11

[mtc-jed]

This is a known behaviour on (Android as in, this is something done by Android itself) but it can be reset. This is what is needed here and I would love ot see it implemented. I also think it should be done under the hood for every call since getLastKnownPosition() exists.

[lclrobert2020]

any update on this?

[mtc-jed]

Any updates ? Has this even been seen ?

[florissmit1]

Thanks for reporting your issue @lclrobert2020. I've looked into this issue, and as @mtc-jed said, it's an expected behaviour on Android devices to cache location updates. Thus getCurrentPosition will sometimes return a cached location when the FusedLocationProviderClient didn't receive a location update.

I'm not sure how this can be solved and will elaborate on this issue after the first of January.

[mtc-jed]

Forgot to put this here, but using forceAndroidLocationManager: true gets me new data every time (it does the calculation for a new position). I believe this is because AndroidLocationManager doesn't have the same caching behaviour as FusedLocationProviderClient does. It at least works for my purposes.

[lclrobert2020]

Thanks for reporting your issue @lclrobert2020. I've looked into this issue, and as @mtc-jed said, it's an expected behaviour on Android devices to cache location updates. Thus getCurrentPosition will sometimes return a cached location when the FusedLocationProviderClient didn't receive a location update.

I'm not sure how this can be solved and will elaborate on this issue after the first of January.

I am also looking at the code, i think the new getCurrentLocation method may be helpful https://developers.google.com/android/reference/com/google/android/gms/location/FusedLocationProviderClient#getCurrentLocation(int,%20com.google.android.gms.tasks.CancellationToken) I will look into the source code later hopefully I can help

[Kavinkumarsimple]

🐛 Bug Report

I am running the example in the flutter-geolocator/geolocator/ and installed to my android the getCurrentPosition() method seems to return cached location when called in quick successions , but after some time, it will return a new gps coordination, while getPositionStream() returns live location

Expected behavior

return the live gps when calling getCurrentPosition()

Reproduction steps

When walking, I open the example app, I manually tapped the getCurrentPosition() floating Botton (the open with gps logo) at a frequency of 5s, it keeps returning the last location, until at some point, it will return a new position. But if I tap the getPositionStream() button and then tap it again to pause it, the getCurrentPosition() floating Botton will always return live gps coordination. Is there a way to ensure the getCurrentPosition() always request new and live gps position instead of a cached one ? I have seen some report on the board but they are reporting cached issue on IOS. The android emulator seems to have the same issue

Configuration

Version: 1.x same as the example Platform:

• [ ] 📱 iOS
• [x ] 🤖 Android SAMSUNG a71 ONE UI 3.1 Android 11

I have a fix for this issue. When you use the getCurrentPosition method, there is a parameter called forceAndroidLocationManager, which you will have to set as true. After that, every time you click the button it will get you the latest position and not the cached one.

This solution works better than the getPositionStream method, as it will not listen for location changes rather the location sensors would only trigger upon using the getCurrentPosition method.

NOTE: This solution will only works for android.

Here is the complete code.

Position position = await Geolocator.getCurrentPosition( forceAndroidLocationManager: true, desiredAccuracy: LocationAccuracy.high);

[florissmit1]

We're currently working a fix, see: #943.

[mtc-jed]

@florissmit1 Very nice. If possible without too much trouble, expose the intervalDuration argument in the getCurrentPosition function, as this could be a useful tool to work around potential problems/restrictions/whatever in the future. Thanks for figuring this stuff out !

[florissmit1]

@mtc-jed intervalDuration shouldn't be exposed in the getCurrentPosition method, since Apple does not support such a thing. But we're always open to suggestions. The PR will be released today and will be available in a new version of geolocator. I will let you know when the release is available.

[mtc-jed]

@florissmit1 Having more parameters is always a good thing in my book, as long as they are properly documented. In this instance, naming it androidIntervalDuration would probably be clear enough (in addition the Dart /// documentation), as it is about the same thing as forceAndroidLocationManager (tho I suppose this will get deprecated one day). No need to tag me for the release since I won't be doing Flutter stuff before the end of the month, but do tag the other people in this issue.

[TimHoogstrate]

I'll close this issue because it seems that the fix is merged. Feel free to reopen the issue when needed.