TECHNICAL DOCUMENT

Why Battery Optimization Keeps Closing Your Parental Control App on Android

You set a two-hour limit. You checked it was on. Three days later you look at the weekly numbers and your child had four hours on Tuesday, and nothing on the phone said a word.

The frustrating part isn’t the failure. It’s that everything still looks correct. The limit is there in the settings. The app opens fine. There’s no error, no warning, nothing to tap.

What’s usually happened is that the phone stopped letting the app run. Android has several independent mechanisms for shutting down background apps, and phone manufacturers add more of their own on top. Almost all of them are on by default, and none of them tell you when they’ve fired.

This page covers what those mechanisms are, how to tell whether one of them is what’s biting you, and exactly where the setting lives on eight brands. Where I couldn’t verify a menu path against the manufacturer’s own documentation, I say so rather than guessing — there’s a lot of confidently wrong copy-paste on this topic, and some of it has been repeated so often that it’s become the standard answer.

The thirty-second version

There are three separate layers, and fixing one doesn’t fix the others: Android’s own idle rules, a per-app battery setting, and (on many brands) a manufacturer launch manager.
The per-app setting called “Restricted” is the brutal one. Google’s own documentation says it removes existing foreground services from the foreground and stops the app’s alarms firing. That’s a total kill for a screen-time app, from one innocuous-looking toggle.
Manufacturer launch managers are separate from the battery whitelist. On Huawei especially, doing the battery step and stopping there is the single most common reason this fails.
You can test it in three minutes without any technical tools. The method is below.
Force-stop is unfixable. If someone force-stops the app, nothing brings it back until a person opens it again. That’s Android by design, and any app claiming otherwise is wrong.

Part 1 — the three layers

Layer 1: Doze and App Standby (every Android phone)

When a device is unplugged, stationary and screen-off for a while, Android enters Doze. Google’s documentation lists what that suspends: network access, wake locks, sync adapters, and JobScheduler work — which, as the same page notes, means WorkManager tasks don’t run either. Standard alarms get deferred to the next maintenance window, and the system schedules those windows less frequently the longer the device stays idle.

There are alarm types that survive Doze, but with a ceiling that matters: the “allow while idle” alarms can’t fire more than once every nine minutes, per app. So an app that wants to check on things every minute simply cannot, once the phone is dozing. There’s one exception, and Google is unusually blunt about it:

Because these alarms are highly visible to users, the system never adjusts their delivery time. The system identifies these alarms as the most critical ones and leaves low-power modes if necessary to deliver the alarms.

That’s the alarm-clock type — the same category as the alarm that wakes you up. It’s the only public mechanism carrying that guarantee, which is why well-built screen-time apps reach for it during the moments that actually matter, and only then. Used around the clock it would wake the phone every minute all night, which is its own kind of broken.

Separately, App Standby sorts apps into buckets — active, working set, frequent, rare, restricted — and each bucket gets progressively less. In the rare bucket an app gets one alarm an hour and no network. In restricted, it gets one alarm a day. An app lands in restricted after the user doesn’t interact with it for 8 days on Android 13 and up. That is a very ordinary thing to happen to a parental-control app, because the whole point is that nobody opens it.

Layer 2: the per-app battery setting

Open Settings → Apps → [the app] → Battery on more or less any Android phone and you’ll find three options. Google’s developer documentation defines them:

Unrestricted — allow all background work, which might use more battery.
Optimized (the default) — the system decides, based on how you use the app.
Restricted — fully prevents the app from running in the background.

That third one deserves a much louder warning than it gets. Per the same documentation, an app in the restricted state cannot launch foreground services, has existing foreground services removed from the foreground, gets no alarms triggered, and has no jobs executed.

Read that again with a screen-time app in mind. The persistent notification is the foreground service. If someone sets the app to Restricted — and phones sometimes suggest this, in a “this app is using a lot of battery” prompt — the app is comprehensively switched off while continuing to appear installed and configured. This is the layer I’d check first, because it’s one screen and it explains the symptom completely.

Google does allow apps to request exemption from battery optimization, but only for particular categories. The acceptable-use list explicitly includes safety apps — “apps that keep their users and their families safe” — which is the basis on which a family screen-time app can legitimately ask. Google Play treats bypassing power management as a violation for apps that aren’t eligible.

Layer 3: manufacturer launch managers

This is where it gets brand-specific, and where most of the confusion lives.

