Android 17 will forcibly close apps that use a lot of RAM

Google has begun to more strictly control RAM usage in Android 17. The new Memory Limiter system is already being used on Pixel smartphones, and other manufacturers will begin implementing it over the next year. The OS can now first slow down an overly resource-hungry app and, if it continues to consume too much memory, forcibly terminate its process.

Google cites not only poorly optimized apps as a reason for the changes. The company notes that due to the rising cost of memory, manufacturers of new devices are increasingly keeping the same amount of RAM or even reducing it, while app requirements continue to grow.

How Android 17 restricts apps

Memory Limiter operates at the Linux cgroup v2 level and controls memory usage for individual app processes. The restrictions apply to all apps on Android 17 regardless of which Android version they were originally developed for.

The system uses different limits for the app currently visible on the screen and for processes running in the background. Background processes are allowed to use significantly less memory.

Upon reaching the soft limit, Android does not immediately close the app. First, the system begins freeing up memory: it discards pages that have not been used for a long time and can be reloaded from files, while moving inactive data to zRAM – an area of RAM where data is stored in compressed form.

This allows the app to continue running, but compressing and decompressing data requires additional CPU resources. As a result, interface slowdowns may occur.

If the app continues to increase its memory usage and exhausts its available zRAM capacity, new memory allocations begin to fail, after which Android may forcibly terminate the process.

Android 17 memory usage limits

Google has already published standard limits for the most common smartphone configurations.

Thus, Android allocates approximately half to two-thirds of the device’s physical RAM to the visible app. About a quarter to a third of the RAM is allocated to background processes.

For these calculations, the system uses the available MemTotal value instead of the memory capacity stated by the manufacturer. It is typically 500 MB to 2 GB or more lower than the physical RAM capacity, since part of the memory is reserved for graphics, the modem, camera, secure environment, and other hardware components.

Pre-installed apps will also be restricted

Memory Limiter monitors virtually all standard app processes, including software pre-installed by manufacturers. The system does not provide a separate whitelist that would allow Samsung, Google, or other companies to exempt their own apps from the restrictions.

The exception is critical Android system processes, to which the memory restrictions do not apply.

The app state is also taken into account. A process with an interface visible on screen receives a higher limit, while background services and handlers operate under stricter constraints. Cached Android processes can be frozen and have their memory usage reduced as much as possible.

Why the restrictions are being introduced

Previously, a single app with a memory leak could gradually put pressure on the entire system. Android would then have to clear memory more aggressively and close other background apps that were functioning normally. As a result, when users returned to those apps, they would face a full cold start instead of an instant restoration of the previous state.

Additional pressure on the memory management system also increases CPU usage and power consumption, which can lead to interface stuttering.

Memory Limiter changes this approach: Android attempts to contain the problem within the app consuming an abnormally large amount of memory instead of allowing it to degrade the performance of the entire system.

At the same time, Google states that the vast majority of normal app sessions should not encounter these restrictions. In Android 17, the thresholds are intentionally set high and are primarily designed to address serious memory leaks and other abnormal scenarios.

Developers will be able to identify why an app was closed

For developers, Google has added separate diagnostic tools. If a process is terminated by Memory Limiter, Android saves the termination reason as REASON_OTHER with the string MemoryLimiter:AnonSwap.

Additionally, the system can be configured to automatically create a memory dump when a process approaches its limit. Android Vitals now includes metrics for standard and swap memory usage, while Firebase Crashlytics 20.1.0 includes additional diagnostics for out-of-memory errors and process terminations caused by Memory Limiter.

Developers can also use ADB to view the current limits on a smartphone, temporarily disable Memory Limiter, or manually set a specific limit for a process during testing.

The new system is currently rolling out to Pixel smartphones. Google expects more Android device manufacturers to adopt it over the next year, including devices with 4 GB to 16 GB of RAM and above.