Google announced two related changes in August 2026 that mobile teams should treat as one performance program. Android 17 introduces per-app memory limits, starting on Pixel devices, to stop one application from degrading the whole device. On 26 August, Google Play published new technical-quality thresholds for memory and DEX optimization, with enforcement beginning in February 2027.
This is not only a targetSdkVersion project. Android lists the memory limiter among changes that affect all apps running on Android 17, regardless of target SDK. Play evaluates versions for which field data is available over a rolling 28-day window. A build can therefore pass compilation and a short manual test, yet still be throttled or terminated on real hardware and later put store visibility or publishing capability at risk.
Android 17 app memory limits and Google Play technical quality requirements
What happens when an app exceeds its budget?
Google describes progressive enforcement. When an app reaches its allocated limit, the system forces some pages into zRAM, compressed memory inside RAM. That can delay termination, but compression and decompression add CPU work and may appear as jank or slower interactions. If memory keeps growing beyond the zRAM threshold, Android can terminate the process.
Do not classify every case as a traditional out-of-memory crash. After termination, inspect ApplicationExitInfo.getDescription(). A memory-limiter event uses REASON_OTHER and includes MemoryLimiter:AnonSwap in the description. Trigger-based profiling with TRIGGER_TYPE_ANOMALY can also capture a heap dump when the limit is reached.
Android 17 exposes test commands on devices that implement the limiter:
adb shell am memory-limiter status
adb shell am memory-limiter manual <pid> 512
adb shell am memory-limiter ignore <uid>The manual limit is expressed in megabytes. The ignore command is a diagnostic control, not a production workaround. Restore the default and prove the flow under constrained memory before accepting a fix.
How Google Play measures bad behavior
Android vitals adds two core measures: dynamic memory, expressed as Anonymous RSS + Swap, and bitmap memory. The first includes Java or Kotlin heap, native allocations, anonymous mappings, and memory compressed or paged into zRAM. It excludes stored files such as code and packaged assets.
Google aggregates anonymized samples from opted-in users. Compliance uses the 90th percentile, split by app state and physical-RAM tier, across the latest 28 days. According to the current support page, memory data covers Android 13 and later and the requirement applies to phone and tablet form factors.
For non-game apps, published dynamic-memory P90 examples are:
| Physical RAM | Foreground | User-perceived service | Background |
|---|---|---|---|
| 4 GB | 2 GB | 1 GB | 1 GB |
| 6 GB | 2.25 GB | 1.25 GB | 1.25 GB |
| 8 GB | 2.25 GB | 1.5 GB | 1.5 GB |
| 12 GB | 3.25 GB | 1.75 GB | 1.75 GB |
| 16 GB | 4.25 GB | 2 GB | 2 GB |
For bitmap memory, the bad-behavior threshold is above 200 MB in a user-perceived service or background state and above 400 MB while cached. A dash in Google’s table means no threshold is published for that cell. It does not mean unlimited memory.
The business cost is larger than RAM
From February 2027, Google says apps and games must meet the memory and DEX thresholds. Non-compliant products may have reduced visibility and publishing capabilities. Google also says more operational detail will arrive later, so it would be inaccurate to claim a specific penalty is already active today. Waiting for the warning is still risky because a fix needs time to move through release tracks and then replace a 28-day field window.
Poor memory behavior has a cost before store enforcement: support cases, interrupted purchases or uploads, battery drain, low ratings, and more device testing. In commerce or field-service software, process death during payment, capture, or synchronization is a conversion and trust failure, not merely an internal performance statistic.
DEX optimization becomes part of the same release gate. From February 2027, relevant uploads must achieve at least 25% each for obfuscation, optimization, and shrinking. Google currently scopes that measurement to apps with more than 10 MB of DEX and games with more than 50 MB. R8 or another shrinker can satisfy it, but release builds require real regression tests because broad keep rules reduce optimization while overly aggressive rules can remove reflection or serialization paths.
A six-week implementation plan
1. Baseline the production artifact
Record P50 and P90 by foreground, background, RAM tier, Android version, and app version. Correlate memory with ANR rate, crash-free sessions, and the time to open expensive screens. Do not use a debug build as the baseline. Debug tooling and the absence of release optimization materially change the result.
2. Exercise expensive user journeys
Test sign-in, long feeds, image capture and editing, maps, video, uploads, and background-to-foreground return. Repeat the flow on 4, 6, and 8 GB devices where possible, including rotation and language changes. In React Native, separate JavaScript heap, native allocations, and decoded images. A visually simple screen can still retain expensive native objects.
3. Fix ownership and retention
Look for retained Activity or Context references, listeners that are never removed, unbounded caches, images decoded above their display size, and lists that load every page. Apply pagination, resize media, respond to onTrimMemory, and release resources that background work does not need. An in-memory cache should not become a full second copy of the database.
4. Optimize the release build safely
Enable minification and resource shrinking, use proguard-android-optimize.txt, and inspect R8 Configuration Analyzer for broad keep rules. Archive the mapping file for every release so production traces remain readable. Test deep links, notifications, JSON adapters, and SDKs that rely on reflection.
5. Add CI and rollout gates
Set memory budgets for critical journeys and reject unexplained regressions. Release through internal and closed tracks, then read Android vitals by version before expanding. Pause rollout when P90 rises materially, MemoryLimiter:AnonSwap appears, or crash-free sessions decline.
Compatibility, availability, and measurement limits
- Memory limits start with Pixel devices. Google expects more manufacturers to adopt them over the following year across devices from 4 GB to more than 16 GB, but not every Android 17 device should be assumed to enforce the same budget today.
- Limits depend on total RAM and process state. There is no single universal megabyte value.
- Play data is sampled from opted-in devices. A small release or region may not yet have a representative sample.
- The Play requirement applies to mobile and tablet distribution globally rather than to a named country rollout. Android 17 availability and limiter adoption still vary by manufacturer, model, and market.
- Thresholds and policy details may change before February 2027. Record the review date and recheck the official requirement before release.
Practical recommendation
Avoid a random campaign to remove every allocation. Start with P90 on journeys that matter to customers and connect each change to an observable outcome: fewer terminations, smoother interaction, or faster recovery. For an Arabic app, include Arabic fonts, content imagery, reversed lists, and language switching because those paths can expose caches and rendering behavior missed by one English test.
Make the memory report and R8 result part of release readiness alongside signing and privacy checks. February 2027 is the announced enforcement point, but the baseline needs to start now. That leaves time to fix the artifact, ship it gradually, and observe a full 28-day Play window after the improvement.
Sources and review date
- Android 17 changes for all apps and memory limits
- Google’s preparation guidance, 19 August 2026
- App-quality announcement and enforcement timing, 26 August 2026
- Official Google Play technical-requirement tables
- Status, thresholds, scope, and dates were reviewed on 29 August 2026.