Something is wrong with your Android phone. You have 12 gigabytes of RAM — maybe 16 — and yet the moment you switch from your camera to your messaging app, the conversation reloads from scratch. Your Spotify stream dies when you open Google Maps. That browser tab you were reading? Gone. Wiped clean. Start over.
This isn’t a hardware problem. It’s a software one. And it’s getting worse.
A growing chorus of Android users and developers has been sounding the alarm about aggressive memory management on modern Android phones, a phenomenon that prematurely kills background apps even when the device has gigabytes of free RAM sitting unused. The issue, as reported extensively by Android Authority, has reached a point where some in the developer community are calling it a full-blown crisis — one that undermines the fundamental promise of multitasking on mobile devices.
The numbers tell a stark story. Today’s flagship Android phones ship with 12GB or 16GB of RAM as standard. Some gaming-oriented models push to 24GB. For context, many desktop computers run comfortably on 16GB. Yet Android phones with this much memory routinely behave as if they’re starving for resources, killing apps that users fully expect to remain running in the background.
The Phantom Memory Problem
To understand what’s happening, you need to understand how Android manages memory — and how phone manufacturers have twisted that system beyond recognition.
Android, at its core, is built on Linux. It inherits Linux’s philosophy that free RAM is wasted RAM. The operating system is designed to keep apps cached in memory so they can resume instantly when a user switches back to them. When memory pressure increases, Android’s low-memory killer daemon (lmkd) steps in, terminating the least-recently-used apps to free up space. In theory, it’s an elegant system. In practice, manufacturers have layered their own memory management on top of it, and the results are often disastrous.
Samsung, Xiaomi, OnePlus, Oppo, Vivo — nearly every major Android OEM ships custom software that aggressively restricts background processes. These aren’t subtle tweaks. According to Android Authority’s reporting, some manufacturers impose hard limits on the number of apps that can remain cached, regardless of how much RAM is available. Others use proprietary algorithms that kill apps based on usage patterns, battery optimization heuristics, or simply how long they’ve been in the background.
The site Don’t Kill My App, a resource created by developers to document manufacturer-specific app-killing behavior, ranks OEMs on a scale from benign to hostile. Samsung, despite being the world’s largest Android phone maker, has historically scored poorly. Chinese manufacturers like Xiaomi and OnePlus have been even more aggressive.
Why would a manufacturer deliberately cripple the multitasking experience on a phone with 16GB of RAM?
Battery life. That’s the short answer.
The longer answer involves a complicated set of incentives. Consumers judge phones partly by how long they last on a charge. Review sites run battery benchmarks. Carriers advertise all-day battery life. And keeping apps alive in RAM, even cached and idle, does consume some power — the RAM itself requires energy to retain data. But the power draw of modern LPDDR5X memory in a low-power state is minimal. The real drain comes from apps that wake up to perform background tasks: syncing data, checking for notifications, updating location. Manufacturers, rather than surgically targeting these wake-ups, have opted for the blunt instrument of killing apps entirely.
It’s the equivalent of demolishing a house to fix a leaky faucet.
Android Authority’s Mishaal Rahman, one of the most respected voices covering Android’s internals, has documented how this behavior varies wildly across devices. A Pixel phone running stock Android will generally respect the operating system’s intended memory management. A Samsung Galaxy phone running One UI may kill the same app within minutes of it entering the background. The experience is inconsistent, unpredictable, and often invisible to the user — who simply sees an app that should have been ready and waiting, but isn’t.
The consequences ripple outward. Fitness tracking apps lose data mid-workout. Navigation apps stop providing turn-by-turn directions when the screen is off. Messaging apps fail to deliver notifications on time. VPN connections drop silently. Security cameras stop streaming. And every time an app is killed and restarted, it consumes more battery than if it had simply been left in memory — the very outcome manufacturers claim to be preventing.
Developers Are Fed Up — And Users Are Paying the Price
For app developers, the situation has become a support nightmare. Users blame the app when their alarm doesn’t fire, when their music stops, when their workout data vanishes. The developer knows the app was killed by the OS. But explaining that to a frustrated user leaving a one-star review is nearly impossible.
Some developers have resorted to extraordinary measures. Apps now include tutorials walking users through the Byzantine process of disabling battery optimization for that specific app — a process that differs on every manufacturer’s skin and sometimes changes between software updates. The Don’t Kill My App website maintains manufacturer-specific instructions, and the fact that such a resource needs to exist at all is an indictment of the status quo.
Google, for its part, has made some efforts to rein in OEM behavior. Android 13 introduced the Foreground Services Task Manager, giving users more visibility into what’s running. Android 14 tightened rules around when apps can start foreground services. But these changes address the developer side of the equation. They don’t prevent manufacturers from killing cached apps that are sitting quietly in memory, doing nothing, consuming negligible resources.
And here’s the fundamental tension: Google controls Android, but it doesn’t control what Samsung or Xiaomi do with it. The Android Compatibility Definition Document (CDD) sets minimum requirements for devices that want to ship with Google Play Services, but it has historically been vague on memory management behavior. Manufacturers have enormous latitude to customize how and when apps are killed.
Recent discussion on developer forums and X (formerly Twitter) suggests frustration is reaching a tipping point. Developers building health and fitness apps — categories where background reliability is literally a safety concern — have been particularly vocal. One recurring theme: apps that work flawlessly on Pixel devices break on Samsung phones, not because of a bug, but because Samsung’s memory management decided the app wasn’t important enough to keep alive.
The irony is thick. Consumers pay premium prices for phones with massive amounts of RAM, partly because they want smooth multitasking. Manufacturers market these RAM figures prominently — 12GB! 16GB! — as selling points. And then the software those same manufacturers install ensures that RAM is never fully used for its intended purpose.
Some of this traces back to an era when Android phones genuinely didn’t have enough memory. Early Android devices shipped with 512MB or 1GB of RAM, and aggressive memory management was a necessity. But the hardware has evolved dramatically while the software philosophy hasn’t. Manufacturers are still optimizing for scarcity on devices drowning in abundance.
There’s also a cultural dimension. Many of the most aggressive OEMs are based in China, where the app environment is different. Without Google Play Services, Chinese Android apps often use more aggressive background techniques to deliver notifications and updates, because they can’t rely on Google’s Firebase Cloud Messaging. Manufacturers developed heavy-handed memory management partly in response to this wilder app environment. But those same restrictions ship on international variants of phones, where apps behave differently and the restrictions cause more harm than good.
What Would a Fix Actually Look Like?
The path forward isn’t mysterious. It’s just difficult politically.
Google could tighten the CDD to mandate specific memory management behaviors — minimum cached app counts, maximum kill rates, standardized exemption mechanisms. This would limit OEM customization, which manufacturers would resist. But it would create a more consistent, reliable experience for users and developers alike.
Manufacturers could also simply trust the system Google built. Stock Android’s memory management, as implemented on Pixel phones, works well. It keeps apps cached when memory is available, kills them when it isn’t, and does so with reasonable intelligence. The OEM additions on top of this system are, in most cases, making things worse, not better.
Another approach: transparency. If a phone is going to kill a background app, it should tell the user why and offer a simple way to prevent it. Right now, the process is invisible. Apps just die. Users just suffer. Nobody knows why unless they’re willing to dig through developer options and ADB logs.
Samsung has shown some willingness to adjust. Recent One UI updates have loosened some restrictions compared to earlier versions. But the improvements have been incremental, and the default behavior still leans aggressive. A user who buys a new Galaxy phone and doesn’t manually adjust battery optimization settings for every app they care about will still experience unnecessary app kills.
So where does this leave the average Android user in 2025? Stuck in an absurd situation. Carrying a pocket computer with more RAM than most laptops had a decade ago, watching apps reload from scratch because the software decided — incorrectly — that keeping them in memory wasn’t worth the trouble.
The RAM is there. The hardware is capable. The bottleneck is a set of software decisions made by companies optimizing for benchmark numbers and worst-case scenarios rather than real-world user experience. And until Google or the OEMs decide to change course, Android’s multitasking promise will remain half-fulfilled — a spec sheet achievement that the software itself refuses to honor.
For those of us who’ve watched Android evolve from its scrappy early days on the T-Mobile G1, it’s a frustrating regression. The phones have never been more powerful. The experience of using them shouldn’t feel like it’s going backward.
WebProNews is an iEntry Publication