Android battery settings that stop run tracking
Short answer
Android stops a run tracker when the system decides a background app is a battery cost, and manufacturer task managers on Samsung, Xiaomi and OnePlus devices are more aggressive than stock Android. Exempting the app from battery optimisation lowers the chance of a kill without removing it, so the question that decides whether you lose kilometres is what the app had already written to storage before it died.
Exempting the app from battery optimisation lowers the odds without removing them. Android stops a run tracker when the system decides a background app is a battery cost, and the manufacturer layer on top is usually the part that actually does it. What decides whether you lose kilometres is not the exemption. It is what the app had already written to storage before the process went away.
Why Android stops a running app
Two systems can end your recording.
- The platform rules Google documents: Doze, app standby buckets and the background location limit. They behave the same on every phone that ships them unmodified.
- The manufacturer layer: Samsung's sleeping apps, Xiaomi's autostart control, OnePlus deep optimisation. None of it is in Google's documentation. It differs per vendor and per firmware, and on several brands it is switched on by default.
They need different fixes. If a run tracker works on a Pixel and dies on a Galaxy, the second list is where to look. Working through the first list on a phone whose vendor layer is doing the killing changes nothing, which is why generic battery advice so often fails here.
Battery optimisation, Doze and app standby
Doze is what most people mean by battery optimisation, and it is probably not what stopped your run. Android defines the entry condition narrowly: "If a user leaves a device unplugged and stationary for a period of time, with the screen off, the device enters Doze mode", per Android's Doze and App Standby guide, fetched 2 August 2026. A phone moving in your pocket is not stationary.
Read that page's restriction list for what is absent from it. Doze suspends network access, ignores wake locks, defers standard alarms to the next maintenance window, skips Wi-Fi scans and blocks sync adapters and JobScheduler. Location updates delivered to a running foreground service are not on the list. Doze explains a run that failed to upload far better than a run that stopped recording.
App standby is the closer fit. Android sorts apps into five priority buckets, Active, Working set, Frequent, Rare and Restricted, and adds that "Every manufacturer can set their own criteria for how non-active apps are assigned to buckets", per Android's App Standby Buckets guide, fetched 2 August 2026. That sentence is the licence. Vendors use it to be stricter than stock Android. There is also a hard limit on location itself. From Android 8.0 onward, "if your app is running in the background, it can receive location updates only a few times each hour", per Android's background location limits documentation, fetched 2 August 2026. A few times an hour is useless for pace and splits, which is why run trackers use a foreground service instead.
What a foreground service does and does not guarantee
A foreground service is not immortal.
What it does do is keep location updates flowing with the screen off, and Android requires it to post a visible status bar notification. The documentation names a fitness app showing distance travelled during a workout as one of its examples, per Android's foreground services guide, fetched 2 August 2026. That notification is the one signal you can check mid run with the phone still locked.
Android classifies a foreground service as a visible process, second in the importance hierarchy, not first, and says such processes "are considered extremely important and aren't killed unless doing so is required to keep all foreground processes running", per Android's process lifecycle documentation, fetched 2 August 2026. Open a camera, a map and a heavy game during a long run and you are pushing on exactly that condition.
The permission side has its own trap. Android states that you cannot create a location foreground service while the app is in the background unless it holds ACCESS_BACKGROUND_LOCATION, per Android's foreground service types documentation, fetched 2 August 2026. In practice a run has to be started from the app in front of you. It cannot be started for you from the background.
Manufacturer settings, one by one
This layer kills run trackers. The community reference dontkillmyapp.com scores seventeen manufacturers on how aggressively they stop background work, and Huawei, Xiaomi, OnePlus and Samsung sit together at the head of that list on the worst score, five out of five, while AOSP, Pixel and Android One builds score zero, fetched 2 August 2026. Its summary of the motive is blunt: manufacturers "prefer battery life over proper functionality of your apps".
| Phone | What to change | Where it lives |
|---|---|---|
| Samsung Galaxy | Add the app to Never sleeping apps, and switch off Put unused apps to sleep | Settings, Battery and device care, Battery, Background usage limits, per Samsung support, fetched 2 August 2026 |
| Xiaomi | Enable Autostart, set the app's battery saver to No restrictions, lock it in the recents tray | Security app, Permissions, Auto-start; then Battery, App Battery Saver, your app, No restriction, per dontkillmyapp.com, fetched 2 August 2026 |
| OnePlus | Set battery optimisation to Don't optimize, turn off deep optimisation, called the main app killer there, then check both again later because dontkillmyapp.com reports OnePlus reverting the setting at random | System settings, Battery, Battery optimization, All apps, your app; advanced optimisation sits behind the three dot menu, per dontkillmyapp.com, fetched 2 August 2026 |
| Pixel and other stock builds | Set the app's Battery usage to Unrestricted. The default, Optimized, is the setting that limits background work | The Battery usage page in system settings, where Android documents the three choices as Unrestricted, Optimized and Restricted, per Android's background optimization guide, fetched 2 August 2026. Stock builds are scored at zero aggressiveness by dontkillmyapp.com, fetched 2 August 2026 |
Samsung deserves a specific warning, because its behaviour looks like the fix wearing off. Its support page describes Background usage limits as one switch, Put unused apps to sleep, plus three lists: Sleeping apps, Deep sleeping apps and Never sleeping apps (Samsung support, fetched 2 August 2026), and the community reference warns that unless Put unused apps to sleep is disabled, Samsung puts apps back to sleep after a few days, three by default (Samsung page, fetched 2 August 2026).
How to tell a kill from a crash afterwards
From the outside these look identical. You take the phone out, the app is at its start screen, the run is not on it. Separating them is worth two minutes. A kill is a settings problem you can solve. A crash is not.
- Check the notification shade before you touch the appIf the ongoing run notification is gone but the phone is otherwise normal, the service was stopped. If it is still there and the app shows no run, the problem sits in the app rather than in Android.
- Look at where the recorded track endsA kill stops the track cleanly at a point, and it never resumes. Thin or absent from the start is a permission problem. A gap with recording either side of it is a dropped signal.
- Ask what else you openedCamera, maps or a game during the run points at memory pressure, the one condition under which Android says a visible process can still be terminated. Nothing opened at all points at the vendor battery layer instead.
If you are chasing the same symptom on an iPhone, the order of checks is different enough to read separately in why an iPhone stops tracking a run in your pocket.
What survives the kill and what does not
Once the process is gone, nothing in Android decides how much of your run you keep.
The app does. It decided long before you started running. An app that holds the whole track in memory and writes it once, when you press save, has a single point of failure and loses everything if the process dies first. An app that appends each batch of positions to a local database as the batch arrives loses only what the operating system had collected but not yet handed over. That mechanism is worth understanding on its own terms in why running apps lose runs.
Runflake takes the second design and states it precisely. Every GPS point is written to the phone's database the moment it arrives, before the app does anything else with it, so there is no save timer and no save at the end step for the raw track. Each arriving batch is written in one all or nothing transaction, so a run can never end up with half a batch on disk. After a crash the app rebuilds the run by replaying the raw points, steps and events from the database rather than trusting the stored summary. When it restarts and finds an unfinished run it offers to resume: the card reads "You have an unfinished run" with the line "Saved up to where it stopped", a Continue button, and a Hold to finish button that requires a long press so a mis-tap cannot end the run. Runflake is built and is not yet published to the App Store or Google Play, so there is no download available today.
What no design recovers is the interval while the process was dead. Nothing is recorded then. That is a gap in the track, not a section filled in later. The honest statement about a kill is that every batch the app had already received is on disk, that whatever the operating system was still holding when the process went away is not, that the dead interval is missing outright, and that nobody has measured the size of that undelivered window for you.
A test you can run on your own street
Do this once, before a long run you care about, on a loop whose length you already know.
- Configure before you test, not afterGrant the battery optimisation exemption, then apply the table row matching your phone. Change nothing else, or you will not know which setting mattered.
- Lap one, clean conditionsStart the run, lock the screen, pocket the phone and walk ten minutes without touching it. This tests the vendor battery layer with nothing competing for memory.
- Lap two, under pressureRepeat the ten minutes, but open the camera, a maps app and the heaviest game on the phone partway through before locking the screen again. This tests the condition Android names as able to terminate a visible process.
- Judge by the track, not the totalA plausible looking total can still hide a gap. Find where the line stops, and compare elapsed time against a clock, not against the app's own summary.
- Repeat lap one three days laterOn a Samsung device this catches the put unused apps to sleep behaviour, which only bites after several days without opening the app. If lap one passed and the repeat fails, the sleeping apps list is the setting to fix.
The goal is not a promise that the app will never be killed. It is knowing which of your phone's settings mattered, and what the app leaves on disk when the kill happens anyway. Those two facts are the difference between losing a long run and losing the last minute of one.
Common questions
- Does exempting a running app from battery optimisation drain my battery?
- It removes one system power rule for a single app rather than for the whole phone. The cost is bounded by what that one app actually does while a run is in progress, and every other app stays under exactly the same power management it had before you changed anything.
- Why does a Samsung phone start killing a run tracker again after it worked fine for a week?
- Samsung puts apps you have not opened for a while back to sleep, so a run tracker you use twice a week is the exact profile that gets caught. Adding the app to the Never sleeping apps list is what stops that recurring, rather than granting the battery optimisation exemption once and assuming it holds.
- Is the ongoing notification enough to know the run is still recording?
- It tells you the service that keeps location updates flowing is still alive, which is the most useful thing you can check without unlocking the phone. It does not tell you the app is still writing points to storage, so treat it as a necessary sign rather than a sufficient one.
- Do I lose the kilometres I already ran when Android kills the app?
- That depends on when the app writes to storage, not on why it died. An app that holds the whole track in memory until you press save loses all of it, while an app that appends each batch of positions to a local database as the batch arrives keeps every batch that had already reached it and loses only what the operating system was still holding.