Product1 distinct publisher3 min readPublished
The limits scale with device RAM and land on Pixel first with Android 17. The part that will get attention in planning meetings is the threat to Play Store visibility, which turns memory profiling into release work.
The Product Desk · Product desk
Compiled by The Product DeskSomething wrong?How this is made
The person who has to deal with this opens the memory profiler for the first time since the last out-of-memory bug, on a loaner handset with 8GB of RAM, and finds the image cache and the embedded webview already sitting somewhere north of 2GB. Nothing is broken. The app ships. It also sits inside a couple of hundred megabytes of the foreground ceiling Google has set for that device, which is 2.25GB [5]. Work that out against the nominal RAM and the app is allowed roughly 28 percent of the phone while it is on screen [20].
The measurement choice does most of the work. Google counts Anonymous Resident Set Size plus Swap, which is the memory an app holds that no file backs [6]. Mapped code from the APK does not count against you. Decoded bitmaps do, the heap inside an embedded browser does, and so does anything you deliberately kept in memory to make a scroll feel smooth. TNW's read is that these numbers are not generous on a mid-range handset, and that an app with a large image cache and an embedded browser can approach them without doing anything unusual [22]. Bitmaps also carry a separate cap that applies on every device regardless of how much RAM it has [7].
What teams usually tell themselves is that memory is a performance concern, owned by whoever watches the crash dashboard, and deferrable when a release is tight. Google's wording removes the deferral. Apps below the thresholds "may see reduced app visibility and publishing capabilities on Google Play" [10], on top of the documented outcome that an app over the line "will be slowed down and may be terminated" [9].
The justification and the cause sit awkwardly next to each other. Google's own documentation says an ecosystem-wide memory crisis is imminent because of rising RAM costs [4], and in June the same programme was described as preventing one bad actor from destroying the multitasking experience and stability of a user's entire device [13]. That failure mode is real on a 4GB phone. It is also true, as TNW puts it, that developers now carry the cost of a shortage that data centre buyers created [21], with Nvidia AI server prices rising more than 15% from early next year on memory costs [14] and the base Pixel 11 Pro shipping with less memory than last year's model [16].
Two questions sort the work. Does your app hold large amounts of non-file-backed memory at peak, meaning decoded bitmaps and an embedded browser, plus any on-device model [18]. And what share of your installs sit on devices with 8GB or less. Both yes: the number to instrument is the p99 of anonymous RSS plus swap on your lowest device tier, measured per app state, because foreground and background carry separate ceilings [5]. First only: the bitmap cap still reaches you on flagship hardware [7]. Second only: confirm it with a profiler reading rather than an assumption. Neither: the DEX optimisation requirement is still on the list, and it is the cheapest of the three [8].
Ranked by verification strength, evidence, and original report placement.
From February 2027, an Android app that exceeds Google's new memory limits risks two penalties: Android can slow it down or shut it, and the Play Store can bury it.
Google published the memory requirements this week on its Android Developers Blog; TechCrunch spotted them first.
Google's technical documentation states that "An ecosystem-wide memory crisis is imminent due to rising RAM costs", a line first noted by The Register.
On a phone with 8GB of RAM, an app can use no more than 2.25GB in the foreground, 1.5GB for user-perceived services and 1.5GB in the background; devices with more than 16GB are mostly exempt.
Google measures the main figure as Anonymous Resident Set Size plus Swap, which is the memory an app holds that no file backs.
Bitmap memory has its own cap that applies to every device: 200MB in user-perceived services and in the background, and 400MB cached. The limits differ somewhat for games.
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 31, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
product
Google's new Preferred Sources button hands publishers the recruiting job2 distinct publishers
product
Google narrowed the Pixel 11 Pro to a display upgrade and a notification LED1 distinct publisher
product
Pixel 11: a flatter camera bar, seven grams, and a software lockout1 distinct publisher
product
Pixel 11 verdict: "could have been a software update," and fleet buyers should read it that way2 distinct publishers
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Google's own words, one desk's telling
The thresholds, the throttling language and the Play visibility warning are lifted straight from Google's developer blog and documentation, which is about as authoritative as a policy claim gets. What is absent is a second reader: the TechCrunch discovery, The Register's "memory crisis is imminent" line and The Verge's Pixel 11 memory observation all arrive through The Next Web's account, and nothing here has been checked against those pages independently.
Live on Pixel, enforced nowhere
Android 17 on Pixel is the only place these limits actually run. Everything else is calendar: other manufacturers "over the coming year" in Google's phrasing, enforcement in February 2027, the size of the store penalty "later this year". No count of apps over the line, no OEM confirming adoption, no developer reporting what profiling turned up.
Sharpened by the sanction nobody has defined
The reporting runs cooler than the subject: limits are quoted before they are argued about. The tilt comes from the hook. Being buried in Play search is what makes this urgent, and it is precisely the part Google refuses to quantify, so the threat does the dramatic work while the specifics stay blank. Add eighteen months of runway and the gap between the alarm and the observable situation is real but narrow.
The referee also sells the phone
Google occupies every position in this transaction at once: it writes the rule, owns the store that enforces it, builds handsets whose RAM it has just trimmed while raising prices, and asks the same developers to load Gemini Nano into the memory it is now rationing. A rule that shifts the cost of scarce DRAM onto third-party engineering teams is convenient for whoever is buying less of it. The Next Web has a smaller stake of its own: the data-centres-versus-developers line extends an argument it has been making since May.
Firm on text, thin on breadth
Verbatim quotation from a named vendor document carries this a long way; a single outlet and two deadlines that have not arrived hold it back. If Google publishes the visibility penalty it promised, or any other newsroom reproduces the same thresholds, this firms up fast — and the low-end handset consequences would then be measurable rather than argued.