Android vitals is Google Play's measure of your app's technical quality on real users' devices. The two core metrics are the user-perceived crash rate and the user-perceived ANR (app not responding) rate. If your app goes above Google's bad behavior thresholds, Google may reduce its visibility on Play or show a warning on your store listing, so it is worth understanding the numbers before launch.
Where the data comes from
Android vitals data comes from users who have opted in to sharing usage and diagnostics data with Google, according to Google's Android vitals documentation. You do not need to add an SDK; the data appears in Play Console once enough users are on the app.
For a new app, that has two consequences:
- During a small closed test, you may see little or no vitals data. Twelve testers is rarely enough for meaningful rates.
- After launch, the first numbers can swing a lot because the user base is small. Look at trends, not single days.
The metrics that count
Google defines core vitals and bad behavior thresholds. At the time of writing, Google's documentation lists:
| Metric | Overall threshold | Per phone model |
|---|---|---|
| User-perceived crash rate | 1.09% | 8% |
| User-perceived ANR rate | 0.47% | 8% |
| Excessive battery usage | 1% | not listed |
| Excessive partial wake locks | 5% | not listed |
"Overall" means across all your users. "Per phone model" means that even if your overall rate is fine, a single device model where you go above the threshold can be flagged for that model.
Google also says memory-related metrics may start to affect visibility from February 2027. That is not in effect yet, and the details may change, so check the documentation closer to the date.
Google updates these values from time to time. Check the current figures in the documentation before quoting them to your team.
What "user-perceived" means
A crash or ANR is user-perceived when the user was actively using the app at the time, for example when it was in the foreground. A crash in a background service that nobody notices still matters for quality, but the core metric focuses on the ones users actually experience. This is why a crash on your app's start screen is so damaging: every affected user sees it.
What happens if you go over
Google's documentation says apps above a bad behavior threshold may:
- have reduced visibility on Google Play
- show a warning on the store listing to users of affected devices
Neither is a policy violation in itself, and you can recover by fixing the issues. But a warning on a brand-new app's listing is a bad first impression, so prevention is much cheaper.
How to keep a new app under the thresholds
Before launch
- Read your pre-launch report for every build. It finds crashes on devices your testers do not own. See our article on the pre-launch report.
- Use real testers on a range of devices during closed testing. Different manufacturers, Android versions and screen sizes find different bugs. Our article on real testers on real devices explains why this matters.
- Collect and act on feedback. Crash reports from testers are only useful if someone reads them; see collecting feedback from closed testers.
- Avoid heavy work on the main thread. Network calls, large database queries and big file reads on the main thread are a classic cause of ANRs.
After launch
- Check Android vitals in Play Console daily for the first week or two.
- Sort crash clusters by the number of affected users, and fix the biggest first.
- Look at the per-device breakdown. A crash limited to one manufacturer often points to a vendor-specific behavior.
- Ship fixes through your closed track first, then to production, ideally with a staged rollout once it is available for your app.
Crash reporting tools
Many teams also add a crash reporting SDK for faster, more detailed reports. That is fine and often helpful, but remember:
- vitals in Play Console is what Google uses for its thresholds
- any SDK that collects data must be reflected in your Data safety form and privacy policy
Vitals and production access
Production access is decided on your closed test, not on vitals data. Google asks how you decided the app was ready, and wants apps that are "stable and free from broken functionality, crashes, or missing screens." A stable build is good for both: it helps your application and gives you a healthy start in vitals once real users arrive.
Key takeaways
- Core vitals: user-perceived crash rate and ANR rate.
- Overall thresholds at the time of writing: 1.09% for crashes, 0.47% for ANRs; 8% per phone model.
- Going over may reduce visibility or add a listing warning.
- Small user bases produce noisy numbers; watch trends.
- Fix crashes found by testers and the pre-launch report before launch.
If you are still before production, our guide covers setting up the closed test, and the production access guide covers the application.
