"Delay before next action" timing inaccurate when screen off

[atom-smasher]

Have you checked if an issue already exists for this bug?

• Nobody else has reported this bug before

Have you tried restarting your device?

• I have tried restarting my device and that did not help

What happened that you did not expect?

To demonstrate, I have a simple keymap triggered by Volume-down that performs this action sequence:

1. Wait 2 seconds
2. Enable flashlight
3. Wait 0.5 seconds
4. Disable flashlight

When the screen is ON, this behaves correctly (≈2.0 s delay, flashlight on for ≈0.5 s, then off).

When the screen is OFF, the timing becomes unreliable:

• The initial "wait 2000ms" can take much longer than 2 seconds, sometimes indefinitely until the screen is turned on.
• The "wait 500ms" after enabling the flashlight is also unreliable; sometimes the flashlight stays on far longer than 0.5s, again, sometimes until the screen is turned on.
• In the worst case (screen off), the flashlight can remain stuck ON until the screen is turned on.

What did you expect to happen?

The action sequence should run with roughly consistent timing regardless of screen state:

• After pressing Volume-down (screen off), it should wait ≈2s, enable flashlight, wait ≈0.5s, then disable flashlight.
• The "delay before next action" should not require the screen to be on to progress, and should not leave the flashlight enabled longer than requested.

What would the developer need to do to reproduce the bug?

Minimal reproduction steps

1. Import the attached keymap group (exported JSON, here) or recreate it manually:

• Trigger ("Expert mode", so it works with screen off): Volume-down
• Actions (in order):
  -- "Do nothing", with "Delay before next action" = 2000 ms
  -- Enable flashlight, with "Delay before next action" = 500 ms
  -- Disable flashlight

2. Confirm baseline behavior with screen ON:

• Press Volume-down.
• Observe: flashlight turns on after ≈2 seconds, off ≈0.5 seconds later.

3. Reproduce with screen OFF:

• Turn screen off (power button).
• Press Volume-down once.
• Observe:
  -- The "2 seconds" delay is often >2 seconds and can appear to stall until the screen is turned on
  -- The "0.5 seconds" delay may also stall, leaving flashlight on.

n.b. my real-world use-case requires a delay of 605000ms (10 minutes, 5 seconds) and gets triggered by a remote BT device while the screen is off. After waiting 10+ minutes with the screen off for the next action to trigger, I often have to turn the screen on and wait another 5+ minutes for the next action to actually trigger.

App version

4.0.5-foss (247)

Android version

Android 10

Device model and manufacturer

Motorola Moto G8 Power

Extra info

• My device is rooted

[jambl3r]

Can reproduce on Pixel 8a

[jambl3r]

This also seems to happen when replacing the initial "Do nothing" with "Disable flashlight", although possibly a slight improvement

[sds100]

This might be a bigger issue in general, most operating systems pause or slow down a lot of processes when they are asleep. Some Android skins do this more aggressively than others. I guess we may have to add an option if this fix is critical for users then they will have to turn on a "wakelock", and then sacrifice battery life significantly. Your screen will still turn off but the components inside your phone won't go to "sleep", which is how phones even last one day off a full charge.

I'll have to look a bit hard if there is a solution that doesn't completely keep the phone awake but I'm not sure. Is there a minimum delay where it starts acting up? What if you do 500ms? There is probably a period of time after the input event where the phone is awake.

[atom-smasher]

Not my area of expertise, but as I understand it there are a few broad approaches here (in-process timers, holding a wakelock, scheduling via system wakeups/alarms), each with different battery/accuracy tradeoffs.

Suggestion (UX/function):

Add selectable delay "modes" with explicit semantics.

My symptoms with screen off look like the current delay is “best effort” and can run late or stall under idle/Doze. It might help to offer delay modes similar to other automation apps:

1. Battery-friendly (best effort): may run late while screen is off, device is idle.
2. Punctual: aim to honor wall-clock timing even when screen is off (with whatever battery/OS tradeoffs are needed on modern Android).
3. Balanced (optional): try to be more punctual than best effort without forcing the most battery-expensive approach in all cases (e.g. use a scheduled wakeup where appropriate, rather than keeping the CPU awake continuously).

Even if the underlying implementation differs by Android version, having the semantics user-selectable would let people choose the right tradeoff per delay.

e.g. in my example with the flashlight, it might make sense for some users to have the first delay "best-effort" (if the timing is not critical), and the second delay "punctual", because battery drain from the flashlight would exceed battery drain from keeping a 0.5s timer ticking.

For my use-case with a 10 minute delay, I'b be happy with a "balanced" timer that just doesn't fall more than a minute behind.

Default can remain Battery-friendly to avoid surprising battery impact, and older keymapper "groups" would work the same unless they're explicitly changed.

[jambl3r]

We see 2 potential fixes:

1. When the initial trigger press occurs, set a wakelock until the actions are all finished.
2. When the initial trigger press occurs, set some kind of alarm for the delay duration which will later wake the process. When awoken, set a wakelock until the actions are all finished.

The 2nd is slightly better in your case for battery usage, but we need to see if that is realistic. Otherwise we will do option 1 in an update

[atom-smasher]

If the multiple actions are each separated by wait-times longer than about a second, then the wakelock should be until the next action finishes - not until all actions finish - then set a new alarm for the next wait period.

e.g.

• (Action 1) Do something, wait 10 minutes.
• (Action 2) Do something, wait 10 minutes.
• (Action 3) Do something, wait 10 minutes.
• (Action 4) Do something. Done.

Rather than a wakelock holding that for 30 minutes, each of the 10 minute waits should set an alarm for the next action. Each action can hold a wakelock until the next wait (if that wait is longer than about a second).

For shorter wait times (≦ 1 second? 5 seconds? 10 seconds?) or where timing is critical, then it makes more sense to just wakelock until (a) all actions are complete, or (b) a longer wait is started. For longer wait times (e.g. minutes) then timing may be less critical, and battery life more important.

Longer wait times lend themselves to alarms, shorter wait times lend themselves to wakelocks.

And also, more critical timing lends itself to wakelocks, less critical timing lends itself to alarms.

Ideally alarm/wakelock that can be user selectable per each wait time.

And for wait times that are best-effort, get it done eventually, the current behaviour is fine, and should remain an option.

I'm seeing three ways to implement the wait, and each one serves different use-cases. There's no One Right Way™.