Android Memory Limits: Play Store Will Penalize Apps in 2027

In August 2026, Google Play announced a new memory quality requirement for apps, clarifying the Android app memory limits Play Store 2027 penalty timeline: starting in February 2027, apps that exceed thresholds set by device RAM class may face reduced visibility and publishing restrictions on Play Store. In this article, you'll walk step by step through which thresholds apply, how they differ from Android 17's device-level MemoryLimiter, and how to prepare your app before February 2027.

💡 Pro Tip: Memory metrics have been accessible since the August 2026 announcement: under the Memory heading in the Android vitals overview, and via the Google Play Developer Reporting API. The four months from October 2026 to February 2027 amount to four consecutive full 28-day P90 windows — waiting for February without using those windows is risky.

Table of Contents

• Policy summary and the February 2027 timeline
• RAM thresholds by device class
• Relationship with Android 17 MemoryLimiter (OS vs. store)
• Measuring real memory usage
• Most common sources of memory bloat
• The measure-fix-verify cycle
• Setting up a memory regression gate in CI
• Roadmap: from October 2026 to February 2027
• FAQ
• What is the Play Store memory limit, and when does it take effect?
• How do I measure my app's RAM usage?
• What happens on Play Store if I exceed the memory threshold?
• Is Android 17 MemoryLimiter the same thing as Play policy?
• How do I meet the DEX code optimization requirement?
• Are the thresholds different for games?
• Conclusion
• Sources

Policy summary and the February 2027 timeline

In its official announcement dated August 26, 2026, Google Play defined two new quality requirements: "reducing memory footprint" and "secure device migration." The announcement states: "Google Play is introducing two new quality requirements: one focused on reducing app memory footprint, and another on providing a secure, seamless device migration experience." This article covers only the memory side; device migration is a separate topic.

The requirement is tied to a single date: "Starting in February 2027, apps and games must meet their respective bad behavior thresholds for Memory usage (Anonymous RSS + Swap), Bitmap memory usage and DEX code optimization." In other words, three separate metrics kick in at the same time — Anonymous RSS + Swap (dynamic memory usage), bitmap memory, and DEX code optimization.

The consequence for apps that exceed the thresholds is clearly defined: "Apps and games that do not meet these thresholds may see reduced app visibility and publishing capabilities on Google Play." This isn't an instant suspension — it's a risk of gradual visibility and publishing restrictions. There are roughly four months from October 2026 to February 2027, which in practice fits into a single minor release cycle, so you need to start measuring now.

Scope varies per metric: the memory thresholds only apply to the mobile and tablet form factor ("This requirement only applies to mobile and tablet form factors."), while the DEX requirement covers all form factors ("This requirement applies across all form factors."). A Wear OS or Android TV app falls outside the memory thresholds but isn't exempt from DEX.

Since these three metrics (Anonymous RSS + Swap, bitmap memory, DEX optimization) are part of the same requirement package, treat them as a whole, not one at a time. A team that only enables DEX optimization (R8) while neglecting bitmap management may still fail the other two metrics even after passing one — the announcement counts the three thresholds separately. That's why the next section covers thresholds first, then measurement and fix steps.

RAM thresholds by device class

Google set tiered thresholds based on a device's total RAM, and evaluates them using the 90th percentile (P90) of the last 28 days of user data: "Play uses the last 28 days of data to evaluate your app's quality… the 90th percentile, which is used to evaluate your app's performance against the bad behavior thresholds." In other words, a single bad session doesn't affect you — nine out of ten of your users' experiences need to stay under the threshold.

The official threshold table for apps (P90 values) is as follows:

Note: the official source table has a fifth column (Cached); for apps, every row in that column has no threshold ("-"), so it isn't carried into the table above.

Only two edges in the table have no threshold ("-"): devices with total memory below 3200 MB and above 18432 MB. This means most phones labeled "16 GB" (the 14336-18432 MB band) aren't exempt — they're subject to the 4.25 GB foreground threshold. The 6GB and 8GB tiers share the same foreground value, but their background thresholds diverge.

Thresholds for games are set more loosely than for apps: in the 8GB class, games have a foreground threshold of 3.5GB, versus 2.25GB for apps.

This gap reflects Google's acknowledgment that game engines naturally use memory more intensively — but it's not an exemption, just a higher ceiling.

In practice, this table tells you two things. First, you can't prioritize optimization without knowing your audience's RAM distribution — you can review the memory metrics in Android vitals broken down by percentile and RAM bucket, and that breakdown should be read alongside this table. Second, since the threshold is "a ceiling that varies by device class" rather than a fixed number, you need device-class-based test scenarios instead of one global target — testing only on a high-end emulator in CI could make you miss the tighter 4GB-class threshold.

Relationship with Android 17 MemoryLimiter (OS vs. store)

