PSA: I am posting this root cause analysis to document a severe logic flaw in WhatsApp's handling of Android's WorkManager and SystemJobService background tasks. While I am open to advanced ADB workarounds, I am primarily sharing these JobScheduler dumps and battery metrics for community awareness and developer visibility, as standard tier-1 tech support (clearing cache, reinstalling) cannot fix this persisted loop.

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).

Don’t get me wrong. I’ve always known developers generally don’t give a fuck when it comes to porting for android. They’ll do the bare minimum and have the app look like it was made in 2005 while on IOS they’ll go out of their way to use apples own design language.

But what was an awake up call for me is seeing hit tweets with 100 thousand likes of tweets like “if you want your app to look nice on this phone, you’re gonna have to adapt to all these layouts” as if these layouts haven’t existed for the past 6 years. It’s so weird to see on the outside but I feel like if you’re an app developer, you would have already considered those layouts but they really just don’t care. Google and Samsung have to resort to having the phone do the work for them and hope it doesn’t look like crap.

Anyways the very least, we should just have better support now that they give a shit I guess so we just reap those rewards.

A petition for software freedom, bootloader access, transparency after end-of-support, and a healthier technology ecosystem

To smartphone manufacturers, operating-system providers, and relevant consumer-rights authorities:

We believe that purchasing a smartphone should provide meaningful ownership and control over the device—not merely permission to use software within restrictions determined by its manufacturer.

Many smartphones eventually reach their official end-of-support date. At that point, manufacturers may stop providing updates while continuing to restrict bootloader unlocking, alternative operating systems, and other forms of software modification.

This creates a problem: users may own the hardware, yet remain unable to decide what software runs on it or how the device can be maintained.

We are calling for a fairer approach to device ownership—one that benefits not only users, but also developers, manufacturers, and the technology industry as a whole.

Our demands

1. Bootloader unlocking after end-of-support

Manufacturers should provide a free, documented, and reasonably accessible bootloader-unlocking method for devices that have reached the end of official software support.

Users should receive clear warnings about the risks, including reduced security, potential data loss, and loss of official support.

1. Freedom to install alternative operating systems

Manufacturers should not unnecessarily prevent users from installing alternative operating systems on hardware they own.

Where technical or security limitations exist, those limitations should be clearly explained rather than hidden behind arbitrary restrictions.

Users should be able to choose software that better suits their needs, whether that means improved privacy, longer device life, better performance, accessibility, or a different user experience.

1. Transparency about background software

Manufacturers and operating-system providers should clearly disclose:

- What system services run in the background.

- What data is collected.

- Why that data is collected.

- Where the data is sent.

- How long it is retained.

- Which services can be disabled.

- Which services are essential for device operation.

Users should not have to reverse-engineer their own phones to understand basic software behavior.

1. Meaningful privacy controls

Users should have meaningful options to disable non-essential telemetry and data collection, without unnecessary loss of basic device functionality.

Privacy settings should be understandable, accessible, and not designed to discourage informed choices.

1. Continued software freedom after support ends

Ending official support should not automatically mean ending the owner's ability to maintain, modify, or repurpose their device.

Manufacturers should distinguish between ending responsibility for official support and retaining unnecessary control over user-owned hardware.

Why this is also good for developers and manufacturers

Software freedom is not only about giving users more choices. It can also encourage companies to build better products.

When users are not permanently locked into a manufacturer's software, manufacturers have a stronger incentive to compete through quality, reliability, performance, privacy, security, and user experience rather than relying on restrictions to retain users.

This creates a healthier relationship between companies and their customers:

- Developers can focus on making better software instead of relying on artificial restrictions to keep users from leaving.

- Manufacturers are encouraged to improve quality, because users have more freedom to choose alternatives when a product no longer meets their needs.

- Competition becomes more meaningful, as companies must earn user loyalty through the quality of their products and services.

- Independent developers can contribute, creating alternative operating systems, security improvements, accessibility solutions, and new ways to extend device life.

- Users can provide meaningful market feedback by choosing better alternatives rather than being forced to tolerate software they dislike.

- Devices can remain useful for longer, reducing unnecessary electronic waste and making hardware ownership more sustainable.

This does not mean manufacturers should be required to support every alternative operating system or provide unlimited technical assistance. It means they should not unnecessarily prevent users from making their own choices after purchasing the hardware.

If a manufacturer's software is genuinely good, users should have a reason to stay because they want to, not because they are technically prevented from leaving.

Why this matters

Smartphones contain personal communications, photographs, financial information, accounts, and other sensitive data. Users deserve to understand and control the software environment that handles that information.

We recognize that unrestricted modification can create security and support risks. However, those risks can be addressed through warnings, opt-in unlocking procedures, clear documentation, and user responsibility.

