The App You Didn't Expect to Lose
You're mid-recipe. You flip to your notes app to check whether it's a teaspoon or a tablespoon of cumin, spend maybe fifteen seconds there, and when you tap back to the cooking video it restarts from the beginning. Not paused. Gone. You didn't close it. Nothing crashed. Your phone quietly executed it while your attention was elsewhere.
This isn't a bug. It's a deliberate, ranked system running constantly in the background, making cold-blooded triage decisions about which processes live and which get terminated. Understanding it changes how you think about the small glass rectangle you carry everywhere.
Not a Queue. A Hierarchy.
Phones don't close apps randomly, and they don't work through a simple first-in-first-out queue. They maintain a priority ladder. The process sitting at the bottom of that ladder dies first when RAM pressure spikes.
Both Android and iOS use variants of this model, though they implement it differently. Android makes its hierarchy explicit in the OS source code under a system called the Low Memory Killer (LMK), with a newer successor called LMKD (the daemon version). iOS keeps its implementation more opaque, but the same tiered logic applies underneath.
The ladder, in rough order from safest to most expendable:
- Foreground processes. The app you're actively touching. Essentially untouchable.
- Visible processes. Something rendered on screen but not focused, like a widget or a picture-in-picture video.
- Service processes. Apps running a declared background service: music players, navigation apps mid-route, a podcast app mid-download.
- Cached (background) processes. Apps you've used but aren't doing anything declared. Sitting in RAM purely for faster relaunch.
- Empty processes. Shells kept alive only to speed up a cold start next time. First against the wall.
When free RAM drops below a threshold, the system works from the bottom up. Empty processes go first, then cached ones. It only touches service processes if things get genuinely desperate.
The Score That Seals Your App's Fate
On Android, each process carries a number called the `oom_adj` score (Out Of Memory adjustment score). Zero means the foreground app: safe. Higher numbers mean more expendable. The kernel's OOM killer and the LMKD daemon watch this score continuously, like a bouncer with a very long, very dynamic list.
When available memory crosses a low-water mark, Android defines several thresholds (low, medium, critical, each triggering progressively aggressive killing), and the daemon sorts all background processes by `oom_adj` score and terminates the highest-scored ones first. A cached process scored at 900 dies before one scored at 700. The numbers aren't arbitrary: the system recalculates them in real time as you switch apps, grant permissions, or as a background service declares itself active.
That last point matters. An app can defend itself. When Spotify declares a foreground service, you'll notice the persistent notification pinned to your status bar. It's essentially filing paperwork with the OS: "I'm doing real work, don't kill me." The OS honors that, mostly.
iOS doesn't publish its equivalent scores, but the mechanism is analogous. Apps register background modes explicitly (audio, location, fetch, VOIP, and a handful of others). Anything outside those modes gets suspended, not just deprioritized. Suspended processes consume RAM but no CPU. When RAM tightens, suspended apps are terminated wholesale, with no notification that it happened. They simply restart cold next time you open them.
A Tale of Two Phones, Same App
Consider two people using the same navigation app on a long drive.
Marta has a phone with 6 GB of RAM and four other apps open in the background: a music app actively streaming, a messaging app with a background notification listener, and two cached browser tabs. Her navigation app has declared a location background mode. Even when she checks her messages mid-route, the navigation app holds its position in the hierarchy. Its `oom_adj` score stays low. It survives.
Daniel has a phone with 3 GB of RAM, still common on budget handsets. He's got eleven cached apps sitting in memory from a morning of heavy use. When he opens the camera to grab a photo, the system needs to load the camera pipeline, a memory-hungry process, and the pressure spike is sharp. The navigation app, despite its declared background mode, is competing with more processes for less headroom. Some manufacturers tune their low-memory thresholds aggressively, and on Daniel's phone, that means a service process the system would normally spare gets terminated regardless. He comes back to navigation to find it recalculating from scratch.
Same app. Different outcome. The RAM budget is the whole story.
What Manufacturers Do to the System
This is the part that catches most people off guard, and honestly, it should make you a little annoyed on behalf of every developer who has ever tried to build a reliable background service.
The vanilla Android priority system described above is what Google ships. What you actually get on your phone may be significantly more aggressive. Samsung, Xiaomi, OnePlus and others layer their own memory management on top. Some do this to hit battery targets. Others do it to make benchmark scores look cleaner. The result is a system that kills background apps earlier and more ruthlessly than stock Android would. Researchers at the site Don't Kill My App (a real resource maintained by developers) have documented specific manufacturers that terminate background processes within minutes of an app leaving the foreground, even when that app has a declared background service.
This is why your alarm app from a third-party developer might not fire on a Xiaomi device but works fine on a Pixel. The Pixel runs close to Google's spec. The Xiaomi has an additional kill layer that doesn't respect the declared service in the same way.
Apple doesn't have this fragmentation problem, because Apple controls the whole stack. But iOS is famously stingy about which background modes it permits in the first place. You can't just declare "I need to run in the background" on iOS. You pick from a short approved list, and if your use case doesn't fit, you get suspended. Full stop.
The Numbers Behind the Pressure
To make this concrete: on a device with 4 GB of RAM, Android's default low-memory thresholds are often configured so that aggressive killing starts when free RAM drops below roughly 200 to 300 MB. At that point, cached processes with high `oom_adj` scores start dying. Critical thresholds, where even service processes become vulnerable, typically kick in below 100 MB of free memory.
Those numbers shift with total RAM. A 12 GB device can afford lazier thresholds, keeping more cached processes alive longer. So when you open a heavy app on a RAM-constrained phone, say the camera, which needs 300 to 400 MB to initialize its processing pipeline, and the system is already near the low threshold, five cached apps can die in two seconds to make room. You've felt this. That slight hesitation when your phone comes back to an app and has to reload it. That pause is a cold start, the process was killed, state was lost or partially serialized to disk if the developer handled it well, and the app is launching fresh.
What You Can Actually Do About It
Not much, honestly. That's the correct answer.
Manually swiping apps out of the recents tray doesn't help and often makes things worse. When you force-close a cached process, you remove something the OS had already decided was worth keeping. The next time you open it, it cold-starts, using a burst of RAM and CPU to reload. The system's judgment about what to keep is, in most cases, better than yours.
What does help: keeping fewer apps installed that run persistent background services. Each declared service is a process that defends itself with a lower `oom_adj` score, crowding out everything else. Twenty apps with persistent notifications are twenty processes competing for the safe zone. Do you actually need all of them running all the time, or have you just never thought to check?
If your phone is killing apps you actually care about, look for a battery optimization exemption list in your settings. Most manufacturers have one. Whitelisting a specific app tells the aggressive kill layer to leave it alone, letting the standard OS hierarchy do its job the way it was designed to.
The system isn't broken. It's doing exactly what it was built to do: keep your current experience smooth at the expense of everything you're not looking at. The real question is whether your manufacturer tuned it for your benefit or for their benchmark numbers. Those are not always the same thing.