It's critical not to conflate two different mechanisms here. In Android 17, Google introduced a "per-app memory limit" mechanism starting with Pixel devices: "In Android 17, we introduced per-app memory limits, starting with Pixel devices… If your app exceeds these limits, it will be slowed down and may be terminated." This is a real-time mechanism that runs at the operating system level.

MemoryLimiter works in two stages. First, compression: "zRAM Swapping: If your app reaches its allocated limit, the system forces your app's pages into zRAM." Then, termination: "Process Termination: If your app continues to increase its memory usage beyond the zRAM threshold, it will be terminated by the system." In other words, an app that exceeds the limit slows down first (zRAM compression/decompression carries a CPU cost), and if it keeps going, the system shuts it down.

Play Store's February 2027 thresholds are an entirely different layer: an audit at the store policy level, based on the last 28 days of aggregated, anonymized data. One (MemoryLimiter) governs an instantaneous behavior of your app on-device; the other (Play policy) affects your long-term visibility in the store. Even if an app is never terminated by MemoryLimiter, it can still face a Play Store penalty if it exceeds the P90 threshold — and the reverse is also possible. You can find other effects of these two layers in our article covering Android 17 (API 37) behavior changes in a broader context.

In practical terms: MemoryLimiter is outside your control — the OS's own decision. You can only observe how close your app is to the limit; you can't disable it directly. Play Store policy, by contrast, is a metric target you can directly influence — keeping P90 under the threshold via code optimization, resource management, and memory hygiene is entirely up to you. So it makes sense to prioritize the latter in your roadmap: treat MemoryLimiter as an early-warning signal and the Play policy as the actual target.

Measuring real memory usage

You should start measuring on-device. The adb shell dumpsys meminfo <package-name> command gives you your app's PSS (proportional set size) distribution live:

1adb shell dumpsys meminfo com.example.app
2 
3** MEMINFO in pid 8421 [com.example.app] **
4                   Pss  Private  Private  SwapPss     Heap     Heap     Heap
5                 Total    Dirty    Clean    Dirty     Size    Alloc     Free
6                ------   ------   ------   ------   ------   ------   ------
7  Native Heap    41208    41156        0    18344    53248    46870     6377
8  Dalvik Heap    12480    12384        0     3120    18432    14210     4222
9        Stack     1024      988        0        0
10       Ashmem      312       48        0        0
11     Gfx dev     9840     9840        0        0
12      Unknown     6112     4980      132     1408
13        TOTAL    70976    69396      132    22872

The SwapPss column in this output is directly tied to Android 17's zRAM compression — as the number grows, your app is getting closer to MemoryLimiter's first stage (compression).

The second tool is ApplicationExitInfo, for understanding why your app was terminated. According to Google's announcement, for a process shut down by MemoryLimiter, the exit reason is reported as follows: "the exit reason is reported as REASON_OTHER and the description string will contain 'MemoryLimiter:AnonSwap'."

1val exitInfos = activityManager.getHistoricalProcessExitReasons(
2    packageName, 0, 10
3)
4exitInfos.forEach { info ->
5    if (info.reason == ApplicationExitInfo.REASON_OTHER &&
6        info.description?.contains("MemoryLimiter:AnonSwap") == true) {
7        // Terminated because MemoryLimiter exceeded the zRAM threshold
8        analytics.logMemoryLimiterKill(info.description, info.pss)
9    }
10}

The third layer is ProfilingManager. The API itself arrived with Android 15 (API 35); the TRIGGER_TYPE_ANOMALY trigger was added with Android 17 (API 37) ("Android 17 adds several new system triggers to ProfilingManager").

Google describes the trigger like this: "you can also leverage trigger-based profiling using TRIGGER_TYPE_ANOMALY to automatically capture heap dumps when the memory limit is reached." This means you can automatically capture a heap dump the moment the memory limit is exceeded on a user's device — so instead of trying to reproduce the bug in the lab, you can work with real user data.

Support is growing on the Play Console side too: Google says for Crashes and ANRs, "we've added a new filter for Crashes and ANRs so you can easily identify when the OS terminated your app due to severe memory pressure" — meaning you can now see, via a dedicated filter, the cases where the OS shut down your app due to severe memory pressure. In addition, Firebase Crashlytics 20.1.0 offers "additional debug data to help you catch, prioritize, and fix Out-Of-Memory exceptions and memory limiter kills."

Most common sources of memory bloat

The main areas Google's official guides recommend against memory bloat are as follows — these aren't a statistic like "Google says 90% is this," but directly recommended optimization areas:

• Code optimization (R8/DEX): Unused classes and methods left unminified lead directly to unnecessary memory footprint. Google's minimum 25% coverage requirement (below) targets this directly.
• Image/bitmap management: Loading large bitmaps without scaling them to screen size directly affects "bitmap memory usage," a separate component of the dynamic thresholds. This is also why the thresholds sit above zero: your app can be sampled mid-response while it's still releasing bitmap memory via onTrimMemory.
• Leaks: Objects whose references aren't released (forgotten listeners, static references), detected with Android Studio's memory profiler, accumulating on the live heap.
• Not using onTrimMemory: Apps that don't release cache and temporary resources on a memory pressure signal keep holding high memory in the background longer.

Note: no Google source was found that officially ties Jetpack Compose's recomposition behavior to this specific 2027 requirement; Compose performance is covered as a separate topic in our Jetpack Compose 1.7 Strong Skipping article — it shouldn't be confused with general memory management here.

When prioritizing these four areas, you can follow this order: R8/DEX first, because a single configuration change (two lines in the gradle file) delivers a measurable gain; then bitmap management, because it's usually concentrated on the most visible screens (gallery, feed, profile) and also directly improves user experience; leak hunting and onTrimMemory are longer-haul items that require ongoing discipline. If you want to approach the threshold in the short term, the first two are enough; if you want to stay under the threshold long-term, you need all four.

The measure-fix-verify cycle

The most efficient way to prepare for the thresholds isn't a one-off "optimization sprint," but building a repeatable cycle:

1. Measure: with dumpsys meminfo + Android Studio Memory Profiler in the development environment; with the Memory heading in the Android vitals overview (or the Play Developer Reporting API) in production.
2. Prioritize: count MemoryLimiter kills and OOM crashes with ApplicationExitInfo, and find the most affected screen/flow.
3. Fix: increase R8 coverage, scale down large bitmaps, implement onTrimMemory, break the leak chain.
4. Verify: measure the same flow again, confirm the P90 value has dropped below the threshold for the RAM class.

Instead of running this cycle manually, you can embed it into your build process — the next section covers that.

The most skipped step is the fourth: verification. Instead of assuming a fix "probably helped" once shipped, re-measure the same flow on the same RAM class and confirm the actual P90 changed. The 28-day window slows this down — you may need a full window to see a fix's effect, so the earlier you start the cycle, the more comfortably you'll enter February 2027.

Setting up a memory regression gate in CI

On the DEX optimization side, Google gives a clear threshold: "apps published on Google Play must be optimized with a minimum of 25% coverage across optimization, shrinking, and obfuscation." The requirement has two qualifiers: it only applies to projects with "non-negligible DEX sizes" (DEX above 10 MB for apps, 50 MB for games), and tool choice is free — "You can use any tool, such as R8 or another app shrinker." R8 is the most common path, not the only one:

1// app/build.gradle.kts
2android {
3    buildTypes {
4        release {
5            isMinifyEnabled = true
6            isShrinkResources = true
7            proguardFiles(
8                getDefaultProguardFile("proguard-android-optimize.txt"),
9                "proguard-rules.pro"
10            )
11        }
12    }
13}

To turn this into a regression gate in CI, it's enough to add a simple step that builds the release APK/AAB on every PR and compares DEX coverage and size against the last successful build:

1#!/usr/bin/env bash
2# ci/check-dex-coverage.sh — runs after the release build
3set -euo pipefail
4 
5APK=app/build/outputs/apk/release/app-release.apk
6BASELINE=ci/dex-size-baseline.txt   # updated weekly by cron, NOT by the PR build
7 
8./gradlew assembleRelease
9 
10# Only classes*.dex entries (KB) — not the entire APK
11DEX_SIZE_KB=$(unzip -l "$APK" 'classes*.dex' | awk '/classes.*\.dex$/ { s += $1 } END { print int(s / 1024) }')
12 
13# If there's no baseline, don't fail under set -e — use the current measurement as baseline
14BASELINE_KB=$(cat "$BASELINE" 2>/dev/null || echo "$DEX_SIZE_KB")
15LIMIT_KB=$((BASELINE_KB * 110 / 100))
16 
17if [ "$DEX_SIZE_KB" -gt "$LIMIT_KB" ]; then
18  echo "DEX size is 10% above the weekly baseline: ${DEX_SIZE_KB}KB > ${LIMIT_KB}KB"
19  exit 1
20fi
21 
22echo "DEX size is within the limit: ${DEX_SIZE_KB}KB <= ${LIMIT_KB}KB"

This script catches whether minifyEnabled/shrinkResources actually work and catches DEX bloat over time by measuring the DEX entries directly; to measure Google's 25% coverage requirement itself, use the App Bundle Explorer reports in Play Console — the CI script is only an early-warning layer.

The gate's critical detail: the script never overwrites the baseline itself. Overwriting it on every green build would hide slow, steady growth (say, 2-3% per PR). Recording the baseline via a weekly cron job instead catches gradual DEX bloat. Apply the same logic to bitmap size — tracking du -sh app/src/main/res/drawable* against a weekly baseline is a second signal at no extra cost.