On stock Android, running a foreground service is supposed to be enough. Google’s documentation for Android’s app freezer says apps with visible activities or foreground services stay unfrozen — only cached processes get frozen, ten seconds after they go cached on Android 14+.

Several manufacturers do more than stock Android does. Their systems can suspend an app’s background process even when it’s running a foreground service, and — this is the important part — they do it through their own controls, which Android’s APIs cannot see. An app can check the battery whitelist, check its standby bucket, check whether background execution is restricted, get “everything’s fine” for all three, and still be frozen solid.

We’ve measured this on our own test phone. On a Huawei GFY-AL00 running EMUI 14.2 (Android 12), with the manufacturer’s App launch setting left at its default, the monitoring service accumulated essentially no CPU time while a video app was in the foreground. Switching that one setting to manual changed it to roughly 45 seconds of CPU over three minutes, and the countdown started updating live again.

In a separate test on a Huawei phone running EMUI, we watched the system withhold the app’s one-minute heartbeat alarm for just over five minutes — the system’s own alarm dump reported a maximum delay of about five minutes, and the blocking screen that should have appeared immediately arrived 5 minutes 33 seconds late. Moving to the alarm-clock type quoted above brought the same scenario down to about 57 seconds.

Two caveats I want to be clear about. That’s one phone, one ROM version — I’m telling you what we saw on the device we own, not stating a rule about a brand. And this isn’t manufacturers behaving badly: aggressive background management is a large part of why these phones get the standby time they do, and it developed in a market where a lot of apps genuinely did abuse background wakeups. The cost is that apps you deliberately want running have to be marked as exceptions, by hand, in a place most people never visit.

Force-stop is a fourth thing, and it’s terminal

If anyone opens Settings, finds the app, and taps Force stop, that is different in kind from everything above. Google documents that the app stays in that stopped state until the user explicitly launches it again, and that it won’t receive the boot-completed signal in the meantime. On Android 15 the system also cancels the app’s pending intents and greys out its widgets.

There is no workaround. Not for us, not for anyone. It’s a deliberate design decision that the user gets the final say over whether an app runs, and I think it’s the right one even though it’s inconvenient here.

Part 2 — how to tell if this is your problem

Three tests, cheapest first, no tools needed.

Test 1 — the count-up test. Note the remaining minutes the app shows. Hand the phone over, or open whatever app your child uses, and leave it in the foreground for three minutes without switching away. Then check the remaining minutes again.

Dropped by about three minutes, and correct the instant you looked → the app is running.
Unchanged → it isn’t.
Jumps to catch up a second after you open the screen-time app → this is the diagnostic one. It means the app wasn’t counting while your child was watching and reconstructed the gap afterwards. A well-built app will backfill so no free minutes are gained, but backfilled time can’t block anything at the moment it mattered.

Test 2 — is the notification still there? A screen-time app that’s monitoring should have a persistent notification. If it’s gone, the foreground service is gone. Check whether the app got set to Restricted (Layer 2) before assuming anything more exotic.

Test 3 — the overnight test. Check the remaining minutes last thing at night, then first thing in the morning before opening anything. If the app has lost track of time overnight, or the notification has disappeared, you’re looking at Doze or a manufacturer manager rather than a one-off.

If any of these point at a problem, the fix is Part 3 — and the order to do it in is: per-app battery setting first (one screen, explains most cases), then the manufacturer launch manager, then everything else.

Part 3 — the settings, by brand

Honesty note on this table. Manufacturer support documentation for these settings ranges from good to nonexistent, and menu names churn between OS versions. I’ve marked each entry by whether I could confirm it on the manufacturer’s own site. Where I couldn’t, I’ve said so instead of printing a plausible-looking path — three of the paths I expected to write turned out to be wrong when checked, so this caution is earned.

Brand	Where the setting is	Verified?
Huawei	Open Settings, search App launch, turn off Manage automatically, then enable Auto-launch, Secondary launch, Run in background	Official
Xiaomi / Redmi / POCO	Settings → Apps → Permissions → Background autostart	Official
Samsung	Settings → Battery → Background usage limits (One UI 7) or Settings → Battery and device care → Battery → Background usage limits (earlier), then add the app to the never-sleeping list	Official
OnePlus	Settings → Apps → Auto launch; plus Settings → Battery → More settings → Sleep standby optimization	Official (OxygenOS 13)
vivo / iQOO	Settings → More settings → Permission management(Applications) → Autostart	Official (Funtouch OS)
OPPO / realme	Phone Manager has auto-launch and background controls, but no exact current path verified	Not verified
Meizu	No official documentation found at all	Not verified
Lenovo / Motorola	Near-stock; use Settings → Apps → [app] → Battery → Unrestricted	Stock Android path

