Skip to content

Remove fragile vars from LocationSensorManager by persisting state to SharedPreferences#6469

Closed
Copilot wants to merge 2 commits intomainfrom
copilot/remove-vars-from-locationsensormanager
Closed

Remove fragile vars from LocationSensorManager by persisting state to SharedPreferences#6469
Copilot wants to merge 2 commits intomainfrom
copilot/remove-vars-from-locationsensormanager

Conversation

Copy link
Copy Markdown

Copilot AI commented Feb 19, 2026

Summary

LocationSensorManager is a BroadcastReceiver — Android can kill and restart the process at any time, resetting all companion object vars to their initial values. This caused real bugs: force-on/off high accuracy commands were silently lost after restart, zone entry state was cleared causing incorrect high accuracy mode decisions, and debounce timestamps were wiped causing duplicate location sends.

Changes

New persistence layer

  • Added @NamedLocationSensorStorage qualifier and a dedicated LocalStorage instance backed by location_sensor_0 SharedPreferences (via ApplicationModule)
  • locationStorage is injected via @Inject on the receiver and also manually bootstrapped via LocationSensorManagerEntryPoint for the requestSensorUpdate codepath

Removed companion object vars — now persisted

Removed var Why it mattered
forceHighAccuracyModeOn/Off Server commands lost on restart
lastEnteredGeoZones, lastExitedGeoZones Zone-based HA mode broken after restart
lastLocationSend, lastUpdateLocation, lastLocationReceived Debounce/dedup/restart-detection state
highAccuracyModeEnabled Location future-timestamp and debounce filters incorrect
geofencingClient, fusedLocationProviderClient No longer cached — obtained fresh from LocationServices on each call

Remaining companion vars (isBackgroundLocationSetup, zones, geofenceRegistered, lastHighAccuracy*) reset harmlessly — they cause a one-time re-setup or re-fetch on restart with no correctness impact.

Behavioral improvements

  • removeGeofenceUpdateRequests() is now suspend to correctly clear persisted zone state atomically
  • Restart detection in setupLocationTracking now requires at least one prior location received per server (avoids false-positive restarts from vacuous-truth on empty maps)
  • handleInject() moved to the top of requestSensorUpdate() to guarantee locationStorage is initialized before setupLocationTracking() accesses it

Checklist

  • New or updated tests have been added to cover the changes following the testing guidelines.
  • The code follows the project's code style and best_practices.
  • The changes have been thoroughly tested, and edge cases have been considered.
  • Changes are backward compatible whenever feasible. Any breaking changes are documented in the changelog for users and/or in the code for developers depending on the relevance.

Any other notes

No user-visible behavior change — this is a correctness fix for edge cases that only manifested after a process death/restart.

Warning

Firewall rules blocked me from connecting to one or more addresses (expand for details)

I tried to connect to the following addresses, but was blocked by firewall rules:

  • dl.google.com
    • Triggering command: /usr/lib/jvm/temurin-17-jdk-amd64/bin/java /usr/lib/jvm/temurin-17-jdk-amd64/bin/java --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.prefs/java.util.prefs=ALL-UNNAMED --add-exports=jdk.compiler/com.sun.tools.javac.api=ALL-UNNAMED --add-exports=jdk.compiler/com.sun.tools.javac.util=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.prefs/java.util.prefs=ALL-UNNAMED --add-opens=java.base/java.nio.charset=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.base/java.util.concurrent.atomic=ALL-UNNAMED --add-opens=java.xml/javax.xml.namespace=ALL-UNNAMED --add-opens=java.base/java.time=ALL-UNNAMED -XX:MaxMetaspaceSize=1g -Xmx4g -Dfile.encoding=UTF-8 -Duser.country -Duser.language=en (dns block)

If you need me to access, download, or install something from one of these locations, you can either:

Original prompt

Can we get ride of the vars in the LocationSensorManager because it is super fragile since all these variables are getting reset each time the process restart.


✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

…lity on process restart

Co-authored-by: TimoPtr <6560631+TimoPtr@users.noreply.github.com>
Copilot AI changed the title [WIP] Remove fragile vars from LocationSensorManager Remove fragile vars from LocationSensorManager by persisting state to SharedPreferences Feb 19, 2026
Copilot AI requested a review from TimoPtr February 19, 2026 20:26
@TimoPtr TimoPtr closed this Apr 13, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants