feat: add significat motion sensor support

[jmencak]

Request GPS position when significant motion is detected using the Android wake-up TYPE_SIGNIFICANT_MOTION sensor.

The new experimental feature requestLocationOnSignificantMotion is disabled by default and must be enabled via experimental preferences. When enabled, the app registers a trigger listener for the TYPE_SIGNIFICANT_MOTION wake-up sensor. When the sensor detects significant motion (such as the user starting to walk, moving in a car, etc.), it triggers a high-accuracy GPS location request. The location is reported with trigger type "m" (for "motion"). After each trigger, the listener re-registers itself to wait for the next significant motion event. This is particularly useful for location tracking during Doze mode, as the significant motion sensor can wake the device to get a fresh GPS fix when the user starts moving.

Changes:

• New experimental feature flag requestLocationOnSignificantMotion.
• New report type SIGNIFICANT_MOTION("m"), triggered by significant
  motion wake-up sensor. This allows the location trigger to be
  identified as coming from significant motion detection.
• SignificantMotionSensor class handling TYPE_SIGNIFICANT_MOTION.

Resolves: 1898#issuecomment-3461721344

Important / Full transparency

• I'm not familiar with the Kotlin programming language and this code (apart from minor changes) was completely AI-generated based on this repository code and my owntracks android client. I'm not sure what the policy on AI-generated code this project has.
• I believe I have reasonable understanding what all the changes in this AI-generated PR do and they do fix my issue with the current owntracks android client.
• I'm fully aware that this code might fix the effect of another bug and not the real cause of the issue. I hope that requesting some help from the maintainers to see if this is the case will not offend anyone.
• I do apologise in advance if AI-generated code is not welcome here.

[growse]

Interesting idea.

Re: waitForAccurateLocation, there was a very specific reason why this was set away from "false" in the past, and that's because people had experiences where the first location they received after some device sleep time was waaaaaay off where they were (and sometimes, but not always low accuracy). This led to, essentially, "bad" location data being transmitted.

I think there's a case for allowing the user the choice. Could you update this to stick that option behind a preference called something like "waitForAccurateLocation" (to borrow the API name). That should allow the user to choose whether they prefer more, less accurate locations, or fewer more accurate locations.

[jmencak]

I think there's a case for allowing the user the choice. Could you update this to stick that option behind a preference called something like "waitForAccurateLocation" (to borrow the API name). That should allow the user to choose whether they prefer more, less accurate locations, or fewer more accurate locations.

Thank you for looking into this and the context! Makes sense. I believe my PR was a little premature and the code still needs more testing. I also tried with the original waitForAccurateLocation = null (i.e. true by default) yesterday and had the first failure (GPS update came too late). Also, the 10/10 "just fine" tests (with waitForAccurateLocation = false) I was actually doing were using a different form of transport (I wasn't going by car where the failures were occuring). Let me update this based on my experiments/testing in a few weeks.

[growse]

More testing is useful, thanks for doing.

I may seem overly keen to "put everything behind a preference", but this project's main lesson is that all Android devices across different manufacturers behave very differently to each other. The exact same app with the same configuration can produce a lovely route track on my Pixel, but a horrible mess on someone else's Samsung (glares at Samsung). Tuning this stuff to give a decent result on a specific device is more of an art than anything, so providing the tunables is pretty important imo.

[jmencak]

Bad news. After some weeks of testing using car as a means of transport, I concluded that waitForAccurateLocation=false doesn't help (it actually makes matters worse when not moving at all) and ACTION_DEVICE_LIGHT_IDLE_MODE_CHANGED and ACTION_DEVICE_IDLE_MODE_CHANGED somewhat help, but are not a bullet-proof solution to the issue I'm seeing. So, back to the drawing board.

Good news. I've abandoned this approach in favour of trying to wake the device up and request a fresh GPS fix on Sensor.TYPE_SIGNIFICANT_MOTION. I'll continue testing this thoroughly before adjusting the code here, but initial testing shows the problem of waking up from DOZE in time after entering an area of bad GPS coverage can be resolved by acting on Sensor.TYPE_SIGNIFICANT_MOTION.

[jmencak]

I've had good success with the latest patch so far. Unfortunately, I couldn't test as much as I wanted (I tested the critical journey by car only 4 times with 100% success). I'll start testing again in January 2026. Publishing the patch for those who also wish to play with this.

I believe this can even reduce the Move mode battery usage when bumping ping to something like 60. But I understand everyone uses the client differently -- I have Move mode constantly turned on even when at home/sleeping.