Android vitals in Play Console track stability and performance, and Google uses core vitals to judge app quality. Google has published bad behavior thresholds for the core metrics: an overall user-perceived crash rate of 1.09% and user-perceived ANR rate of 0.47%, plus a per-device threshold of 8%. Exceeding the overall thresholds can reduce your app's discoverability on Google Play, and exceeding the per-device threshold can reduce visibility and show a warning to users on affected devices.
What Android vitals measure
Android vitals is a section of Play Console that reports technical quality from opted-in Android devices. It covers crashes, application not responding (ANR) errors, excessive battery use, slow rendering, slow startup, and other metrics. Some are core vitals that Google uses when evaluating app quality on Google Play.
The core vitals focus on what users actually experience: user-perceived crash rate, which counts crashes while the user is interacting with the app, and user-perceived ANR rate, which counts freezes the user notices. Check Play Console for the current list, because Google adds and refines metrics over time.
The bad behavior thresholds
Google has published bad behavior thresholds for core vitals. At the overall level, these are a user-perceived crash rate of 1.09% and a user-perceived ANR rate of 0.47%, measured as the share of daily active users who experience the issue. There is also a per-device threshold of 8% for each phone model.
If your app exceeds the overall threshold, Google may reduce its discoverability on Google Play. If it exceeds the per-device threshold on a specific model, visibility can be reduced on that device and users on it may see a warning on your store listing. Confirm the current thresholds in Play Console help, as Google can update them.
Why vitals matter for ASO
Stability affects ASO directly through visibility and indirectly through ratings. Crashes and freezes generate one-star reviews, and Google Play's rating gives extra weight to recent ratings, so a bad release can lower the visible rating quickly. A warning on the listing also reduces conversion for affected users.
Our guides to crash rate and store ranking and how app ratings are calculated explain how stability flows into visibility.
Reading the vitals dashboard
Play Console shows each metric with your value, the threshold, and comparisons with peer apps. You can break data down by app version, Android version, device model, and country. Start with the core vitals, then check the devices and versions that contribute most.
Look at trends over time and spikes after releases. A sudden increase usually points to a recent update, a new OS version, or a problem on specific devices.
Diagnosing crashes
Crash clusters in Play Console group similar crashes with stack traces. Combine them with crash reporting tools in your app for more context, such as user actions before the crash. Prioritise crashes by the number of users affected, not just total events.
Common causes include null references, memory pressure on low-end devices, unhandled network errors, and third-party SDK issues. Reproduce on affected devices and Android versions where possible.
Diagnosing ANRs
An ANR occurs when the app's main thread is blocked for too long, for example while waiting on disk or network operations, heavy computation, or locks. ANR reports in Play Console show where the main thread was stuck.
Fix ANRs by moving slow work off the main thread, reducing startup work, avoiding synchronous disk and network access, and being careful with broadcast receivers and services. ANRs are often more common on lower-end devices, which may make up a large share of your users in growth markets.
Device-specific problems
Some issues only affect specific devices or manufacturers because of hardware, drivers, or custom Android versions. The per-device threshold makes these problems matter even if your overall rates are fine.
Use device breakdowns to find outliers, and the device catalog in Play Console to understand device specifications. Our tablet and foldable store assets guide reminds teams to test large-screen devices too.
Preventing regressions
Use staged rollouts so new releases reach a small share of users first. Monitor vitals and crash reports during the rollout, and halt it if rates rise. Our staged rollouts and ratings protection guide explains the process.
Use the pre-launch report on testing tracks, which installs your app on real devices and flags crashes and issues before release. Add automated tests for critical paths and monitor third-party SDK updates.
Other vitals worth watching
Beyond crashes and ANRs, vitals cover excessive battery use, such as wake locks and wakeups, slow startup, slow rendering, and excessive background activity. Google has added newer metrics over time, and some may become core vitals. Battery drain and slowness also show up in reviews.
Our guides to app size and conversion and reducing app uninstalls explain how performance affects retention.
iOS equivalents
Apple does not publish equivalent thresholds, but App Store Connect and Xcode Organizer report crashes, hangs, energy use, and other metrics. Stability affects ratings and conversion on iOS just as on Android.
Use TestFlight for beta crash data before release, as described in our TestFlight beta testing guide.
Common vitals mistakes
Ignoring vitals until ratings drop is the most common mistake. Others include releasing to all users at once, fixing only the most frequent crash while ANRs grow, testing only on flagship devices, and adding SDKs without monitoring their stability impact.
Teams also misread total crash counts instead of the share of users affected, which is what the thresholds measure.
A worked example: bringing ANRs under the threshold
A shopping app's user-perceived ANR rate rises above the threshold after adding a new analytics SDK that initialises on startup. Play Console shows ANRs concentrated on low-memory devices. The team moves SDK initialisation off the main thread, defers non-essential startup work, and halts the rollout until the fix ships.
The ANR rate falls back below the threshold over the following weeks, negative reviews mentioning freezing decline, and the app's visibility recovers.
How to do it, step by step
- Review core vitals weeklyCheck user-perceived crash and ANR rates against thresholds in Play Console.
- Break down by version and deviceIdentify the versions, devices, and Android versions driving problems.
- Prioritize by users affectedFix crashes and ANRs that affect the most users first.
- Use staged rollouts and pre-launch reportsCatch regressions before they reach all users.
- Monitor SDKs and low-end devicesWatch third-party SDK impact and test on representative devices.
Before and after examples
Illustrative examples written for a generic app in this category, not client results. Swap in your own product, audience, and data.
Total crash count this week.
Share of daily users experiencing user-perceived crashes versus the 1.09% threshold.
Why it works: Thresholds are based on users affected.
SDK initialization on the main thread during startup.
Initialize SDKs in the background after the first screen renders.
Why it works: Unblocking the main thread prevents ANRs.
Release to 100% and check vitals next month.
Release to 5%, check vitals daily, then expand.
Why it works: Staged rollouts limit damage.
Action plan
- Track core vitals against thresholds
- Break down by device and version
- Prioritize by users affected
- Use staged rollouts
- Run pre-launch reports
- Monitor SDK stability
Metrics to monitor
- User-perceived crash rate
- User-perceived ANR rate
- Worst device rates versus 8% threshold
- Crash-free users by version
- Stability-related reviews
Record the baseline, release date, audience, markets, and external changes before interpreting movement. Rankings and conversion are useful signals, but a decision is stronger when activation, retention, and business value confirm that the page attracted the right users.
Frequently asked questions
What is the Android vitals bad behavior threshold?
Google has published an overall threshold of 1.09% for user-perceived crash rate and 0.47% for user-perceived ANR rate, with a per-device threshold of 8%. Check Play Console for current values.
What happens if my app exceeds Android vitals thresholds?
Google may reduce your app's discoverability on Google Play, and users on affected devices may see a warning on your listing.
What is an ANR?
Application Not Responding: a freeze where the app's main thread is blocked long enough that users notice and Android may offer to close the app.
How do I reduce ANRs?
Move slow work off the main thread, reduce startup work, avoid synchronous disk and network calls, and test on lower-end devices.
Do Android vitals affect rankings?
Exceeding core vitals thresholds can reduce discoverability, and stability problems also lower ratings and conversion.
Does iOS have similar thresholds?
Apple does not publish equivalent thresholds, but crashes and hangs affect ratings and conversion on iOS too.
Keep reading
Go deeper on this topic
More in Platform Guides
Browse all 12 Platform Guides guides
Work with ASOWin
Primary sources
Platform capabilities and limits can change. Verify current requirements in these official resources:
