Android 17: Use Too Much Memory, Your App Gets Killed

Android 17: Use Too Much Memory, Your App Gets Killed

---

ANDROID · MOBILE DEV August 2026

A phone can have 16GB of memory to spare, and Android can still shut your app down for using too much of it. On August 19, 2026, Google said it will take the per-app memory limit that started on Pixel phones and roll it out to phones from other companies. The limit will cover phones with as little as 4GB of memory, all the way up to 16GB and more. Instead of just cleaning up memory after the whole phone runs low, the new system watches each app on its own, slows it down first, and then kills it if it keeps using too much.

1From Pixel to Every Android Phone

2Slow Down First, Then Shut Down

3Watch the Worst Case, Not the Average

4What Google Still Hasn't Told Us

1 From Pixel to Every Android Phone

So does this mean every Android phone will suddenly start killing apps? Not quite — and that's the part worth slowing down for.

This rule lives inside Android 17 (API level 37), and it decides how much memory an app can use based on the phone's total RAM (the phone's short-term memory, used while apps are running). Google says it applies to every app running on Android 17, no matter which Android version the app itself was built for.

But Google's own page only says the limit applies to "some Android devices." The August 19 announcement did not name which phone makers, which models, or exactly when the rollout starts. It only promised that more phone makers will join over the next year.

Don't assume this is switched on for every Android 17 phone already. A big memory number printed on a phone's spec sheet doesn't mean an app is safe, either — the limit is set per app, based on total RAM, and the exact numbers have not been made public yet.

 

2 Slow Down First, Then Shut Down

What actually happens the moment an app crosses its limit? It doesn't just get killed right away — it gets punished first.

Once an app hits its memory budget, the system pushes its data into zRAM. The phone's processor has to squeeze it in and then unsqueeze it every time the app needs it, which uses up processing power.

EASY WAY TO THINK ABOUT IT

Imagine your backpack is full, so you start squeezing your clothes into vacuum bags to fit more in. It works, but every time you need something, you have to unzip the bag and let the air back in first. That's what zRAM does to your app's data — and that squeezing and unsquozing is why the app feels slow.

If the app keeps using more memory even after that, Android kills the process. Here's the twist: Google says this kind of shutdown does not leave behind a normal stack trace (the usual error trail developers check when an app crashes). If a developer only checks crash logs, this kind of death disappears without a trace.

POINT

To a user, it just looks like the app got laggy and then closed. To a developer checking crash reports afterward, there may be nothing there at all — the app simply vanished from the logs.

This is different from Android's older memory rule, the Low Memory Killer Daemon (lmkd), which only steps in once the whole phone is running low and kills the least important background apps first. The new per-app limit acts earlier, on a single greedy app, before the whole phone is affected.

 

3 Watch the Worst Case, Not the Average

If most users never hit the limit, how is a developer supposed to catch the few who do?

Google Play Console lets developers check a number called Anonymous RSS + swap — basically, how much memory an app's process is really holding onto. Developers can look at this by two levels: P50 (a typical, middle-of-the-pack session) and P90 (a worse-than-90%-of-sessions case).

When the P90 number gets far past the P50 number, that's a warning sign

P50 (typical session)1×

 

P90 (worst 10% of sessions)3.5×

 

Google says once P90 is more than 3.5 times P50, that's worth checking as a possible memory leak (a bug where an app quietly keeps grabbing memory and never lets go, like a leaky faucet you forgot to close). A high number alone doesn't prove a leak — sometimes a few users just handle a lot of data. But it tells developers exactly where to look.

There are also tools to catch the moment of death itself. ApplicationExitInfo.getDescription() can reveal a marker that flags a memory-limit shutdown, and a system called ProfilingManager can grab a snapshot of memory the instant the limit is hit — giving developers a trail even when the usual stack trace is missing.

📖 QUICK TERM GUIDE

zRAM

A way to squeeze more data into memory by compressing it — like stuffing more clothes in a suitcase by using vacuum bags.

RSS (Anonymous RSS + swap)

A measurement of how much real memory an app's process is holding onto right now.

lmkd

Android's older, phone-wide memory watchdog — it only acts once the entire phone is running low, not one app.

 

4 What Google Still Hasn't Told Us

So what's actually missing before developers can plan around this with confidence?

Google confirmed the memory range — 4GB up to 16GB and beyond — and promised more phone makers will adopt it within a year. But which company, which model, and on what exact date, remains unannounced. The precise memory budget for each RAM class, and whether visible and invisible apps get different limits, also hasn't been published.

There's also no official confirmation that Anonymous RSS + swap is the only number used to decide the limit, or the exact rule for when an app moves from zRAM to being killed outright. Until Google publishes real numbers, guessing at thresholds is a waste of time — testing real devices as the rollout expands is the safer bet.

A Memory Limit That's Coming — But Still Half-Explained

1Google will bring Pixel's per-app memory limit to phones from 4GB up to 16GB+ of RAM over the next year.

2Apps get slowed down through zRAM first, then killed — and that death can vanish from normal crash logs.

3Which phones, which numbers, and when — Google hasn't said. Would your app survive if the limit landed on your users' phones tomorrow?