[Rasbandit]

Summary

Adds context profiles: the locator settings change automatically depending on what the device is connected to or doing. The main use is saving battery while still reporting accurately. Today people do this with Tasker sending CHANGE_MONITORING intents; this makes it native.

Examples it handles:

• At home (home Wi-Fi): stop location updates entirely and report a static location every 30 minutes.
• Driving (car Bluetooth): Move mode, high accuracy, short interval.
• On any other Wi-Fi: Significant mode, balanced priority.
• Out and about (none of the above): Significant mode with a smaller displacement.

It's off by default. While it's off, nothing about the device is watched and behaviour is unchanged.

What's in it

• Conditions: a Wi-Fi network (SSID), any Wi-Fi, a Bluetooth device, charging (or charging from cable, wireless or dock), or being inside a waypoint's region. A profile applies when any, all or none of its conditions match.
• Profiles are kept in priority order, and the first that applies wins.
• Overrides: monitoring mode, locatorInterval, moveModeLocatorInterval, locatorDisplacement, locatorPriority, ping, and an optional static location that's reported instead of tracking.
• Manual changes win. Picking a monitoring mode (map, notification, CHANGE_MONITORING intent), or changing a preference the applied profile overrides, suspends that profile until a different one applies. This survives restarts.
• The ongoing notification shows the applied profile, e.g. "Move monitoring mode · Driving".
• Settings UI:
  • A Context profiles screen showing the active profile live, with an ordered list and up/down arrows.
  • A profile editor that only shows the overrides relevant to the chosen mode.
  • Nearby Wi-Fi and paired Bluetooth pickers.
  • A map location picker for the static location, using the same kind of map the user has chosen for the main map (Google Maps or OpenStreetMap).

Design

• The core is ContextProfileManager. It matches profiles against a DeviceContext (Wi-Fi, Bluetooth, charging, entered regions) and publishes the resulting LocatorSettings. The location request, ping schedule, publish suppression, significant-motion rate limit and displayed monitoring mode read those settings instead of the raw preferences.
• Device context sources are cold flows. Their listeners are only registered while profiles are enabled.
• Nothing is matched, requested or pinged until every source has reported once (with a 3s fallback), so the empty context at startup can't briefly apply a profile.
• While a static location is in use, real locations are only published when the user explicitly asks (USER). Other on-demand requests (e.g. remote reportLocation) get the static location, and it's not used for region transition detection.
• Region conditions reference waypoints by tst, like exported waypoints do, so they survive waypoint re-imports.

Open questions for maintainers

1. Storage format. Profiles are stored as a JSON string in the exportable contextProfiles preference, because PreferencesStore only handles primitives. That means escaped JSON in .otrc exports. Would you prefer a typed preference with a serializer, or something else? I'm happy to rework it.
2. Permissions.
   • BLUETOOTH (maxSdk 30) and BLUETOOTH_CONNECT are added for Bluetooth conditions. The runtime permission is only requested when a Bluetooth condition is added.
   • CHANGE_WIFI_STATE is only for requesting a fresh scan in the Wi-Fi picker. Without it the picker falls back to cached scan results, which are often empty. It can be dropped if you'd rather.
3. oss limitation. Without OS geofencing, region transitions come from location fixes, so a profile that combines a region condition with a static location can't detect leaving the region. This is documented rather than solved.
4. Splitting. The commits are laid out to be reviewable one at a time: prep refactors, then the engine, then the UI, the picker following the user's map choice, then fixes from a further review and tests. I can split this into separate PRs if that's easier.

Testing

• 120 new JVM unit tests, covering:
  • matching, settings resolution, suspension and settling, readiness, ping scheduling
  • static-location publishing and gating, entered regions, Wi-Fi tracking, decoding
  • the new preferences, added to PreferencesGettersAndSetters, PreferenceTest, ImportExportTest and LoadViewModelTest as with other preferences
• 12 new instrumented tests:
  • ContextProfilesPreferencesTests: add, configure, delete and reorder profiles, and show the active one
  • ContextProfileTests: static location published instead of real fixes, the profile's mode on the map and in the notification, CHANGE_MONITORING suspending a profile
  • LocationPickerActivityTests: the picker's results
  • They use a new FakeDeviceContextProvider swapped in through @TestInstallIn, the same way as TestGeofencingCapabilityModule, because an emulator's Wi-Fi, Bluetooth and charging state can't be set.
• The same checks as CI, run locally:
  • ktfmtCheck
  • assembleDebug assembleAndroidTest assembleRelease
  • createGmsDebugUnitTestCoverageReport, all passing
  • lint: nothing new from this branch apart from the untranslated new strings
• Instrumented tests run locally: only ContextProfilesPreferencesTests (passing on an API 36 emulator). ContextProfileTests and LocationPickerActivityTests haven't been run locally (the only emulator available was busy with another project), so CI will be their first run.
• Manually tested on an emulator (both flavours) and on a Pixel 8 Pro running Android 17, reporting over HTTP to a self-hosted Dawarich:
  • Wi-Fi, Bluetooth and charging switching
  • the static location being reported once on arrival and then every ping, with no real fixes leaking
  • manual override
  • startup with no profile flicker
  • rotation in the location picker

AI assistance

This was written with Claude Code, with me directing the design, reviewing it and testing on my own device. The commits carry a Co-Authored-By trailer.

🤖 Generated with Claude Code