Run Service to collect sensor data only when user is moving

Question

I wanted to track sensor data (accelerometer, gyro) when user is moving/ phone is not stationary.

Things I was able to do :

1. Listen to sensor data using Sensor Listener

        sensorManager = getSystemService(SENSOR_SERVICE) as SensorManager
        
        val accelerometerSensor = 
        sensorManager.getDefaultSensor(Sensor.TYPE_ACCELEROMETER)
    
        sensorManager.registerListener(
                accSensor,
                accelerometerSensor,
                SensorManager.SENSOR_DELAY_NORMAL
            )

2. Run a foreground service that always keeps running in the background to track the sensors even when the app is swiped off from recent apps

serviceIntent = Intent(context, SensorService::class.java)
context.startForegroundService(serviceIntent)

3. Start the service as soon as the app is rebooted using broadcast listeners which listen to Boot completed event.

But I was not able to:

1. Stop sensor service that collects sensor data when the device stops moving.
2. Start sensor (which is not running) when the user's device starts to move and collect sensor data.

What might be the way to receive the Motion start and Motion end notifications/callback from the system so that we can decide to start/end foreground services.

Answer 1

Too big for a comment, so I'll post it as an answer. And it is in some way an answer, but without proofs, just my experience.

I'm in no way an expert in the Android. But I know a thing or two about sensors in general. And the main thing is that they are always active (if not turned off entirely), and that there is always some noise. So

1. One can't say with 100% certainty is there any movement or not. Instead you need to collect all events, choose your thresholds and decide it yourself. (Probably you'd want to aggregate the measurements from several sensors to make that decision, and even to consider the history of measurements - e.g. if a user is in a car on a bumpy road the noise will be higher for a prolonged period).
2. There is virtually no difference in energy consumption if the corresponding code will be executed by the OS, or by your service. But there is a lot more opportunities to customize the thresholds, the aggregation and other logic with your code. That's why I believe that OS keeps API to the bare minimum, and there is no such events as moving starts/moving stops.
3. The only thing that drains energy above the minimum is your code. And no one else, but your code decides to annoy users with a constant stream of notifications or not.

So, think of aggregation strategy and thresholds, don't show notifications if thresholds are not passed, and make your code fast (so that it won't use too much energy). And your are done... more or less... because these decisions are not easy to make. A lot of apps from big companies fail to make them right in all the cases. Just install a couple of pedometer-apps and you'll see that they all will show different counts of steps.