In this guide
Android vitals is Google's dashboard of technical quality data for your app, collected from real devices in the field. It sits in Play Console. For a small team the sensible approach is to watch a few numbers, understand what they mean, and use them to decide what to fix first.
The core metrics
Google's Android developer documentation lists these as the most important vitals:
- Stability: user-perceived crash rate and user-perceived ANR (Application Not Responding) rate.
- Battery: excessive partial wake locks.
- Memory: memory usage and bitmap memory usage.
Start with stability. Crashes and ANRs are the numbers most developers can act on directly.
Thresholds, and why they matter
The same documentation names "bad behavior" thresholds. To maximize visibility on Google Play, keep these under:
| Metric | Overall (average across devices) | Per phone model |
|---|---|---|
| User-perceived crash rate | 1.09% | 8% |
| User-perceived ANR rate | 0.47% | 8% |
If you exceed a threshold, Google says Play may reduce your app's visibility and may show a warning on your store listing. Thresholds can change, so check the current page before you quote them.
Two readings are worth keeping apart: the overall rate tells you whether the app is healthy on average; the per-model rate tells you whether one device family is badly broken even though the average looks fine.
Where to look
Crash and ANR data appears in the Android vitals dashboard in Play Console. The same data is available through the Google Play Developer Reporting API. To investigate a device-specific problem, Google points to Reach and Devices in Play Console.
Vitals plus tester reports
Vitals tells you that something fails and how often. It rarely tells you what the person was doing. A tester report fills that gap.
- Spot a spike in vitals after a release.
- Ask testers on the affected device type to repeat the main flows and note exact steps.
- Match their steps to the stack trace in the vitals clusters.
- Fix, then watch the number after the next release.
Vitals reflects released builds, so it cannot replace testing before a release. It also has little to say for a brand-new app with few users: small samples make percentages jump around. In that phase, tester feedback carries more weight.
Turning numbers into priorities
- Fix crash clusters that hit the most users first. See how to prioritize crash reports.
- Treat ANRs as a separate problem with separate causes (blocked main thread, slow I/O). See Android ANR errors.
- Check a model-specific spike on a real or similar device before changing code.
- Write the number down at each release, so you can see whether a change helped.
Part of the Android app testing guide. Related: cloud device tests vs real testers and the Android release checklist.
Want testers to reproduce a problem on their own phones? Start free and collect private, structured feedback.