Google Play will enforce new Android app performance rules in 2027

Google is tightening the technical quality bar for apps distributed through Google Play. Starting in February 2027, Play will assess apps and games against new “bad behavior” thresholds for dynamic memory, bitmap memory and DEX-code optimization. Apps that remain above the limits may face reduced Play visibility and publishing restrictions, rather than an automatic delisting.

A second requirement arrives in April 2027: apps that use sign-in must support Zero-Tap Sign-In during device migration, using Android’s Restore Credentials system. Games are currently exempt from that migration requirement. 17

What Google Play will measure

The performance policy focuses on three areas that can contribute to slowdowns, crashes or inefficient app delivery:

1. Dynamic memory usage

Google will measure an app’s anonymous resident-set size, or RSS, together with compressed swap. This focuses on private memory consumed while the app runs, rather than treating every code or asset file stored on the device as application memory.

For games, the foreground dynamic-memory thresholds scale with device RAM. The stated range runs from 2.25GB on 4GB-RAM devices to 5GB on 16GB-RAM devices. Google Play plans to evaluate performance across device capability tiers instead of applying one identical allowance to every phone or tablet.

2. Bitmap memory

Bitmap use will be assessed across foreground, background and cached states. The thresholds are:

• 200MB while an app is in the foreground or background
• 400MB while an app is cached

The goal is to prevent visual assets from remaining unnecessarily resident in memory when they are no longer immediately visible.

3. DEX-code optimization

Games with more than 50MB of DEX code will need at least 25% App Bundle coverage through code optimization, shrinking and obfuscation. Developers can use tools such as R8 or another shrinking tool to reduce unnecessary code and improve the efficiency of the delivered bundle.

How enforcement will work

Google Play will not judge an app from one unusually bad session. The thresholds are evaluated using the 90th percentile, or P90, of data collected over a rolling 28-day period. In practical terms, the policy is aimed at persistent performance problems across real-world usage rather than a single worst-case measurement.

Apps that fail to meet the requirements may see reduced app visibility and publishing capabilities on Google Play. That is different from a stated policy of automatically banning or delisting every app that crosses a threshold. Google is also rolling out Play Console monitoring and diagnostic tools so developers can inspect dynamic-memory and bitmap metrics before enforcement begins.

The thresholds may also change as Google collects more data and refines its understanding of performance across different device and app categories. Developers should therefore treat the published limits as a baseline for ongoing monitoring, not as a one-time certification target.

The separate Zero-Tap Sign-In deadline

The second policy change addresses a different part of the Android experience: moving to a new device. From April 2027, apps with user sign-in will need to support Zero-Tap Sign-In, which automatically restores a user’s sign-in state during Android-device migration through the Restore Credentials API.

Restore Credentials is implemented through Credential Manager and is designed to silently sign users back in when they restore an app on a new device. It can work independently of the app’s primary authentication method, including passwords, passkeys or federated sign-in. 1719

The requirement is intended to reduce the friction of manually signing in to every app after a device transfer. Games are currently excluded, although that exemption could change as Google develops the policy further.

How this relates to Android 17

The Play policy complements, rather than replaces, Android 17’s operating-system memory controls. Android 17 introduces per-app memory limits based on a device’s total RAM, initially on Pixel devices. Google says more manufacturers are expected to use the limits across devices ranging from 4GB to more than 16GB of RAM.

When an app exceeds an Android 17 memory limit, the operating system can slow it down and may eventually terminate it. Play’s new requirements operate earlier in the distribution process: they encourage developers to reduce excessive memory use and optimize code before users encounter operating-system enforcement in the field.

That distinction matters. Android 17 governs what can happen while an app is running on a particular device; Google Play’s 2027 rules govern whether an app continues to receive normal visibility and publishing access in the store.

What Android developers should do now

Developers with large apps or games should begin by:

1. Auditing anonymous RSS and compressed-swap usage across foreground and background sessions.
2. Tracking bitmap memory separately from general heap usage, including cached states.
3. Checking DEX size and measuring App Bundle coverage from shrinking, optimization and obfuscation.
4. Testing across multiple RAM tiers instead of relying only on high-end devices.
5. Watching Play Console’s forthcoming diagnostics and Android vitals metrics.
6. Reviewing the app’s authentication flow and planning Restore Credentials support before April 2027.

The practical message is straightforward: memory efficiency and code optimization are becoming distribution concerns, not merely performance best practices. Apps that do not prepare may still run, but they risk poorer Play visibility, tighter publishing access and more exposure to Android’s own memory controls.