Fix Android foreground geolocation update distance

[jfversluis]

Note

Are you waiting for the changes in this PR to be merged?
It would be very helpful if you could test the resulting artifacts from this PR and let us know in a comment if this change resolves your issue. Thank you!

Description of Change

Stops Android foreground geolocation listening from using the desired accuracy distance as the platform minimum movement threshold. MinimumTime now controls the requested update cadence without imposing a hidden 50m+ distance gate for GeolocationAccuracy.Best.

The existing accuracy value is still used by the listener to filter out locations that do not satisfy the requested accuracy.

Issues Fixed

Fixes #22683

Validation

• Built src/Essentials/src/Essentials.csproj for net10.0-android36.0.

Manual regression coverage

Automated Android device coverage for this exact regression would require controlling mock location updates from the test app/device environment, which is not reliable in the current Essentials device-test setup. Please validate the PR artifacts with the issue repro or Essentials geolocation sample:

1. Install this PR's artifacts using the dogfood instructions above.
2. Start foreground listening with new GeolocationListeningRequest(GeolocationAccuracy.Best, TimeSpan.FromSeconds(1)).
3. Keep the app in the foreground and send or perform multiple location changes that remain within 50 meters of the previous position.
4. Confirm LocationChanged continues firing for those sub-50m updates instead of stopping after the initial GPS/network callbacks.
5. Confirm updates still include high-accuracy locations; locations whose reported accuracy is worse than the requested accuracy can still be filtered by the existing listener accuracy check.

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.sh | bash -s -- 35783

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/maui/main/eng/scripts/get-maui-pr.ps1) } 35783"

[kubaflo]

/review -b feature/enhanced-reviewer

[MauiBot]

Expert Review — 1 findings

See inline comments for details.

[MauiBot]

[major] Regression Prevention — This bug fix changes Android foreground listening semantics but has no regression coverage. Please add an Android Essentials device/integration test or documented manual test coverage that proves StartListeningForegroundAsync continues raising LocationChanged when the reported position remains within the previous 50-100m accuracy-distance threshold. Without that, this can regress back to treating desired accuracy as minDistance.

[jfversluis]

Added documented manual regression coverage to the PR description.

I did not add an automated Android Essentials device test for this servicing fix because proving this exact behavior would require controlling sub-50m mock location updates from the test app/device environment, and the current Essentials device-test setup does not provide a reliable mock-location path for Helix. The documented scenario validates the old failure mode directly: start foreground listening with GeolocationAccuracy.Best and a 1-second cadence, then send or perform multiple location changes within 50m and confirm LocationChanged continues firing instead of being gated by the old accuracy-distance threshold.

[kubaflo]

/review -b feature/enhanced-reviewer

[MauiBot]

AI Review Summary

@jfversluis — new AI review results are available based on this last commit: 4304990.
Fix Android geolocation foreground update distance To request a fresh review after new comments or commits, comment /review rerun.

Review Sessions — click to expand

Gate — Test Before & After Fix

Gate Result: ⚠️ SKIPPED

No tests were detected in this PR.

Recommendation: Add tests to verify the fix using the write-tests-agent.

---

UI Tests — Essentials

Detected UI test categories: Essentials

⏭️ Deep UI tests — 0 passed, 0 failed across 1 category on platform-pool agent (replaces in-process counts above). 1 category reported 0 tests.

🧪 UI Test Execution Results (deep, platform pool)

Category	Tests	Snapshot diffs
Essentials	0 tests	—
📎 Download drop-deep-uitests artifact (TRX + snapshot diffs)

---

Pre-Flight — Context & Validation

Issue: #22683 - Geolocation.StartListeningForegroundAsync stopps calling event after 2 positions on Android
PR: #35783 - Fix Android foreground geolocation update distance
Platforms Affected: Android
Files Changed: 1 implementation, 0 test

Key Findings

• Android foreground geolocation used the desired accuracy distance from GetBestProvider as LocationManager.RequestLocationUpdates minDistance, so GeolocationAccuracy.Best could impose a hidden 50m movement threshold.
• PR #35783 changes only src/Essentials/src/Geolocation/Geolocation.android.cs, replacing the foreground-listening minDistance argument with 0 while keeping listener-side reported-accuracy filtering.
• Gate was already skipped before this phase because no tests were detected in the PR; inline discussion requested regression coverage and the author added documented manual coverage.

Code Review Summary

Verdict: LGTM
Confidence: medium
Errors: 0 | Warnings: 0 | Suggestions: 1

Key code review findings:

• 💡 Consider future regression coverage if Android Essentials device tests gain reliable mock-location support; no required code change for this PR.

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
PR	PR #35783	Pass 0 as Android foreground minDistance and keep providerInfo.Accuracy as listener-side accuracy filter	⚠️ Gate SKIPPED (no tests detected)	src/Essentials/src/Geolocation/Geolocation.android.cs	Original PR

---

Code Review — Deep Analysis

Code Review — PR #35783

Independent Assessment

What this changes: Android foreground geolocation listening now calls LocationManager.RequestLocationUpdates(..., minDistance: 0, ...) instead of reusing providerInfo.Accuracy as the requested minimum movement distance.
Inferred motivation: DesiredAccuracy should filter delivered locations by reported accuracy in ContinuousLocationListener, not impose a hidden 50m/100m/250m+ movement gate that can suppress LocationChanged events despite MinimumTime requesting a cadence.

Reconciliation with PR Narrative