The per-brand detail:

Huawei. The one that catches most people, because App launch and battery optimization are two different switches and doing only the battery one is not enough — Huawei’s own support page lists them as separate steps for the same app. It’s also where the menu path is least stable, which is why searching Settings beats navigating. Worth noting that Settings → Battery → App launch, the path nearly every third-party guide repeats, appears on no official Huawei page I could find. Full walkthrough and a verification method: the Huawei-specific page.

Xiaomi. The official toggle is Background autostart, under Apps → Permissions — not “Autostart” under app management, which is what most guides say and what I assumed before checking. Xiaomi also has a battery screen at Settings → Battery → Battery settings → App battery saver; the screen is documented but the individual option names on it are not, so pick the least restrictive one available rather than trusting a name you read somewhere.

Samsung. Samsung’s naming changed recently and both versions are live in the wild. On One UI 7 the list is called Never auto sleeping apps; on earlier versions it’s Never sleeping apps, reached via Battery and device care. Add the app to that list, and make sure it isn’t in Sleeping apps or Deep sleeping apps. Samsung also has a Put unused apps to sleep toggle that will catch an app nobody opens. I could not find official Samsung documentation for a per-app Unrestricted/Optimized/Restricted screen, so I’m not giving you a Samsung path for that one.

OnePlus. Verified from the OnePlus 11 user manual: OnePlus kept a separate Auto launch manager under Settings → Apps after the ColorOS merge. The widely-repeated Battery optimization → Advanced optimization → Deep optimization route does not appear anywhere in that manual — it describes older OxygenOS versions.

vivo. The autostart path is documented on vivo’s official support site. A “high background power consumption” allowlist is widely reported and probably exists on your phone, but vivo doesn’t document a path for it that I could find, so I’m not printing one.

OPPO and realme. I genuinely could not verify anything here. OPPO’s support articles are JavaScript pages that serve no text to fetch, and the only official manuals indexed are for ColorOS versions several generations old. OPPO’s Phone Manager does have auto-launch and background-running controls — their own newsroom describes them — but with no menu path attached. Look under Phone Manager and under the app’s own info screen, and treat anything more specific you read online as unconfirmed.

Meizu. Nothing. No reachable official documentation in English or Chinese. The community references that exist cite no Meizu documentation and no version numbers.

Lenovo and Motorola. These run close to stock Android and generally don’t add an autostart manager, so the stock per-app battery setting is the one that matters. (There is one official Motorola page showing an “Auto launch management” menu, but it names no device or Android version, so I can’t tell you which phones it applies to.)

What none of this fixes

No setting makes an app un-killable. You can do everything on this page and still get killed by a low-memory event, a ROM update that resets your choices, or a manufacturer battery feature nobody has documented.

Force-stop still ends it, as covered above. If your child is old enough to find Settings and tap Force stop, no configuration prevents that — you’re in a different conversation, one about the arrangement between you rather than about the phone.

A screen-time app should tell you when it’s been interrupted. Since Android can’t report the state of a manufacturer’s private setting, the only honest signal is after the fact: noticing that time got used while monitoring was down, and saying so. That’s a smoke alarm, not a fire door — worth having, but not a substitute for the settings above.

Reliability and battery life genuinely trade off. Every exemption here means the app runs more. A well-behaved screen-time app should cost you very little, but “runs reliably in the background” and “consumes nothing” cannot both be fully true.

Huawei App Launch Management and why it stops parental control apps — the deep dive on the single most common cause
How to keep the app from being killed by battery saver — the shorter, setup-oriented version
How to make Android warn your child before screen time ends — the next question, once limits are actually enforcing

Written by a parent who builds Tortoise Time, an Android screen-time app for kids aged 6 to 14. It nudges quietly at 60%, 75%, and 90% of the daily limit before blocking anything at 100%. It’s free, with no ads and no in-app purchases. Your child’s screen-time data stays on the phone by default — the only things that leave the device are anonymous crash reports and usage statistics, as our privacy policy says.

Sources

Retrieval level noted for each, because it changes how much weight the claim can carry.

