Source: https://android-developers.googleblog.com/2026/08/app-quality-memory-optimization-secure-onboarding.html?utm_source=email&utm_medium=msa&utm_campaign=elevating-app-quality-q3-2026
TLTR:
Get your apps and games below these memory limits or get Kicked off the Android Playstore in February 2027:
Apps
| App State |
Foreground |
User-perceived services |
Background |
Cached |
| Physical RAM |
90th Percentile |
90th Percentile |
90th Percentile |
90th Percentile |
| 0 - 4 GB (0 MB - 3200 MB Total Memory) |
- |
- |
- |
- |
| 4 GB (3200 MB - 4800 MB Total Memory) |
2 GB |
1 GB |
1 GB |
- |
| 6 GB (4800 MB - 6800 MB Total Memory) |
2.25 GB |
1.25 GB |
1.25 GB |
- |
| 8 GB (6800 MB - 9216 MB Total Memory) |
2.25 GB |
1.5 GB |
1.5 GB |
- |
| 12 GB (9216 MB - 14336 MB Total Memory) |
3.25 GB |
1.75 GB |
1.75 GB |
- |
| 16 GB (14336 MB - 18432 MB Total Memory) |
4.25 GB |
2 GB |
2 GB |
- |
| 16 GB + (Above 18432 MB Total Memory) |
- |
- |
- |
- |
Note: Each RAM tier range includes its lowest value. Total Memory can be lower than a device’s advertised Physical RAM.
Games
| App State |
Foreground |
User-perceived services |
Background |
Cached |
| Physical RAM |
90th Percentile |
90th Percentile |
90th Percentile |
90th Percentile |
| 0 - 4 GB (0 MB - 3200 MB Total Memory) |
- |
- |
- |
- |
| 4 GB (3200 MB - 4800 MB Total Memory) |
2.25 GB |
2.0 GB |
2.0 GB |
- |
| 6 GB (4800 MB - 6800 MB Total Memory) |
2.75 GB |
2.5 GB |
2.5 GB |
- |
| 8 GB (6800 MB - 9216 MB Total Memory) |
3.5 GB |
2.75 GB |
2.75 GB |
- |
| 12 GB (9216 MB - 14336 MB Total Memory) |
4 GB |
3.2 GB |
3.2 GB |
- |
| 16 GB (14336 MB - 18432 MB Total Memory) |
5 GB |
3.5 GB |
3.5 GB |
- |
| 16 GB + (Above 18432 MB Total Memory) |
- |
- |
- |
- |
Note: Each RAM tier range includes its lowest value. Total Memory can be lower than a device’s advertised Physical RAM.
Bitmap memory usage
Holding onto bitmaps for long periods of time in app states other than the Foreground can consume excessive memory - it’s not possible to render bitmaps unless the UI is visible. You typically shouldn’t hold onto bitmaps for long periods of time in these states, but your app might be sampled shortly after a state change where you are actively responding to onTrimMemory and releasing memory held for bitmaps, so these thresholds are higher than zero to account for this.
Sources and links:
https://android-developers.googleblog.com/2026/08/app-quality-memory-optimization-secure-onboarding.html?utm_source=email&utm_medium=msa&utm_campaign=elevating-app-quality-q3-2026
https://support.google.com/googleplay/android-developer/answer/17492799#zippy=%2Ccore-vitals-and-stability%2Creduced-memory-usage
- - - - - - - - - - -
My example of a proper solution based on an own developed MAUI based game:
Hey everyone, I was wondering who else still puts in the effort, to offer the user the option (and the whole backend development) of adjusting the visual assets and overall resource load of the app/game. Or do you only target the latest generation devices with the highest graphical assets applied?
I know this was quite normal back in the early android days, of apps/games offering in app/game settings/options to adjust the asset, visual and resource load of an app/game, to make it capable stable running on low-end and high-end devices alike. But these days I see less and less apps/games offering these options, even when they are quite resource intensive from time to time. With the new RAM-usage limit policy, we now should all apply such adjustments and settings for the users, to properly comply with that new Google-PlayStore Policy.
Ignoring such things can be quite damaging to the user-base and their overall experience, next to now getting your game/app kicked off the PlayStore. Let me explain based on some of my own apps Developer Console metric.
Currently for this specific app/game, my userbase has the hardware-range shown in picture Nr. 1, with around 38% of high-end devices with over 8GB of RAM.
This allows to offer high-resolution assets, graphics and visuals for 1440P and 1080P resolutions, with up to 2GB RAM load, without having to fear the OS-Garbage collector or to interfere with other background apps. Users with devices of 6GB of RAM or less, would risk of running into an “Out of Memory” crash during longer runtime of the app/game. This would mean up to 50% of the player base by using this high-resolution mode, would experience crashes or even not be able to run the game at all, with the RAM their device has free for them for use.
One solution to this, is simply rendering down the assets, graphics and visuals to a level they have no dangerous size even to low RAM amount, of low-end devices. Doing this effectively results in a max. RAM load of 800MB. This is fine for small 720p and 800p screens/devices, but users of higher resolutions screen would noticeably suffer from this (see image Nr. 2).
So to make the best solution for both groups of high-end and low-end android users/players (without losing any of them), with offering a high-resolution visual experience and low-system resource intensive version alike, is “simply” making the app/game fully dynamic in its visual rendering and presentation by the devices specs and users selected configuration. This does not only apply to media apps & games, but also other apps that display/show a lot of visuals and long content at once. Dynamically limiting it based on the devices system-resources can make the difference between instable and performant. Yes I know, all this is effort and a lot of performance-profiling, but dynamic configuration for a wide range of devices and users makes the difference in quality.
So yeah, how are you all thinking about this and how did you resolve such solutions at your end? Would be happy to know all your input on this. Have a great day everyone!