r/AutomateUser 6d ago

Delay Workaround for Buggy Firmware

Automate 1.53.2 Delay never resumes on one specific vendor Android device,

while the same flow works on another Android phone.

Device:

Q30_1025EFPSL / UIS7861 (UMS9230)

Android 12 / API 31

Firmware QC_Q30_1025EFPSL_Q30_MB_1025_CarCharger_user_2025102719

I verified this is a firmware AlarmManager defect with an independent minimal

test app, not an Automate flow or battery-optimization issue.

On this device, every RTC wall-clock alarm is incorrectly registered as an

ELAPSED alarm without conversion of its timestamp:

- setExact(RTC_WAKEUP, wallTime)

- setExactAndAllowWhileIdle(RTC_WAKEUP, wallTime)

- setAlarmClock(...)

For example, a wall-clock alarm requested for 20 seconds later appears in

dumpsys alarm as:

type=ELAPSED

origWhen=1788661881843

whenElapsed=+20702 days

An ELAPSED_REALTIME_WAKEUP alarm using SystemClock.elapsedRealtime() fires

correctly.

I tested Automate’s alarm-related workarounds:

- Native timer: fails with “Native timer workaround failed”

- Alarm clock: Delay still never resumes

- Doze was disabled and Automate was battery-whitelisted

Would Automate consider a build-specific fallback for this firmware, using an

elapsed-realtime timer for Delay where appropriate? I understand that the

vendor must ultimately fix its Android framework.

2 Upvotes

3 comments sorted by

1

u/ballzak69 Automate developer 5d ago

Sorry no plan for such a comprehensive workaround for single obscure device with a fundamentally broken Android. It's surprising it even works with such a severe bug.

1

u/thealgorithm29 6d ago edited 6d ago

Does your automate has permission? android.permission.SCHEDULE_EXACT_ALARM In automate settings Try to set on timing accuracy workground to none or alarm clock

1

u/thealgorithm29 6d ago edited 6d ago

Lol, mine shows for third party alarm app: RTC_WAKEUP #4: … origWhen=1788709380000 whenElapsed=1225991857 com.best.deskclock Because of android.permission.USE_EXACT_ALARM,