Software freedom can also encourage innovation. Independent developers and communities should be able to experiment with ways to improve, maintain, and extend the useful life of devices without unnecessary interference.

End-of-support should not mean end-of-ownership.

We ask manufacturers and policymakers to support a future in which people can repair, maintain, modify, and understand the devices they purchase.

A device should remain the user's device—even after the manufacturer moves on.

Let companies compete by making better software. Let users choose what deserves to stay on their devices.

https://c.org/cXZTxQxMkj (sign it for a change)

I recently upgraded from a Pixel 8 to a Pixel 11 and have been generally happy with the transition. But one glaring issue that I've noticed after the switch is how poorly Google Maps performs on Android Auto.

I have tried it in both of my cars, both wired and wireless, and haven't noticed any difference between the two. Either way, Google Maps absolutely chugs and is constantly stuttering and hitching and appears to be running at a very low frame rate compared to what I was getting on my Pixel 8.

Now I can't say with certainty that this isn't an issue specific to the Pixel 11 and its underpowered GPU that potentially also came with unoptimized drivers. However, I have seen some other posts around in the last month or so talking about similarly poor performance on other devices after recent Google Maps updates. So now I'm just sending my feelers out here on Reddit to see how widespread the issue is and try to isolate the cause. I no longer have my Pixel 8 anymore to test and isolate whether or not my Pixel 11 is the actual culprit here.

Everything else in Android Auto seems normal and performant with no stuttering or lag when switching between apps or interacting with anything other than Google Maps itself. It seems like Google Maps is just straight up running at a really low frame rate and dropping frames.

There is an interesting discussion regarding Japanese carrier-locked devices (specifically Sharp Aquos R9, SoftBank variant A401SH) and their update mechanisms when used globally.

It seems these devices often stop receiving OTA updates outside Japan, even when using VPNs or manual checks, sticking to base OS releases like Android 15 with earlier security patches.

Does SoftBank restrict OTA updates exclusively to devices connected directly to their cellular network in Japan?

Are there any known official PC tools or methods for Sharp devices to pull update manifests outside Japan?

How do other Japanese carrier variants (like Docomo or au) behave in international markets regarding security patches?

Would love to hear insights or experiences from anyone handling Japanese carrier devices globally

i want to hear from actual users not professional reviewers

about a week in with the galaxy z fold8 now and the im noticing my favorite thing is smaller than what i thought id be.

the one that got me is that closing or folding it shut feels like an actual stop. on my old phone id lock it and just look at the clock but it's not the same as folding it shut. i didn't realize a folding phone would be so nice to fold shut, as well haha

It's a little thing but i actually notice how the feeling throughout the day of feeling food about being able to just close my phone and set it aside for a moment.

Not really a rant, more a "does anyone know a workaround" post. I own a Lenovo P2 (2016 phone, Snapdragon 625, still solid hardware, 5100 mAh battery). Wanted to unlock the bootloader for custom ROM work, and discovered the entire OEM-unlock chain for this device depends on a backend (unlockrowapi.lenovo.com) that's simply gone — no DNS issue, no maintenance page, just a dead endpoint. Result: fastboot oem unlock fails outright with an invalid-data error, and there's zero way through official channels for global-market ("ROW") Lenovo devices.

This is a pretty common pattern with smaller/discontinued OEMs — the phone hardware outlives the vendor's willingness to keep a tiny API server running, and a perfectly good device becomes stuck on stock EOL firmware forever. Curious if anyone here has dealt with something similar (Lenovo, Moto, ZTE, etc.) and found a workaround — leaked unlock tools, community-built unlockers, anything.

I just realised that outside India, Motorola sells this phone for about 1000 dollars. In India you can get it for less than 600 without exchange benefits or offers.

Triple sony Lyta cameras, strong Snapdragon 8 gen 5 performance , stock android, very very slim, 165 hz display, 5200 mah battery, 7 years of OS updates, and is better value than the Samsung FE series.

Does anyone else wish Android had a proper universal clipboard?

Like, if I copy something on my phone, I’d want to be able to paste it directly on my Windows PC without having to send it to myself through WhatsApp, Telegram, email, etc.

Especially for:

• Text
• Links
• Images
• Small snippets of code

I know there are apps/workarounds for this, but they always seem a bit hit-or-miss.

Do you guys actually use something for this already, or do you just send stuff to yourself?

Curious how other people handle it.

I just wanted to make a quick post about gemini. Inserting itself into my messages. So, like any other sane person, i figured out how to get rid of it.

If you follow the imgur link, then you will be able to see the next screen after gemini in messages.

Https://imgur.com/gallery/eHb6Is0