On this page · 10 sections
Summary. On 19 August 2026 Blair Harmon, Director of Product Management for the Android Platform, wrote that "over the coming year, an increasing number of manufacturers will use the Android per-app memory limits across their portfolio of device RAM configurations from 4GB to 16GB+ devices." Per-app memory limits arrived in Android 17 (API level 37) on Pixel hardware only. The August post moves them to the rest of the ecosystem, and it lands in the middle of a memory price shock: TrendForce estimated on 14 May 2026 that LPDDR4X mobile DRAM contract prices would rise at least 70-75% quarter-on-quarter in 2Q26 and LPDDR5X by 78-83%, pushing mid-range phones back to 8GB and entry-level phones to roughly 4GB. The awkward part is that three Google pages published within 11 weeks describe the consequence of breaching a limit three different ways.
What actually changed on 19 August 2026
The August post is not a new API. The limits themselves were documented earlier in the Android 17 cycle. What changed is the device population.
Until now, enforcement was a Pixel behaviour. Most teams could treat a memory-limiter kill as a rounding error in their crash mix because Pixel is a small slice of installed base almost everywhere outside the United States. Once manufacturers turn the limiter on across 4GB, 6GB, 8GB, 12GB and 16GB+ tiers, the same code path starts firing on the devices that carry the volume, and it fires hardest on the low-RAM tiers where the budget is smallest.
The August post also spells out a two-stage progression that the earlier material did not. First, the system pushes the app's pages into zRAM, which Google says "adds CPU overhead, which can result in noticeable UI jank and experience slowdowns." Only if the app keeps growing past the zRAM threshold is the process terminated.
The contradiction: how bad is it, really
Read three Google pages in sequence and you get three answers.
| Source | Date | How it describes exceeding the limit |
|---|---|---|
| Prioritizing memory efficiency, Android Developers Blog | 2 June 2026 | "Android will kill the process with no associated stack trace" |
| Behavior changes: all apps, Android 17 (Android developer documentation) | updated 14 August 2026 | "we anticipate minimal impact on the vast majority of app sessions" |
| Preparing your app for broader memory limits | 19 August 2026 | "it will be slowed down and may be terminated" |
| Memory usage (anonymous RSS + swap) | updated 3 August 2026 | Frames high memory as a leak-detection problem, not an enforcement one |
| Low memory killers | updated 19 May 2026 | Separate metric; "an LMK rate above 1% indicates a critical need for immediate action" |
These are not equivalent statements. "Killed with no stack trace" and "minimal impact on the vast majority of app sessions" are the two ends of a planning spectrum, and a team reading only the behaviour-changes page would reasonably deprioritise the work.
Our reading is that all three are true of different things. The June wording describes the terminal state. The behaviour-changes wording describes the median session, which is genuinely unaffected because most apps sit well under budget. The August wording describes the tail, and the tail is where your P90 and P99 users live. If your memory distribution has a long right edge, the population statement is irrelevant to you.
How to tell whether this is your problem
Google gives four instruments, and they answer different questions.
The field signal is ApplicationExitInfo. Call getDescription(); if the system applied a limit, the exit reason is reported as REASON_OTHER and the description string contains MemoryLimiter:AnonSwap. That string is the only unambiguous confirmation that the limiter, and not the ordinary low-memory killer, ended the session.
The population signal is the Android vitals Memory usage (anonymous RSS + swap) metric. It reports daily percentile values, breaks usage down by process state (foreground, user-perceived services, background, cached) and by RAM bucket. The documented leak heuristic is a ratio, not an absolute: "if your P90 to P50 ratio exceeds 3.5x, it indicates a likely memory leak during extended sessions." The companion Bitmap memory usage metric, updated 12 August 2026, applies the same 3.5x shape to the P99/P50 ratio in the foreground state and is calculated as a 28-day summary of daily data by default.
The crash-reporting signal arrived earlier than most teams noticed. Firebase Crashlytics 20.1.0 shipped in the Firebase Android BoM v34.16.0 release of 9 July 2026 with a single line: "For API 37+, decorated fatal events with OOM and Anomaly triggers from the ProfilingManager API when appropriate." Crashlytics is currently at 20.1.0 and the BoM at 34.18.0 as of 19 August 2026.
The diagnostic signal is ProfilingManager. The Android 17 features page in the platform documentation, updated 14 August 2026, lists TRIGGER_TYPE_OOM, TRIGGER_TYPE_ANOMALY, TRIGGER_TYPE_COLD_START and TRIGGER_TYPE_KILL_EXCESSIVE_CPU_USAGE, and states that the callback "occurs prior to any system imposed enforcements" — the heap dump lands before the kill, not after.
One documentation gap to plan around: the trigger-based profiling guide, also updated 14 August 2026, still documents only TRIGGER_TYPE_APP_FULLY_DRAWN and does not mention the two memory triggers at all. It does carry the practical constraint the features page omits: ProfilingTrigger.Builder(...).setRateLimitingPeriodHours(1) imposes a per-trigger cooldown on top of the system rate limiter, so you will not collect a dump on every incident.
Reproducing it before your users do
The Android 17 behaviour-changes documentation lists three adb subcommands under am, which is the part of this story a vendor announcement would never carry:
am memory-limiter ignore <uid>|none|all
am memory-limiter manual <pid> <limit>|max|none
am memory-limiter status
manual takes an integer number of megabytes, so am memory-limiter manual <pid> 30 caps that process at 30 MB. max removes all limits on the process, none restores the system default, and status reports the limits currently imposed on visible and non-visible processes. The commands have no effect on a device that does not impose limits, which is the current state of most non-Pixel hardware — so build the test matrix on a device that does.
The realistic test set is the three journeys Google names as the usual offenders: WebView and in-app browser sessions, media-heavy infinite scrolling, and asset creation or editing flows. Capture heap dumps across visible, foreground-service and cached states and check whether memory actually comes back after backgrounding.
What to change, in priority order
The June post's ordering still holds, and the first item is the cheapest.
Enable full R8. Monzo, the UK digital bank with 15 million customers, replaced proguard-android.txt with proguard-android-optimize.txt and reported a 35% reduction in ANR rate, a 30% improvement in cold start, a 24% improvement in warm start, a 14% improvement in hot start, and a 9% reduction in app size. The legacy proguard-android.txt file suppresses optimisation and is no longer supported in Android Gradle Plugin 9.
Fix bitmaps second, because they are usually the largest objects on the heap. Switching from the default ARGB_8888 to RGB_565 where transparency is not needed halves the footprint of that bitmap.
Then trim on the two callbacks that still fire. Since Android 14 the system has stopped delivering every ComponentCallbacks2 level except TRIM_MEMORY_UI_HIDDEN and TRIM_MEMORY_BACKGROUND; the rest were formally deprecated in Android 15. Code written against the older constants is dead code that reads as memory hygiene in review.
India-specific considerations
India's device mix makes this a first-order problem rather than a tail one. TrendForce's May 2026 assessment has entry-level models settling around 4GB while average smartphone DRAM capacity rises only to 8.5GB in 2026, annual growth of 10%. An app tuned on a 12GB flagship in Gurugram or Bengaluru is being tuned two RAM tiers above the device its next million installs will run on.
Google's own low-RAM guidance, the Optimize app memory page for Android (Go edition) updated 26 February 2026, is the closest thing to a playbook for that device class: read the current trim level with ActivityManager.getMyMemoryState(RunningAppProcessInfo), avoid GIFs because they hold a lot of memory, and let aapt convert true-colour PNGs that need fewer than 256 colours into 8-bit palette images at build time.
TrendForce also notes that brands are "working with app developers to reduce memory consumption" as a cost countermeasure. That is worth reading literally: OEM pressure on app memory is a procurement response to DRAM pricing, not only a platform-quality initiative, which makes it unlikely to relax when prices do.
Nothing in the limiter touches personal data, so there is no direct Digital Personal Data Protection Act 2023 exposure here. The indirect one is real, though. If you start uploading production heap dumps through ProfilingManager, those artefacts can contain user content held in memory at capture time, and they need the same retention and access treatment as any other production data export.
What is still unknown
Google has not published which manufacturers are enabling the limiter, on which models, or on what schedule beyond "over the coming year." It has not published the per-RAM-tier budgets in the behaviour-changes page, so the only way to learn your effective ceiling on a given device is am memory-limiter status. And the trigger-based profiling guide still does not document the two triggers that matter most for this change, which means the reference implementation most teams will copy is the one in the blog posts rather than the one in the docs.
If you already track the Android vitals memory metrics and your P90 to P50 ratio sits under 3.5x, this is a monitoring change. If you do not track them, or your ratio is above it, the enforcement population just expanded from Pixel to most of your install base and the work is now dated.
FAQ
How eCorpIT can help
eCorpIT builds and maintains production Android applications, and this change is squarely a build-quality problem rather than a feature one. Our teams run the memory audit end to end: baseline your Android vitals P50 and P90 by process state, reproduce the limiter on hardware that enforces it, wire ApplicationExitInfo and ProfilingManager triggers into your existing crash pipeline, and land the R8, bitmap and trim-callback fixes with regression benchmarks attached. If you need the capacity to do that alongside a roadmap, you can hire Android developers through us on a senior-led team basis. Tell us your current vitals numbers and target device tiers at /contact-us/ and we will scope the remediation against them.
Related reading: the Android 17 memory limiter RAM tier caps breakdown, the Android 17 API 37 behavior changes migration guide, our Android vitals ANR and crash remediation service, and the enterprise mobile app development guide.
References
Last updated: 21 August 2026.
