Poor GeoLocation accuracy on both Android and iOS when using Geolocation.GetLocationAsync
- Dominant language
- C#
- Stars
- 23.3k
- Forks
- 2k
- Avg merge
- 1d 15h
- Merged PRs (30d)
- 290
Description
### Description
When sampling GeoLocations using the Geolocation.GetLocationAsync and GeolocationAccuracy.Best, the sampled locations have very poor accuracy. This happens on both Android and iOS. See screen shot for an example captured using a Samsung Galaxy A55 5G, Android 14:

The black line was captured with dedicated GPS hardware.
Compare this to a track recorded at the same time using the Geolocation.StartListeningForegroundAsync approach on an iPhone 14, iOS 18.3.2:

Interestingly using a Google Pixel 6a, using the Geolocation.GetLocationAsync approach, the captured track is very good (recorded without a GPS reference track)

I cannot use the Geolocation.StartListeningForegroundAsync approach on Android due to the issue raised regarding only receiving 2 locations when listening and then no other locations received.
### Steps to Reproduce
My app follows closely the MAUI sample code for capturing. There appears to be significant platform differences in the performance of the Geolocation.GetLocationAsync
### Link to public reproduction project repository
_No response_
### Version with bug
8.0.100 SR10
### Is this a regression from previous behavior?
Not sure, did not test other versions
### Last version that worked well
_No response_
### Affected platforms
Android, iOS
### Affected platform versions
iOS 18, Android 14
### Did you find any workaround?
The Geolocation.StartListeningForgroundAsync method work's around the issue on iOS but unfortunately not on Android.
### Relevant log output
```shell
```
Contributor guide
Research direction
Start with the Geolocation.GetLocationAsync and Geolocation.StartListeningForegroundAsync entry points and reproduce the reported behavior on Android 14 and iOS 18. Compare the sampled tracks with the reported platform differences; done means the accuracy problem is reproducible and its platform-specific cause or expected behavior is established.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- android, csharp, ios
- Domain
- mobile-dev
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100