The per-app memory limits that Google introduced with Android 17 on Pixel devices are now set to expand to devices from other manufacturers. On August 19, 2026, the company announced plans to increase the number of adopting device makers over the coming year, extending coverage from configurations with 4GB of physical RAM up to those with more than 16GB. In addition to the traditional approach of reclaiming memory only after the entire device becomes constrained, the new system will throttle apps that use too much memory, and ultimately terminate them. How far will this rollout extend, and what do developers need to re-measure on the app side? These questions will shape developer decision-making.
From Pixel to 4GB–16GB+ Devices
Android 17 corresponds to API level 37, and this limit is configured according to a device's total RAM. According to Google's explanation, it applies to all apps running on Android 17 regardless of targetSdkVersion. This is not a compatibility change that only affects apps that have already migrated to the new targetSdk—existing apps also need to reconsider how they use memory.
However, this does not mean the limit applies uniformly across all Android 17 devices. Google's page on Android 17 behavior changes describes the limit's scope as applying to "some Android devices." The August 19 blog post likewise only stated a policy of increasing the number of adopting manufacturers over the next year, without naming specific manufacturers, target models, or a rollout start date. This should not be interpreted as mandatory for all manufacturers and all devices, nor as immediate implementation across every Android 17-equipped device.
Prior to this announcement, Google had already indicated a policy of prioritizing memory efficiency in Android 17 and had introduced per-app memory limits on Pixel devices. The August 19 announcement concretizes a plan to expand that mechanism to a broader range of RAM classes and device manufacturers. Google explains the background as follows: due to rising prices of physical memory, RAM capacity in new devices has remained flat or is decreasing. This is the company's stated rationale for the rollout, not independent market data.
Even if a device's RAM capacity is large, that doesn't necessarily mean memory-intensive apps are always safe. Since a per-app budget is set according to total RAM, developers must check not only the device's stated capacity but also how much actual memory their own processes reach on target devices. Specific budget values have not been disclosed.
Throttled via zRAM, Then Terminated
When an app reaches its allocated budget, the system sends its pages to zRAM. zRAM is a mechanism that holds compressed data within RAM, and compression and decompression require CPU processing. As a result, apps that continue using memory may experience effects such as UI stuttering or slowdowns before being terminated outright.
If usage continues to increase even after crossing the zRAM threshold, the system will terminate the process. Google notes that this termination does not come with a normal stack trace. For workflows that only search for crash logs, distinguishing terminations caused by memory limits becomes difficult. On screen, it begins as lag and ultimately ends with the process disappearing. Developers will need to test performance issues and post-termination recovery within the same scenario.
Android has traditionally had a hard limit on an app's heap capacity. In addition, the Low Memory Killer Daemon (lmkd) detects device-wide memory pressure and terminates lower-priority processes based on oom_adj_score. In situations where a large app protected by, say, a foreground service remains active, cached apps or background processes may be killed first.
The per-app limit addresses overuse before the entire device becomes memory-constrained. It pushes the pages of an app that has exceeded its allocation to zRAM, and if usage continues to grow, terminates that process. According to Google's explanation, the goal is to limit the impact that memory-overusing apps have on other apps. That said, the exact formula for determining when to move data to zRAM, and how device-specific budgets are calculated, have not been disclosed.
Look at the Tail, Not the Average
In Google Play Console's Android vitals, developers can check Anonymous RSS + swap as a memory monitoring metric. Anonymous memory includes the Java/Kotlin heap, native heap, and thread stacks, among others. Since P50 and P90 values can be viewed by device RAM class and process state, developers can isolate sessions where usage grows in ways that wouldn't be apparent from an average across all users alone.
Google suggests that when the ratio of P90 to P50 exceeds 3.5x, this can serve as a guideline for identifying candidates for memory leaks in long-running sessions. However, a high ratio alone cannot definitively confirm a leak. Depending on the use case, a long tail can also result from a limited number of users handling large amounts of data. RAM class, whether the app is in the foreground or background, and whether an SDK is spawning a separate process—these factors need to be examined separately.
Sessions terminated due to the limit can be identified via ApplicationExitInfo.getDescription(). The reason will be REASON_OTHER, and the description will include MemoryLimiter:AnonSwap. Capturing this marker in recovery logic or analytics infrastructure allows it to be treated as a distinct pathway separate from ordinary crashes—a useful clue given the absence of a stack trace at termination.
Furthermore, ProfilingManager, introduced in Android 15 (API level 35), can use TRIGGER_TYPE_ANOMALY to collect a heap dump at the moment the memory limit is reached. In reproduction environments, the adb command am memory-limiter is also available. It has three subcommands—ignore, manual, and status—and manual allows specifying a PID and an upper limit in megabytes. Official documentation uses 30MB as an example, but this feature will not function on devices that don't support the limit.
Diagnosis doesn't end with simply reviewing numbers. Developers need to verify, on real devices or via reproduction commands, whether screen state can be saved as the app approaches its limit, whether necessary data can be restored on resume, and how much the UI slows down during heavy operations. By narrowing down long-tail RAM classes and processes using Android vitals, then tracing reproduction paths using exit information and heap dumps, developers can investigate memory consumption that wouldn't be visible on an average device.
Unresolved Factors Remain for High-Memory Apps
This announcement revealed the timeline for expanded adoption and the RAM configurations covered, ranging from 4GB to over 16GB. However, which manufacturers' which models will adopt this and when remains unknown. Default limit values by RAM class, and the specific budgets given to visible versus invisible processes, have also not been published. It is not yet possible to calculate, via a general formula, the point at which an app's memory usage will hit the limit.
Anonymous RSS + swap is the metric Google recommends for diagnosis and monitoring, but there is no basis to conclude definitively that it is the sole value used to calculate the limit. The same applies to the conditions governing the transition from offloading to zRAM to termination. Rather than setting hypothetical thresholds before official values are published, developers would be better served by measuring actual behavior on each Android 17 device that has implemented the limit, prioritizing testing of memory-intensive screens and long-running sessions.
Apps with memory-intensive features will need to verify behavior more quickly once device adoption status is made public. Only by confirming which models have adopted the limit, how behavior actually differs by RAM class, and whether state can be preserved after termination, can developers judge how this limit will affect the user experience.