Technical guide · Google Play
Android Vitals: Crash Rate 1.09% & ANR 0.47% (Google Play Limits)
Updated:
Google Play cuts your app's visibility if crash rate passes 1.09% or ANR 0.47% of daily users (8% per phone model). What Android Vitals measures and how to stay under.
Android Vitals isn't just an info panel in Play Console: two of its metrics — user-perceived crash rate and ANR rate— are core vitals, meaning crossing certain thresholds directly reduces how much Google Play recommends your app, with or without changes to your listing or keywords.
What is Android Vitals?
Android Vitals is the Play Console section (Quality → Android Vitals) where Google aggregates, from the devices of real users who opted in to share data, your app's stability and performance: crashes, ANRs ("app not responding"), battery drain, startup times and denied permissions. There is nothing to integrate: it fills up on its own from production usage and from closed and open tests. Two of its metrics are "core vitals" with thresholds that directly affect your visibility; those are the ones explained below.
The exact thresholds
| Metric | Overall threshold | Per-device threshold |
|---|---|---|
| Crash rate (user-perceived) | ≥ 1.09% of daily active users | ≥ 8% on a single model |
| ANR rate (user-perceived) | ≥ 0.47% of daily active users | ≥ 8% on a single model |
Cross the overall threshold and your app becomes less discoverable on every device. Cross the per-device threshold on a specific phone model and Google Play stops recommending your app to users on that model, possibly with a warning on the store listing.
ANR rate: what it means and what causes it
An ANR (Application Not Responding) happens when your app's main thread stays blocked for too long and the system shows the close dialog. The ANR rate is the share of daily active users who had at least one user-perceived ANR: that is why a 0.47% threshold sounds tiny but is easy to cross in busy apps.
- Common causes: network or disk work on the main thread, deadlocks between threads, heavy work at startup and synchronous preference writes.
- How to catch them before launch: enable StrictMode in test builds and review the ANR clusters Android Vitals groups by stack trace in Play Console.
- Why device variety matters: an ANR you never see on your flagship phone shows up on a slower model; a closed test across different manufacturers surfaces them.
Why this can catch you off guard
The per-device threshold (8%) is easy to cross without noticing: your overall crash rate might look perfectly healthy, but if a budget model or a specific manufacturer accounts for only 3-4% of your users and its crash rate there is 15%, you're already penalized on that segment — even though the aggregate number hides it.
How this connects to pre-launch testing
Catching these issues in production means you've already crossed the threshold and are losing visibility while you fix it. The alternative is covering varied manufacturers and device categories in your closed test before requesting production — exactly what Tester Marketplace campaigns support with manufacturer and device-category targeting (phone, tablet, foldable) and a dedicated device compatibility test focus.