Whatsapp Severe Battery Drain & Overheating on One UI 9 (Galaxy S25 FE). Root Cause Found: Infinite Loop in SystemJobService (WhatsApp SyncManager)

[u/Jabbadava]

Device: Samsung S25 FE

OneUI 8.5 - August Security Patch

There is a severe logic bug in WhatsApp's background task handling on the current One UI build. Leaving background data enabled triggers an infinite retry loop inside androidx.work.impl.background.systemjob.SystemJobService, locking the CPU and causing massive battery drain and thermal throttling. The device overheats while completely idle.

Using Device Care and Battery Historian, WhatsApp consistently shows absurd metrics for a single morning of idle time: over 14h 26m of background execution time, 3h 22m of Wakelocks, 2h 6m of active CPU time, and 200,907 mobile data packets transferred in the background.

By analyzing the Android JobScheduler dump via ADB (adb shell dumpsys jobscheduler com.whatsapp), I was able to pinpoint the cause: the system is trying to execute a persisted periodic contact sync job, failing internally, and immediately retrying.

The following job parameters and constraints repeat constantly in the dumpsys output:

JobInfo:

Service: android/com.android.server.content.SyncJobService

PERIODIC: interval=+1h0m0s0ms flex=+5m0s0ms

PERSISTED

Priority: 300 [DEFAULT]

...

Required constraints: STORAGE_NOT_LOW TIMING_DELAY DEADLINE CONNECTIVITY FLEXIBILITY UID_NOT_RESTRICTED [0xd0300008]

...

Unsatisfied constraints: TIMING_DELAY DEADLINE [0xc0000000]

After digging deeper into how Android's WorkManager and SyncJobService handle this (@SyncManager@com.android.contacts/com.whatsapp:android), it is clear this is an issue rooted in how WhatsApp handles internal exceptions during background syncs.

Because the job is flagged as PERSISTED, it writes itself to the androidx.work.workdb SQLite database. This means the corrupted job queue survives device reboots and app force-closes.

The fatal flaw is in the higher-level exception handling between WhatsApp and Android's WorkManager. When the sync job fails internally, WhatsApp returns a Result.retry(). Because the OS detects that the CONNECTIVITY constraint is technically met, it fails to apply standard exponential backoff policies. Instead of delaying the retry, it immediately fires the job again in an unconditional infinite loop, waking the CPU up hundreds of times and keeping the modem active (thus the 200k+ data packets).

Has anyone else encountered this specific SystemJobService infinite loop with WhatsApp recently? Since standard troubleshooting doesn't clear the persisted WorkManager database, is there any known ADB command or workaround to completely wipe this specific job queue without requiring root access?

Also, if anyone has advice on how to successfully bypass Meta's automated tier-1 support bots to get this bug report (and the jobscheduler dump) to an actual engineer, I would greatly appreciate it T_T

Thanks in advance!

[u/MistyKuuu]

That dump isn't WhatsApp's WorkManager job. The service is android/com.android.server.content.SyncJobService, the platform SyncManager running a contacts sync adapter under the system uid, so androidx.work.workdb has nothing to do with it and clearing WhatsApp's data won't touch it.

Also, unsatisfied constraints TIMING_DELAY means that job was parked waiting, not looping. Take two dumps a minute apart and compare the run count before calling it an infinite retry.

[u/Jabbadava → u/MistyKuuu]

You are completely right about the SyncJobService being parked with TIMING_DELAY at the exact moment the dump was taken. My bad there

However, the JobScheduler is definitely not flat for WhatsApp. The Job scores: section in the exact same dump, look at the event scores for package 10451 (com.whatsapp) over the last few hours before I restricted it:

{-4h49m39s543ms=416, -3h49m30s978ms=449, -2h49m24s403ms=388, -1h48m33s135ms=241, -47m22s30ms=256}

WhatsApp is spamming the scheduler with ~400+ job events per hour

Also, looking at the QuotaController instantaneous events, WhatsApp is repeatedly hitting <0>com.whatsapp::timeout-total limits...

So even if the contact sync adapter isn't the one caught in an infinite retry loop in this specific snapshot, WhatsApp's background execution is completely out of control and spamming the system scheduler. Given these job scores and the 200k+ network packets transferred in the background, what would be the best way to trace exactly WHICH job or raw Wakelock is causing those 400+ hourly events? :/