Xiaomi, OPPO and Vivo: Fix Delayed Email Notifications

If mail shows up ten or twenty minutes after it actually landed, the phone is the problem, not the email app. Xiaomi's HyperOS (and older MIUI), OPPO's ColorOS, and Vivo's Funtouch OS all run their own background-process manager on top of standard Android. That manager decides which apps get to keep running when the screen is off, and by default, most third-party apps lose.

This is not the same fight as stock Android's Doze mode. Doze is a single system-wide setting you can exempt an app from in one screen. These three skins layer at least three more controls on top of it, and an app has to clear all of them before it can reliably wake up, check the server, and push a notification while your screen is dark.

What this error literally means#

When you see delayed email notifications on one of these phones, the mail server did its job. Gmail, Outlook or your IMAP provider pushed the message the moment it arrived. The delay happens after that, inside the phone.

HyperOS, ColorOS and Funtouch each maintain an app-level power profile that's separate from the Android battery-optimization list Google ships. An app can be excluded from Android's own Doze restrictions and still get frozen by the OEM's layer a few minutes after the screen locks. The notification, the network socket that would have delivered it, and the background service that would have shown it are all suspended at once.

The practical result: the email app's push connection (or its periodic sync job) gets torn down while the screen is off, and nothing wakes it back up until you next open the app manually — at which point it syncs immediately and the notification finally fires, stamped with whatever time it actually arrived.

Causes table: which setting is actually blocking your mail#

Three separate toggles, three separate menus. It helps to see them side by side once before hunting through Settings, since granting one doesn't grant the other two.

Fix 1: enable autostart#

Autostart is the permission that lets an app relaunch its background service after the phone reboots or after the OS has killed it. Without it, HyperOS and ColorOS in particular treat a killed app as gone until you tap its icon again — no push, no scheduled sync, nothing.

Names and locations shift by software version and region, so treat the steps below as the shape of the fix, not an exact menu path for your build.

1. 1

   Open the autostart manager

   On Xiaomi/HyperOS: Settings → Apps → Manage apps → [email app] → Autostart, or Security app → App management → Autostart. On some regional builds it lives inside the Security app under Permissions instead of Settings.

2. 2

   Toggle it on for the email app

   Find your email app in the list and switch autostart to on. If the app doesn't appear, it may already be exempt — check the battery lock step below instead.

3. 3

   Confirm after a reboot

   Restart the phone once. Autostart settings on some HyperOS versions have been reported to reset silently after major OS updates, so re-check this screen after any system update.

Fix 2: remove the background app lock#

This is the setting most people assume is the whole fix, and it's necessary but not sufficient on its own. It governs whether the app can keep a process alive and a network connection open once the screen turns off.

1. 1

   Open battery settings for the app

   On Vivo/Funtouch: Settings → Battery → Background app refresh (or High background power consumption), find the email app. On OPPO/ColorOS: Settings → Battery → App battery saver → [email app].

2. 2

   Set it to unrestricted

   Choose the option equivalent to "No restrictions" or "Allow background activity." Some builds add a separate long-press action in the recents/app-switcher screen — a small lock icon on the app card that pins it against being swiped away by the system cleaner.

3. 3

   Lock the app in recents, if that control exists

   Open the recent-apps view, find the email app's card, and tap the lock icon if the skin offers one. This is a second, independent protection against the OS's own "clear all" background killer, distinct from the Settings toggle above.

Fix 3: raise the notification allowance#

Even with autostart and background lock both correct, some OEM skins still throttle how promptly a notification channel is allowed to post, or downgrade it to a silent/grouped channel that only surfaces on a manual check.

1. 1

   Open notification settings for the app

   Settings → Notifications → [email app]. On some builds this is nested one level deeper, under Notification management or App notifications.

2. 2

   Set the channel to high importance

   Enable "Allow notifications," set importance/priority to high, and turn on lock-screen and banner display. If your email app exposes per-account or per-folder notification channels, repeat this for each one you care about.

3. 3

   Disable any "optimize notifications" or "notification management" toggle

   Several skins ship a system-wide feature that reorders or delays lower-priority notifications to reduce interruptions. It's usually labeled something like Notification management or Smart notifications — turn it off for the email app if the option is per-app, or check it isn't suppressing mail globally if it isn't.

How to tell which cause you actually have#

If notifications only arrive after you open the app manually, and never on their own, autostart is the most likely culprit — the background process isn't relaunching at all.

If notifications arrive within a few minutes of screen-off but then stop until you touch the phone again, that points to the background app lock — the process starts fine but gets frozen shortly after.

If the email actually syncs (you can see it if you open the app) but no banner or sound ever appeared, the notification channel itself is capped or silenced — check Fix 3 rather than the battery settings.

Don't kill my app maintains a community-sourced, per-manufacturer database of exactly which settings each OEM uses to restrict background apps, and it's worth cross-checking your specific phone model there, since it tracks changes across software updates more closely than any single guide can.

Preventing it going forward#

The three-permission problem exists because these OEMs optimize their default battery scores against review benchmarks, and background network activity is the easiest thing to restrict to win that number. The fix works, but it's manual, per-app, and per-device, and it can silently revert on a software update.

AI Emaily can't reach into HyperOS, ColorOS or Funtouch's process manager — no email app can, since the restriction lives in the OS, not the mail client. What it does do is keep every account's unified inbox synced and triaged the moment the app is foregrounded, so even when a phone's background lock delays the notification banner, opening the app surfaces what actually needs a reply first rather than a flat chronological list you have to re-triage yourself. We build AI Emaily.

• Re-check all three settings after every major OS update — HyperOS, ColorOS and Funtouch updates have each reset autostart or battery-lock preferences on prior versions without warning.
• If you use more than one email app or account, repeat the fix per app; the OEM lock is applied per package, not globally.
• Where the phone offers a lock-screen or recents-card pin (a small padlock icon), use it in addition to the Settings toggles — it survives some "clear all" actions that the Settings-only fix doesn't.
• If push still lags after all three fixes, fall back to a shorter manual/periodic sync interval in the email app itself as a floor, even though it costs more battery than true push.