Flutter background sync stops on certain Android 13 OEM ROMs when device Doze enters aggressive standby

Environment

Flutter 3.7 app using flutter_workmanager plugin (Android embedding v2). TargetSdkVersion 33. Users reported failures mainly on Xiaomi MIUI 14 and OnePlus OxygenOS devices running Android 13 with vendor aggressive battery optimizations. Server uses push notifications for occasional wake-ups.

Symptoms

Periodic background sync tasks scheduled with WorkManager stop running after ~12–36 hours on affected devices. The app shows no background logs, and syncs resume only when the user opens the app or explicitly whitelists it through device battery settings. Stock Pixel devices and Android emulator behave normally.

Observations

Logcat from affected devices shows app process killed by low-memory killer or OEM battery manager; WorkManager never starts the worker (no onStopped/onStarted). adb shell dumpsys deviceidle reports the app in deep idle and app standby bucket as 'restricted'. Programmatic requests to ignore battery optimizations succeed (Intent ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS) but are ignored by OEM unless user explicitly grants permission in settings. High-priority FCM messages sometimes wake the app but are throttled by OEM after repeated use.

Already attempted

Replaced flutter_workmanager with flutter_background_fetch on a test build — same results on affected OEM ROMs. Implemented a foreground service fallback for long-running syncs, which worked but is undesirable because it shows persistent notification and impacts UX. Added retries with exponential backoff. Asked a subset of users to whitelist app in battery settings — that fixed the problem for them.

Question

Given OEM aggressive Doze policies that prevent periodic background work on many devices, what robust, production-appropriate strategies exist (with Flutter) to ensure periodic sync runs reliably without requiring most users to manually whitelist the app?

Post timeline

COMMUNITY RESPONSES

Verified community troubleshooting

0 replies

No answers yet..

Showing 0 of 0 community responses

AI DIAGNOSTICS

Incident analysis

Updated 1w ago• Trouble ID

Most likely causes

App not whitelisted for battery optimizations and therefore moved to deep idle by manufacturer heuristics. 100%

OEM-specific aggressive battery management kills background processes and blocks alarms/WorkManager execution. 95%

Use of plugins that rely on AlarmManager with non-RTC_WAKEUP flags that are deferred in Doze. 25%

Summary

OEM vendors often implement stricter battery optimizations than upstream Android, blocking alarms, jobs, and sometimes high-priority FCM. WorkManager is the recommended API and should survive Doze on Android stock devices, but vendor modifications can kill the host process or block scheduling. Foreground services or high-priority FCM messages are more reliable ways to wake code, but they carry UX and policy implications. The solution requires a combination of API best-practices, fallbacks, and user education for the smallest number of manual steps.

Suggested Fixes

Diagnostic step 1

Verify WorkManager initialization: ensure you initialize WorkManager in Application.onCreate using androidx.work.Configuration if required by plugin; test with a minimal native Android sample to rule out plugin bug.

Diagnostic step 2

Implement a documented fallback: use a short-lived foreground service for essential syncs (triggered by user action or when app is foreground) and avoid leaving it running permanently. This is reversible and visible to users via notification.

Diagnostic step 3

Use high-priority Firebase Cloud Messaging sparingly to wake the app for critical syncs; be mindful that OEMs may still throttle/ignore FCM. Do not abuse high-priority messages to avoid platform penalties.