Android app memory limits are now a Google Play publishing condition, and the reason sits in a data centre rather than in your codebase. On 27 August 2026 Google published two new app quality requirements, and the first of them tells developers that from February 2027 an app that uses too much RAM will lose visibility on the Play Store. The justification Google gives is blunt: the mobile industry faces “significant hardware supply constraints that are altering device memory availability.”
That is a polite description of a memory market that has been drained by AI. Every wafer that goes into a high-bandwidth memory stack for an accelerator is a wafer that does not become an LPDDR5X module for a mid-range handset, and the price of consumer DRAM has moved accordingly. The consequence lands on the one group that never bought a GPU: the people shipping ordinary apps to ordinary phones. Our companion piece on AI in mobile phones covered what on-device models do; this one covers what they cost everyone else.
This breakdown covers exactly what Google announced and when it bites, the published per-tier Android app memory limit thresholds for apps and for games, the Android 17 Memory Limiter that enforces the same idea at the kernel level, what tends to break first, the awkward contradiction between a 12 GB on-device AI requirement and shrinking budget-phone RAM, and the work to schedule before the deadline. Every figure below is traceable to a document in the References section.
Table of contents
- Android App Memory Limit Rules: What Google Just Announced
- Why the AI Memory Crunch Reached Your Phone
- Inside the Android App Memory Limit Thresholds
- How the Memory Limiter Enforces the Android App Memory Limit
- What Breaks First Under an Android App Memory Limit
- The On-Device AI Contradiction: 12 GB Phones, 4 GB Budgets
- How to Prepare for the Android App Memory Limit Deadline
- What This Means for Product and Engineering Teams
- Frequently Asked Questions About the Android App Memory Limit
- References
Android App Memory Limit Rules: What Google Just Announced
Google Play’s quality bar has always covered crashes, ANRs and battery. Memory has now joined it, and the Android app memory limit is the first of the two new requirements to take effect.
The two requirements and their dates
The first requirement is the Android app memory limit proper — reduced memory usage and minimum code optimisation, enforced from February 2027. It measures three things: dynamic memory usage, expressed as anonymous resident set size plus swap; bitmap memory usage; and DEX code optimisation coverage. The second requirement is Zero-Tap Sign-In restoration, enforced from April 2027, which asks any app with a sign-in to restore that session automatically when a user moves to a new device.
What Google actually said about supply
The wording in the announcement is the interesting part. Google frames the Android app memory limit as a response to “significant hardware supply constraints that are altering device memory availability,” and singles out low-cost devices as the place where memory availability is tightest. Play requirements are normally justified by user experience alone. This one is justified by the supply chain, which is a first.
What non-compliance costs you
An app that misses the threshold is not banned. Google’s language is “reduced app visibility and publishing capabilities on Google Play” — the app ranks worse, is surfaced less, and may be blocked from shipping updates. Compliance is assessed on rolling 28-day windows of field data, not on a lab run, so an Android app memory limit failure is a slow-moving statistic rather than a single bad build.
| Requirement | Enforced from | What it measures | Applies to |
|---|---|---|---|
| Dynamic memory usage | February 2027 | Anonymous RSS + swap, 90th percentile, per process state | Apps and games, mobile and tablet |
| Bitmap memory usage | February 2027 | Bitmaps retained in service, background and cached states | Apps and games, mobile and tablet |
| DEX code optimisation | February 2027 | 25% coverage across optimisation, shrinking and obfuscation | All form factors, above a DEX size floor |
| Zero-Tap Sign-In restoration | April 2027 | Restore Credentials API on device-to-device transfer | Apps with sign-in; games exempt for now |
Why the AI Memory Crunch Reached Your Phone
The Android app memory limit is a platform response to a commodity shortage, so the shortage is worth understanding on its own terms.
High-bandwidth memory is eating the wafers
IDC’s framing is the clearest one published: “every wafer allocated to an HBM stack for an Nvidia GPU is a wafer denied to the LPDDR5X module of a mid-range smartphone or the SSD of a consumer laptop.” This is a reallocation of fab capacity, not a factory fire. IDC expects 2026 supply growth of roughly 16% for DRAM and 17% for NAND, both below historical norms, against demand that is not behaving normally at all.
What that does to a bill of materials
J.P. Morgan Global Research estimates DRAM prices will rise more than 400% between the start of 2024 and the end of 2026. IDC puts memory at 15–20% of a mid-range device’s cost and 10–15% of a flagship’s. When the largest single line item in that bracket quadruples, something has to give — and on a price-sensitive handset, the thing that gives is the RAM specification.
Why Google had to act at the platform level
If the installed base is about to stop gaining memory, and in the budget tier may lose some, then the platform has two options: let apps fight over a shrinking pool, or set a per-app ceiling. Google chose the ceiling. That is what an Android app memory limit is — an admission that the hardware will not bail software out this time. The macro effect is real too: J.P. Morgan estimates every 10% rise in hardware costs lifts core inflation by around 0.1%, with 0.2–0.4% of the current lift attributed to the memory shock alone.
| Published figure | Value | Source |
|---|---|---|
| DRAM price change, start 2024 to end 2026 | More than +400% | J.P. Morgan Global Research |
| 2026 DRAM supply growth | About 16% | IDC |
| 2026 NAND supply growth | About 17% | IDC |
| Memory share of mid-range device cost | 15–20% | IDC |
| Memory share of flagship device cost | 10–15% | IDC |
| Smartphone volume risk, 2026 | −2.9% moderate, −5.2% pessimistic | IDC |
| Smartphone average selling price rise | +3–5% moderate, +6–8% pessimistic | IDC |
| Import price index, computers and parts | +37% since end 2024 | J.P. Morgan Global Research |
Inside the Android App Memory Limit Thresholds
Google published the actual numbers, which is more than most policy changes offer. Every Android app memory limit below is a 90th-percentile field measurement, tailored to two variables: whether you ship an app or a game, and how much physical RAM the device has.
The Android app memory limit for apps, tier by tier
For apps, the Android app memory limit in the foreground runs from 2 GB on a 4 GB device to 4.25 GB on a 16 GB device. The background and user-perceived-service allowances are far tighter — 1 GB on a 4 GB handset, rising only to 2 GB on a 16 GB one. The asymmetry is deliberate. Google is not trying to stop your app being large while the user is looking at it; it is trying to stop your app being large when they are not.
The game Android app memory limit and why it is higher
Games get a more relaxed Android app memory limit because a game’s working set genuinely cannot be paged away between frames. On a 4 GB device a game may hold 2.25 GB in the foreground against an app’s 2 GB, and 2 GB in the background against an app’s 1 GB. The widest gap is at the 8 GB tier, where a game is allowed 3.5 GB in the foreground and an app only 2.25 GB.
Bitmaps and DEX optimisation
Two secondary thresholds sit alongside the main Android app memory limit. Bitmap memory must stay under 200 MB in user-perceived-service and background states, and under 400 MB when cached — a rule aimed squarely at image caches that never release. DEX code optimisation demands a minimum of 25% coverage across optimisation, shrinking and obfuscation, applying to apps with more than 10 MB of DEX and games with more than 50 MB.
| Device RAM | App foreground | App service / background | Game foreground | Game service / background |
|---|---|---|---|---|
| 4 GB | 2 GB | 1 GB | 2.25 GB | 2 GB |
| 6 GB | 2.25 GB | 1.25 GB | 2.75 GB | 2.5 GB |
| 8 GB | 2.25 GB | 1.5 GB | 3.5 GB | 2.75 GB |
| 12 GB | 3.25 GB | 1.75 GB | 4 GB | 3.2 GB |
| 16 GB | 4.25 GB | 2 GB | 5 GB | 3.5 GB |
How the Memory Limiter Enforces the Android App Memory Limit
The Play requirement is a distribution consequence. The kernel-level Android app memory limit is separate, older, and already running: the Memory Limiter, introduced in Android 17 on Pixel devices.
cgroup v2, memory.high and memory.swap.max
The Memory Limiter is a system service that monitors and limits app process memory using Linux cgroup v2. It sets two controls per process: memory.high, a soft limit that triggers throttling and proactive page reclaim, and memory.swap.max, which caps how much compressed swap that process may consume. It watches processes with a UID of 10000 or above and exempts core system processes. There are no allowlists, so no app negotiates its way out of the Android app memory limit.
The platform Android app memory limit tier table
Android ships standard limits in /system/etc/memory-limiter-config.xml, keyed to physical RAM ranges. Visible processes — those in TOP, BOUND_TOP, IMPORTANT_FOREGROUND or TOP_SLEEPING states — get roughly half to two-thirds of physical RAM. Not-visible processes, which covers foreground services, bound services, receivers and backups, get roughly a quarter to a third. Cached processes are frozen and reclaimed as aggressively as the kernel can manage.
Throttle first, terminate second
Android app memory limit enforcement is progressive rather than instant. Cross the soft limit and the kernel evicts clean file-backed pages and pushes inactive anonymous pages into zRAM; compressing and decompressing them costs CPU, which the user experiences as jank and slow scrolling. Keep growing and the process is killed. The kill is attributable: ApplicationExitInfo.getDescription() returns MemoryLimiter:AnonSwap, so an Android app memory limit termination is distinguishable from an ordinary low-memory kill in your crash reporting.
| Physical RAM | MemTotal range (MiB) | Visible memory | Not-visible memory | Swap, each state |
|---|---|---|---|---|
| 4 GB | 3200–4800 | 2,048 MiB | 1,024 MiB | 1,024 MiB |
| 6 GB | 4800–6800 | 4,096 MiB | 2,048 MiB | 2,048 MiB |
| 8 GB | 6800–9216 | 5,120 MiB | 3,072 MiB | 3,072 MiB |
| 12 GB | 9216–14336 | 8,192 MiB | 4,096 MiB | 4,096 MiB |
| 16 GB | 14336–18432 | 10,240 MiB | 5,120 MiB | 5,120 MiB |
What Breaks First Under an Android App Memory Limit
Most teams will not fail the Android app memory limit because of one enormous allocation. They will fail it because of three unglamorous patterns that have been tolerated for a decade.
Image-heavy feeds and bitmap caches
The 200 MB bitmap ceiling in background and service states is the sharpest edge in the whole policy. A scrolling feed that decodes full-resolution images and keeps a generous in-memory cache will sail past it the moment the user switches away. Decoding at display resolution rather than source resolution, and trimming the cache on onTrimMemory, is the single highest-value change most teams can make before the Android app memory limit deadline.
Background services that never shrink
The background and service halves of the Android app memory limit are the tightest numbers Google published — 1 GB on a 4 GB handset. Any service that loads a working set for one job and then holds it for the life of the process is a direct threat. This is also where the Memory Limiter’s kill lands most often, because a background process is exactly what the kernel is most willing to sacrifice.
The dependencies you did not write
A third of a typical app’s resident memory is frequently owned by code the team did not author: analytics SDKs, ad mediation, a WebView, a bundled map or media engine. The Android app memory limit applies to the process, not to the code you are proud of. Auditing third-party memory behaviour belongs in the same sprint as your own, and it is often the harder negotiation, because the fix lives in someone else’s release schedule.
Everything the platform will not tell you
One constraint deserves flagging: apps cannot query their assigned budget at runtime. There is no API that returns “you have 2.25 GB on this device.” You measure in the field, compare against the published table, and infer. That makes Android vitals and your crash reporter the only honest instruments you have.
The On-Device AI Contradiction: 12 GB Phones, 4 GB Budgets
Here is where the story becomes genuinely awkward for Google, and where the phrase “AI memory crunch” earns its keep.
Gemini Intelligence wants 12 GB
Google’s own on-device AI tier is not modest. Gemini Intelligence requires 12 GB or more of RAM, a flagship-class chip, AICore support, Gemini Nano v3 or newer, and a vendor commitment to five Android OS upgrades and six years of security updates. The bar is high enough that the Pixel 9 series and the Galaxy Z Fold 7 — 2025 flagships — do not qualify, because they carry Gemini Nano v2.
Budget phones are going the other way
At the same time, memory is the fastest-inflating component in a budget handset. The realistic outcome across 2026 and 2027 is a widening gap: flagships holding or gaining RAM to run local models that handle summarisation, rewriting and other natural language processing work on the device, and the cheap tier standing still or stepping back. One platform, two hardware realities, and a single Android app memory limit table that has to serve both.
Where that leaves an app shipping its own model
If your roadmap includes bundling a small local model, the arithmetic just changed. A quantised model that occupies 700 MB of resident memory consumes 35% of a 4 GB device’s entire foreground allowance before your UI draws a pixel. Teams building artificial intelligence and machine learning features into mobile products should now treat memory budget as a first-class design constraint alongside latency and accuracy — and our AI models and tools hub tracks which models are small enough to be candidates.
How to Prepare for the Android App Memory Limit Deadline
February 2027 sounds distant. It is roughly five months of engineering capacity once you subtract release trains, holidays and the work already committed.
Measure your Android app memory limit headroom first
Android vitals now reports memory usage across process states and RAM classes, and warns you directly on the overview page when your app crosses a bad-behaviour threshold. Firebase Crashlytics 20.1.0 and later tracks out-of-memory exceptions and Memory Limiter kills. The ProfilingManager API collects heap dumps from production devices on a trigger. Between them you can establish where you sit against the Android app memory limit without guessing.
The optimisation work that actually pays
Three items dominate the return. Enable app optimisation in your release build to satisfy the 25% DEX coverage requirement — it is a build configuration change, not a refactor. Fix bitmap retention, because it is the threshold most commonly exceeded. Then make the background path genuinely release what it allocates. Everything else is smaller.
Test against the Android app memory limit directly
You do not have to wait for field data. Android 17 exposes am memory-limiter from the shell, with status reporting the active limits and monitoring metrics, ignore temporarily excluding a UID, and manual overriding a specific process’s budget for test purposes. Wiring that into an automated device-lab run is the closest thing to a pre-flight check for the Android app memory limit that currently exists, and it belongs in the same DevOps pipeline as your other release gates.
Do not forget the April requirement
Zero-Tap Sign-In restoration is the quieter of the two changes and the one most likely to be missed. From April 2027 an app with a sign-in must restore that session automatically when the user moves to a new device, using the Android Restore Credentials API. Block Store integrations completed by 30 September 2026 are exempt, as are permanently private apps, enterprise device management apps, and games for now.
| Work item | Effort | Threshold it addresses |
|---|---|---|
| Enable app optimisation in the release build | Low, build configuration | 25% DEX optimisation, shrinking, obfuscation |
| Decode images at display resolution | Medium | 200 MB bitmap ceiling |
| Trim caches on onTrimMemory | Low to medium | Bitmap and background thresholds |
| Release working sets in background services | Medium to high | Background anonymous RSS + swap |
| Audit third-party SDK memory behaviour | High, external dependency | Whole-process dynamic memory |
| Adopt Restore Credentials API | Medium | Zero-Tap Sign-In, April 2027 |
What This Means for Product and Engineering Teams
The technical work is well defined. The planning decisions around it are less obvious and matter more.
The Android app memory limit is now a distribution risk
Until now, a memory regression cost you reviews and retention. From February 2027 it costs you reach. That moves the Android app memory limit out of the engineering backlog and into the same category as a policy violation — something a product owner has to hold a date for, not something a platform team fixes when there is room.
Budget the work in this planning cycle
An audit, a bitmap fix, a background-service fix and an SDK negotiation is not a two-week job on a mature codebase. Teams running a lean MVP development process have an advantage here: fewer dependencies, less accumulated cache logic, and a smaller DEX to optimise. Teams with a decade-old app should scope this now rather than in December.
Ask your vendors before they ask you
Every SDK you embed will need to answer the same question, and the vendors who cannot will become a liability on your compliance record rather than theirs. If you work with an external Android app development team, put the February 2027 Android app memory limit thresholds into the next statement of work explicitly, with the published per-tier numbers attached.
Frequently Asked Questions About the Android App Memory Limit
Will my app be removed from Google Play if it exceeds the threshold?
No. Google’s stated consequence is reduced visibility and reduced publishing capability, not removal. In practice that means worse ranking and surfacing, and potentially being blocked from shipping an update until the Android app memory limit is met again.
Which Android versions does the Memory Limiter run on?
The per-app Memory Limiter was introduced in Android 17, starting on Pixel devices. Google says an increasing number of manufacturers will adopt it over the coming year across RAM configurations from 4 GB to 16 GB and above. The Play requirement, by contrast, is measured from field data across your whole install base.
How is the Android app memory limit actually measured?
It is the 90th percentile of anonymous resident set size plus swap for your process, segmented by process state and by the device’s RAM tier, over a rolling 28-day window. A single heavy session will not fail you; a consistent pattern across a tenth of your sessions will.
Do games really get an easier Android app memory limit?
Yes, and the gap is largest at the 8 GB tier, where a game may use 3.5 GB in the foreground against an app’s 2.25 GB. Google’s stated reasoning is that games need more RAM to function properly. Classification follows your Play Console category, so it is not something you opt into.
Can I detect a Memory Limiter kill in production?
Yes. ApplicationExitInfo.getDescription() returns MemoryLimiter:AnonSwap for a termination caused by exceeding the swap budget, and Firebase Crashlytics 20.1.0 and later surfaces these alongside out-of-memory exceptions.
Does an app get told what its budget is?
No. The Memory Limiter does not expose a per-app budget at runtime and does not support allowlists, so no app can query or negotiate its Android app memory limit. You compare field measurements against the published tier table instead.
Is this shortage going to end before the deadline?
Nothing in the published forecasts suggests so. IDC expects below-trend supply growth through 2026 and J.P. Morgan’s analysts describe an industry that will “stay in shortage for multiple years”, so plan on the constraint outlasting the February 2027 enforcement date.
References
AI’s Memory Crunch Is Coming for Android Apps — TechCrunch
Preparing Your App for Broader Memory Limits — Android Developers Blog
Prioritizing Memory Efficiency: Essential Steps for Android 17 — Android Developers Blog
Play Console Technical Quality Requirements — Play Console Help
Memory Limiter — Android Open Source Project
Behavior Changes: All Apps, Android 17 — Android Developers
Overview of Memory Management — Android Developers
Enable App Optimization — Android Developers
Restore Credentials — Android Developers
Google’s Tough Stance on App Memory Limits Is Coming in February — Android Authority
Global Memory Shortage Crisis: Market Analysis — IDC
The AI-Driven Memory Shortage: DRAM Prices, Inflation and Market Risks — J.P. Morgan
Gemini Intelligence Android Spec Requirements — 9to5Google
More AI coverage: explore Progressive Robot's AI Models, Tools & Releases hub — hands-on reviews, setup guides and benchmarks in one place.