Google Play's technical quality bars (and what changes in February 2027)

Google Play measures a handful of technical-quality signals on your app and acts on them — a build that crosses a threshold can lose discoverability on the Play Store, independently of anything to do with testing tracks or production access. Two of those bars are in force today; two more were announced for February 2027. All four are Google's own numbers, and the sources at the bottom of this page are where to verify them.

In force today: crashes and ANRs

Google Play flags an app once at least 1.09% of its daily users hit a user-perceived crash across all devices — or at least 8% of daily users on a single device model. The per-model figure is the one developers most often miss: an app whose overall crash rate looks healthy can still be flagged because one manufacturer's build is failing badly.

The same shape applies to ANRs, the freezes where the app stops responding to input: at least 0.47% of daily users globally, or 8% on one device model, crosses Google Play's bad-behavior threshold.

February 2027: memory thresholds by RAM tier

Google Play is introducing memory thresholds measured per RAM tier — 4, 6, 8, 12 and 16 GB — at the 90th percentile of sessions. The consequence is that "how much memory does my app use" stops being one number: a footprint that is comfortable on a 16 GB flagship can already be over the line on a 4 GB device, and the tier your app is judged against is the tier the user is on, not the tier you develop on.

Practically, this is the requirement most likely to surprise a developer who only tests on their own phone, because memory pressure on low-RAM hardware is invisible on high-RAM hardware — the app doesn't behave slightly worse, it behaves differently, with background processes evicted and work redone.

February 2027: code optimization for apps over 10 MB of DEX

Apps with more than 10 MB of DEX code will need at least 25% obfuscation, 25% optimization and 25% shrinking to be uploaded to Play Console. For most Android projects that means R8 doing real work rather than being effectively disabled — a build configuration question, answerable from your Gradle setup, not something a run on a phone can tell you.

Startup time: two different number series

Startup is where published figures get misquoted most, because two unrelated series exist and they are routinely merged. Android's own recommended targets are goals, not enforced: under 500 ms cold, under 200 ms warm, under 150 ms hot. Android Vitals' "excessive startup" bad-behavior thresholds are the ones that can actually affect your app: 5 s or more cold, 2 s or more warm, 1.5 s or more hot. A 1.6-second cold start is nowhere near the enforced threshold and nowhere near the recommended target — both statements are true, and only stating one of them misleads.

What you can actually do about it before release

None of these are things Play Console tells you before you ship — they're computed from real user data after release, over a rolling window of up to 28 days. What you can do beforehand is measure the same categories on real hardware across the RAM tiers your users actually have, and check the static build facts (DEX size, R8 configuration, target API level, native library packaging) directly from your artifact. That is exactly what our Android QA & Performance Testing product does; it is not a compliance guarantee, and no one outside Google can offer one, because Play's verdict depends on your real users' devices.