Roadmap: from October 2026 to February 2027

Your window is about four months. The recommended sequence:

• October 2026: Add ApplicationExitInfo scanning to production and learn the current MemoryLimiter kill rate (you can't measure improvement without a baseline).
• November 2026: Review the P90 data by RAM class in the Android vitals > Memory section, and identify which tier is closest to the threshold.
• December 2026: Verify R8 coverage (the 25% requirement), scale down large bitmap resources, and close onTrimMemory gaps.
• January 2027: Ship the fixes to production and wait for at least one new 28-day P90 window to form (leaving it to the last week is risky since enforcement is based on the 28-day window).
• February 2027: The thresholds take effect; the goal is to have completed at least one full 28-day verification cycle by this date.

The riskiest step is the December-January transition: fixes landing over the year-end holidays can be tough on both traffic and team availability. If possible, finish the major changes (R8 config, bitmap scaling) in November and reserve December-January for verification and fine-tuning — that gets you into February without stress. Small, measurable steps beat one big refactor, and rechecking P90 after each step lowers regression risk.

FAQ

What is the Play Store memory limit, and when does it take effect?

As part of the new quality requirement announced on August 26, 2026, Google Play set memory usage thresholds by device RAM category (Anonymous RSS + Swap, bitmap memory, DEX code optimization) for apps; for example, on devices with 8GB RAM, foreground usage must not exceed 2.25GB at P90. The rules become mandatory starting in February 2027; apps that exceed the threshold will face the risk of reduced visibility and publishing restrictions.

How do I measure my app's RAM usage?

During development you can use adb shell dumpsys meminfo and the Android Studio Memory Profiler. In production, these metrics are accessible under the Memory heading in the Android vitals overview and via the Google Play Developer Reporting API; additionally, you can detect terminations caused by "MemoryLimiter:AnonSwap" using ApplicationExitInfo.getDescription().

What happens on Play Store if I exceed the memory threshold?

According to Google, apps that exceed the threshold may face "reduced app visibility and publishing capabilities" — this isn't an instant shutdown, but a gradual visibility penalty. In a separate layer, Android 17's MemoryLimiter first compresses an app that exceeds the limit into zRAM, and terminates it on-device if it continues.

Is Android 17 MemoryLimiter the same thing as Play policy?

No. MemoryLimiter runs in real time at the OS level, on-device — it started on Pixel with Android 17 and, per the source, rolls out to other manufacturers' 4GB-16GB+ devices over the following year. Play Store's February 2027 thresholds are a separate store-policy audit based on the last 28 days of aggregated data (P90). One governs instantaneous on-device behavior; the other governs long-term store visibility.

How do I meet the DEX code optimization requirement?

You need to reach at least 25% coverage across optimization, shrinking, and obfuscation by keeping a shrinker enabled in release builds. R8 (isMinifyEnabled = true, isShrinkResources = true) isn't mandatory; Google says "You can use any tool, such as R8 or another app shrinker." The requirement only applies to projects where DEX size isn't negligible: above 10 MB for apps, above 50 MB for games.

Are the thresholds different for games?

Yes. In the 8GB RAM class, the foreground threshold is 2.25GB for apps versus 3.5GB for games — Google has set a higher ceiling in acknowledgment that game engines naturally use memory more intensively. The distinction is made based on the category in Play Console's Store settings; changing the category just to get into different thresholds counts as a Metadata policy violation.

Conclusion

The February 2027 thresholds sit on a timeline too concrete for a "someday" list: within four months, bring your P90 memory usage below the device-class ceiling. The fastest win is verifying R8/DEX optimization; the most durable win is a continuous measurement cycle with ApplicationExitInfo and Play Console Memory vitals. Track Android 17's MemoryLimiter and the store policy separately — don't conflate them.

If you want to dig deeper, you can find other effects of MemoryLimiter in our Android 17 (API 37) behavior changes article, how a similar mandatory timeline was handled in our Google Play API 36 deadline article, general memory/performance optimization in our Jetpack Compose 1.7 performance article, other quality requirements in Play Console in our Google Play Billing v7 article, and a cross-platform memory management comparison in our iOS Memory Management article.

Sources

• Elevating app quality: memory and device migration — Android Developers Blog — The official announcement of the February 2027 thresholds, the DEX 25% rule, and Play Console tools.
• Play Console Help — Core quality vitals thresholds — The foreground/background threshold table by RAM class and the P90 methodology.
• Preparing your app for broader memory limits — Android Developers Blog — Android 17 MemoryLimiter's zRAM compression and termination behavior.
• Prioritizing memory efficiency: steps for Android 17 — Android Developers Blog — ProfilingManager TRIGGER_TYPE_ANOMALY and GC/jank effects.
• Google to impose new Android app memory limits — TheNextWeb — Independent news confirmation of the announcement and ecosystem context.