“Optimize for Doze and App Standby.” Android Developers. (Full page retrieved twice. Source for what Doze suspends, maintenance windows becoming less frequent over time, the nine-minute floor on allow-while-idle alarms, App Standby’s idle determination, and the acceptable-use list for battery-optimization exemption including safety apps.)
“App Standby Buckets.” Android Developers. (Full page retrieved. Source for the bucket names.)
“Power management restrictions.” Android Developers. (Full page retrieved. Source for the per-bucket alarm and network quotas, and for an app entering the restricted bucket after 8 days without interaction on Android 13+.)
“Optimize battery use for App Standby.” Android Developers. (Full page retrieved. Source for the Unrestricted / Optimized / Restricted definitions and for the restricted state removing existing foreground services from the foreground, blocking alarms and preventing jobs from executing.)
“Schedule alarms.” Android Developers. (Full page retrieved twice, second pass requesting character-for-character reproduction; both retrievals matched. Source for the quoted sentence about the system never adjusting alarm-clock delivery times and leaving low-power modes to deliver them.)
“Behavior changes: all apps” (Android 15). Android Developers. (Full page retrieved. Source for the force-stopped state persisting until the user launches the app, boot-completed delivery, and Android 15 cancelling pending intents and disabling widgets.)
“Cached apps freezer.” Android Open Source Project. (Full page retrieved. Source for apps with visible activities or foreground services staying unfrozen, and the ten-second freeze delay for cached processes on Android 14+.)
“Device and Network Abuse.” Google Play Developer Policy. (Full page retrieved. Source for bypassing system power management being a violation for apps that aren’t eligible for allowlisting.)
“How Do I Keep an App Running in the Background.” Huawei Consumer Support. (Full page retrieved twice. Source for App launch and battery optimization being documented as two separate steps, and for the three switch names.)
“Setting App Launch.” Huawei Consumer Support. (Full page retrieved twice. Source for the search-based route and for Manage automatically.)
“How to switch on/off the Background autostart for APPs.” Xiaomi Global Support, KA-507611. (Full page retrieved twice. Source for Settings → Apps → Permissions → Background autostart. Note this particular page is written for the Xiaomi 14T Pro and states no OS version. I could not verify whether the same path holds across all MIUI/HyperOS devices, so treat it as one confirmed data point rather than a universal path.)
“How to enable App battery saver.” Xiaomi UK Support, KA-61830. (Full page retrieved twice. Source for the App battery saver path. The page names the screen but does not enumerate its options, so the option names are not sourced here.)
“Background usage limits.” Samsung US Support. (Full page retrieved twice. Source for the One UI 7 path and Never auto sleeping apps.)
“How to use Background usage limits.” Samsung US Support. (Full page retrieved twice. Source for the earlier Battery and device care path and Never sleeping apps. Samsung’s two pages genuinely disagree because the UI changed; both are reproduced above.)
OnePlus 11 5G User Manual (English, PDF). OnePlus. (Downloaded and text extracted mechanically rather than summarized. Source for Settings → Apps → Auto launch and Settings → Battery → More settings → Sleep standby optimization on OxygenOS 13, and for the absence of “Deep optimization” and “Don’t optimize” anywhere in the manual.)
“How to turn on/off Autostart for my apps.” vivo official support (Philippines). (Full page retrieved twice. Source for Settings → More settings → Permission management(Applications) → Autostart, including the parenthesis, on Funtouch OS above 2.6.)
“Boost your battery.” OPPO Newsroom. (Full page retrieved. Confirms Phone Manager has auto-launch and background controls; gives no menu path, which is why no OPPO path is printed above.)
Our own device testing, Huawei GFY-AL00, EMUI 14.2, Android 12. (CPU-time comparison for the monitoring service with the manufacturer’s App launch setting at default versus manual; and, in a separate test on a Huawei phone running EMUI, the system’s alarm dump reporting a maximum delay of roughly five minutes on a one-minute heartbeat, with blocking arriving 5 minutes 33 seconds late, improving to about 57 seconds after moving to the alarm-clock type. Our own measurements on Huawei hardware, a single ROM version in each case — reported as observations, not brand-wide behavior.)
dontkillmyapp.com. (Community-maintained, not manufacturer documentation. Consulted for every brand above. Referenced here only to note where a widely repeated path — such as Huawei’s Settings → Battery → App launch — has no official basis.)

Not verified: OPPO and realme menu paths on any current ColorOS version; any Meizu path; vivo’s high-background-power-consumption allowlist path; Xiaomi’s App battery saver option names; a Samsung per-app Unrestricted/Optimized/Restricted path; the device scope of Motorola’s “Auto launch management” page. Honor was not researched separately for this article — it split from Huawei in 2020 and now ships MagicOS, so Huawei’s paths are a starting point rather than a verified answer.