Open jkaufman opened 1 year ago
Hey, that's correct. I indeed wanted to keep the android.location backend default for 3.X release, to get the feedback from the community and resolve issues. I will change this behaviour in upcoming versions when it becomes stable enough.
That is super interesting @jkaufman ! Thanks for sharing this.
This part of the docs does not seem to reflect this behavior:
locationProvider (string, Android-only) - Either "playServices", "android", or "auto". Determines wether to use Google’s Location Services API or Android’s Location API. The "auto" mode defaults to android, and falls back to Android's Location API if play services aren't available.
Many developers might be mislead and thinking they use the new play API but they are not, which leads to many issues about poor accuracy
@christophemenager i think the wording of the docs is weird/wrong. what it says now:
'auto' defaults to android, but will fall back to Android (if play services aren't available)
HUH?? that is VERY confusing. i'd like to see that cleared up.
other than that. it's been a year. is it maybe time to have 'auto' default to Play services?
Reviewing the code, it appears that the default location provider configuration setting,
auto
, always yields the Android location provider.mLocationManager
is set toAndroidLocationManager
.onConfigurationChange
checks for the valuesandroid
andplayServices
, butauto
is a no-op. As a consequence, the location manager remainsandroid
by default.On line 54:
else if (Objects.equals(config.locationProvider, "playServices") && mLocationManager instanceof AndroidLocationManager)
… should probably read …
else if ((Objects.equals(config.locationProvider, "playServices") || Objects.equals(config.locationProvider, "auto")) && mLocationManager instanceof AndroidLocationManager)