Author claims: The PR fixes Android foreground listening by removing the accidental distance threshold while keeping the existing accuracy filter; it fixes #22683 and documents manual validation because automated Android mock-location regression coverage is not reliable in current Essentials device tests.
Agreement/disagreement: This matches the code and linked issue. The issue reports updates stopping until larger movement occurs; the old code passed the same accuracy-distance value to Android's minDistance, so the fix addresses the inferred root cause. A prior inline review asked for regression coverage; the author added manual validation notes, and I am not duplicating that comment.

Findings

No ❌ Error findings.

No ⚠️ Warning findings.

💡 Suggestion — Consider future regression coverage if mock-location support improves

The lack of automated coverage is understandable for this servicing-sized Android platform fix, but this behavior would be worth covering if Essentials device tests later gain reliable mock location injection. No action required for this PR.

Devil's Advocate

The main risk is increased callback volume/battery use because Android no longer has a movement-distance gate. However, MinimumTime still controls cadence and this API's shared contract describes minimum time between updates plus an accuracy filter, not a movement threshold. The listener still filters location.Accuracy <= desiredAccuracy, so low-quality locations are not surfaced. CI is still pending, so this is a code-review verdict rather than a merge-readiness approval.

Verdict: LGTM

Confidence: medium
Summary: The one-line Android change is consistent with the API contract and the linked bug's symptoms, and I found no correctness issues in the changed line or its immediate consumers. CI has no failures in the data available, but several checks are still pending/in progress, so final merge should wait for completion.

---

Fix — Analysis & Comparison

Fix Candidates

#	Source	Approach	Test Result	Files Changed	Notes
1	try-fix	Separate desired accuracy from listening movement threshold with DesiredAccuracy tuple naming and GetMinimumListeningDistance()	✅ Build passed; regression test unavailable	1 file	Clearer semantics, but behaviorally equivalent to PR and not better
2	try-fix	Use API 31+ LocationRequest.Builder with explicit SetMinUpdateDistanceMeters(0) and executor, legacy fallback	✅ Build passed after compile iterations; regression test unavailable	1 file	Meaningfully different, but larger/riskier servicing change
3	try-fix	Add Android partial GeolocationListeningRequest.PlatformMinimumDistance => 0 and use it at call site	✅ Build passed; regression test unavailable	2 files	Self-documenting, but extra abstraction for constant
PR	PR #35783	Pass literal 0 for foreground Android minDistance; keep desired accuracy as listener filter	⚠️ Gate SKIPPED (no tests detected)	1 file	Smallest correct fix

Cross-Pollination

Model	Round	New Ideas?	Details
maui-expert-reviewer	1	Yes	Proposed modern LocationRequest, semantic refactor, request helper/partial, and adaptive threshold ideas.
maui-expert-reviewer	2	Yes	Proposed request-level Android partial as a distinct candidate after attempts 1-2.
maui-expert-reviewer	3	No	Rejected remaining variants: adaptive threshold preserves the bug; named constants/helpers are equivalent; AndroidX/public API options are inappropriate for servicing.

Exhausted: Yes
Selected Fix: PR's fix — It is the smallest behaviorally correct change. Candidate 2 is the only materially different compiled alternative, but it adds API-level branching/executor behavior without proving better regression coverage or correctness. Candidates 1 and 3 improve naming/readability but are not demonstrably better than the PR.

---

Report — Final Recommendation

Comparative Fix Report — PR #35783

Candidate ranking

Rank	Candidate	Result	Assessment
1	pr	⚠️ Gate skipped; no tests detected	Smallest correct fix. Removes the accidental Android movement threshold while preserving listener-side reported-accuracy filtering.
2	pr-plus-reviewer	⚠️ Gate skipped; no tests detected	Expert reviewer found no actionable code changes, so this is equivalent to pr; ranked below pr only because it adds no distinct improvement.
3	try-fix-1	✅ Build passed; regression unavailable	Behaviorally equivalent to the PR with clearer tuple/helper naming, but it changes more lines without improving correctness.
4	try-fix-3	✅ Build passed; regression unavailable	Encodes the zero threshold as an Android partial GeolocationListeningRequest.PlatformMinimumDistance, but adds an extra abstraction/file for a constant.
5	try-fix-2	✅ Build passed after compile iterations; regression unavailable	Uses modern API 31+ LocationRequest.Builder plus executor fallback. It is materially different but riskier for a servicing fix because it adds API-level branching and dispatch behavior for the same functional outcome.

No candidate had a failed regression test. The original gate was skipped because the PR contains no automated tests, and all try-fix candidates reported builds passing after their final iteration. Per the ranking rule, there were no regression-failing candidates that needed to be forced below passing candidates.

Analysis

The raw PR fix directly addresses the root cause: Android foreground listening accidentally used the desired accuracy distance as minDistance, causing LocationChanged to stop for sub-threshold movement. Passing 0 lets Android deliver updates according to MinimumTime, while ContinuousLocationListener continues filtering by reported location accuracy.

pr-plus-reviewer does not differ from pr because the expert reviewer wrote an empty inline findings array and recommended no source changes. try-fix-1 and try-fix-3 improve semantic labeling but do not provide a correctness advantage over the one-line PR. try-fix-2 modernizes newer Android request creation, but that additional complexity is not justified for this bug because the legacy overload with minDistance: 0 already expresses the intended behavior across supported Android versions.

Winner

Winner: pr

The submitted PR is the best candidate because it is the minimal behaviorally correct fix, preserves existing accuracy filtering, avoids new public API or abstraction, and avoids API-level branching risk. The only remaining gap is automated regression coverage; the PR currently relies on documented manual validation because reliable Android mock-location regression coverage was not available.

---

Future Action — review latest findings

No alternative fix was selected for this run. Review the session findings and CI results before merging.