An app can pass every test on your desk and still crash on a device you have never held. Manufacturer variations, Android versions, memory pressure, background restrictions and real user behaviour combine in ways a debug build rarely reproduces — and the first evidence often arrives as a one-star review rather than a stack trace.
Android Vitals is Google Play's answer to that gap: quality measurements from real devices, surfaced in Play Console and the Play Developer Reporting API. This guide covers what it measures, which numbers matter, how to read a crash cluster, what an ANR really is, and how to verify a fix.
What Is Android Vitals?
Android Vitals is the technical quality section of Google Play Console. Google describes it as a way to understand and improve an app's stability, performance, battery usage and more, using data from devices whose users opted in to share usage and diagnostics. It can be read in Play Console or through the Play Developer Reporting API.
In one sentence: Android Vitals measures how your app actually behaves on real devices after release, then flags the metrics that can affect your visibility on Google Play.
Signals are grouped by aspect of quality: stability, start-up time, rendering, battery, memory and permissions. A small subset is designated core vitals — the metrics that affect visibility on Google Play. For all apps that means user-perceived crash rate, user-perceived ANR rate and excessive partial wake locks; mobile apps add memory usage and bitmap memory usage; watch faces add excessive battery usage.
Why Android Vitals Matters for App Developers
Three distinct benefits get mixed together, and only the first is a policy matter.
- Visibility. Core vitals carry published bad behavior thresholds. Google states that exceeding one is likely to make your app less discoverable, and that a warning can sometimes appear on the store listing. That is a discoverability consequence, not a rejection.
- Diagnosis. Clusters, stack traces and breakdowns by app version, Android version, device model and country turn "some users crash" into a specific line of code on a specific build.
- Trend. Daily data over weeks shows whether a release improved or regressed quality — something no pre-release test can tell you.
What it does not do: a clean Vitals dashboard guarantees nothing about ranking, featuring or production access. It is a measurement system, not an approval mechanism.
Understanding the Most Important Android Vitals Metrics
The most common misreading is treating crash rate and user-perceived crash rate as the same number. Both are normalised by daily users — someone who used the app that day on one device, so two devices count twice. The user-perceived variants count only issues likely to have been noticed: crashes while a visible activity or foreground service is running, and for ANRs only input dispatching timeouts. That is why they are always the lower number.
| Metric | What it means | Why it matters | What to check |
|---|---|---|---|
| User-perceived crash rate | Share of daily users hit by a crash likely noticed, in a visible activity or foreground service | Core vital; drives Play visibility thresholds | Below 1.09% overall and 8% per phone model |
| Crash rate | Share of daily users hit by any crash, including ones not classified as user-perceived | Wider signal; Google cannot guarantee these did not affect users | Whether a background-only pattern is growing |
| User-perceived ANR rate | Share of daily users who saw a noticed ANR; currently only input dispatching timeouts | Core vital; the freeze happens on screen | Below 0.47% overall and 8% per phone model |
| ANR rate | Share of daily users hit by any ANR, not only foreground ones | Catches service and broadcast timeouts | Which ANR type dominates, and on which devices |
| Memory usage (P90) | 90th percentile of anonymous RSS plus swap, per app state and RAM tier | New core vital; documented visibility impact from February 2027 | Footprint against your RAM tier's threshold |
Thresholds are per metric, and stability ones exist both overall and per device model, so a healthy average can hide one phone model in bad behaviour. Google evaluates them over the last 28 days of data. The published threshold tables are authoritative; re-read them rather than quoting a number from memory.
How to Find Android Vitals in Google Play Console
The documented path, in order:
- Open Play Console and sign in.
- Select the app you want to review.
- In the left navigation, open Monitor and improve.
- Select Android Vitals.
- Open Overview for all metrics by aspect of quality.
- For individual issues, open Crashes and ANRs.
- Set the date range, then filter by app version, device, Android version or country.
The Overview page opens with core vitals, then a Critical issues section covering bad behaviors (metrics past a threshold) and anomalies (a sharp change, such as an ANR spike). Email notifications exist, but Google documents them for anomalies only — thresholds are something you check, not something that pings you.
How to Understand Crash Reports
The Crashes and ANRs page does not list individual reports. It groups them into clusters: crashes that share a likely root cause, each carrying the number of affected users and breakdowns by app version, Android version, device model and country.
Two filters do most of the work. Issue visibility restricted to foreground issues isolates user-perceived clusters, the ones driving the core vital. Artifact (app version) tells you whether a cluster belongs to the release you are shipping now or one you already replaced.
Prioritise by affected users, not by how interesting the bug looks. Google's guidance is to fix the clusters with the highest number of affected users first, and to look at per-device clusters separately when improving quality on a specific model.
Some clusters are marked possibly SDK-related. If the fault sits in third-party code, the report can be shared with the SDK provider, who may add provider notes to your Overview page.
Illustrative example: a cluster shows 1,200 affected users on your latest release. Broken down, 84% are on one Android version and 71% on a single device family, and the first event is dated the day 2.4.0 shipped. Those facts point at what changed in 2.4.0 for that configuration — a much shorter investigation than reading the stack trace cold.
What Are ANR Errors?
An ANR — Application Not Responding — happens when the app's UI thread is blocked for too long, and the system shows the user a dialog offering to wait or close the app. The main thread matters because it draws frames and dispatches input: block it and both stop, so the screen freezes and taps queue up. For an input dispatch ANR the default timeout is 5 seconds, though Google notes the documented defaults apply to AOSP and Pixel devices and can vary by manufacturer.
Common causes, per Android's ANR guidance:
- Blocking I/O on the main thread — database or network calls made synchronously.
- Long-running calculations or expensive frames — heavy work inside a single frame.
- Slow or repeated binder calls — one long synchronous call, or many in a tight loop.
- Lock contention or a deadlock — the main thread waiting for a lock another thread holds.
- Blocked by another component — a broadcast receiver or service holding the main thread.
- GPU hang — a system or hardware fault, with little to fix on the app side.
Resist the tidy explanation that every ANR is a slow UI thread. Google also names system-side causes: transient system server problems, high device load, and slow binder replies. Perfetto traces are the documented way to separate those from app-side faults. Two cluster signatures are usually noise — "nativePollOnce" and "main thread idle" — because the stack was likely captured late or the device was constrained.
How to Prioritize and Fix App Quality Issues
| Priority | Issue pattern | Suggested action |
|---|---|---|
| P1 | A core vital at or over its threshold, or any cluster blocking a core journey such as sign-in or checkout | Stop feature work. Reproduce, fix, ship, and watch the metric daily |
| P2 | The largest cluster by affected users that is not yet over a threshold | Schedule into the current cycle; widest impact per hour of work |
| P3 | A per-device or per-version cluster, or one that only affects an older release | Batch with related work; verify on the affected model before closing |
| P4 | Low-volume clusters, "main thread idle" signatures, and code you cannot change | Watch the trend; escalate SDK issues to the provider |
Investigate causes rather than symptoms. A catch block may remove a crash from the dashboard while leaving the broken state behind, and ANRs have a habit of resurfacing as something worse. When both an overall and a per-device problem exist, Google's advice is to fix the largest overall clusters first.
Developer tip: sort clusters by affected users, not by how alarming the stack trace looks. A dull null pointer affecting 4,000 people beats an exotic race condition affecting nine.
How to Retest After Fixing a Crash or ANR
- Identify the issue from the cluster, not a single report.
- Investigate the details — stack trace, versions, device and Android version patterns.
- Fix the root cause, not the symptom.
- Prepare a new build with a version you can recognise in the Artifact breakdown.
- Test the affected scenario on the build you intend to ship.
- Test on the affected devices or Android versions, not only your own phone.
- Monitor the metric again after release, using the version breakdown to separate old events from new.
Vitals data is aggregated and arrives with delay, so it confirms a fix rather than testing one. Structured real-device testing closes that gap: a tester on the affected model can reproduce the scenario within minutes and tell you whether the build is fixed before you wait for field data. The real device testing guide covers how to choose those devices, and the bug report guide covers the feedback format that makes the result actionable.
Android Vitals vs. Manual Testing and Other Testing Tools
| Method | Main purpose | Best used for |
|---|---|---|
| Android Vitals | Measure field quality from opted-in devices | Knowing which problems are real, how many users they reach, and whether a release helped |
| Manual testing | Explore behaviour and judge usability | New features, edge cases, anything needing human judgement |
| Real-device testing | Reproduce on the hardware that fails | Confirming a fix for a device-specific cluster before release |
| Automated testing | Prevent regressions repeatably | Logic that should never break again, run on every change |
| Firebase Test Lab | Run automated tests across many devices | Device breadth without owning the hardware |
These do not replace each other. Vitals tells you where the fire is; manual and real-device testing tells you why; automated tests keep it from starting again. Play's pre-launch report sits in between.
Why Android Vitals May Show No Data
An empty dashboard is usually not a bug. Google documents several reasons data may be absent:
- Not enough data points for the selected filters. Play Console states that if no data is available, the app lacks enough data points to identify issues.
- Opt-in is required. Data comes only from users who share usage and diagnostics, and from a subset of devices and OS versions.
- Eligibility limits. Vitals excludes uncertified device models and versions not installed through Google Play.
- Filters. A narrow date range, a single country, or a low-install app version can empty the view.
- Lag and retention. Data updates daily, Android 10+ can arrive first, Console keeps 90 days and the API three years.
Important: Android Vitals does not represent every issue from every installation. It is a sample of eligible, opted-in devices, so a clean dashboard means no measured problem — not a guarantee that no user is affected.
Android App Quality Monitoring Checklist
A weekly routine for a team shipping regularly:
- Open Android Vitals on a fixed day each week, not only after a bad review.
- Check core vitals against their thresholds, overall and per device model.
- Review new and growing crash and ANR clusters.
- Break clusters down by app version to separate new events from old ones.
- Note any device model or Android version that concentrates the problem.
- Fix the highest-impact issue before starting the next one.
- Read the stack trace or ANR details before forming a hypothesis.
- Retest the exact scenario on the affected build and device.
- Watch the same metric for a week after release.
- Keep a record of recurring issues so patterns surface across releases.
Frequently Asked Questions
What is Android Vitals in Google Play Console?
The technical quality section of Play Console, showing stability, performance, battery, memory and permission metrics from opted-in devices.
Does Android Vitals show all app crashes?
No. It covers opted-in users on certified devices and Play-installed versions — a large sample, not a complete record.
What is the difference between a crash and an ANR?
A crash ends the process unexpectedly. An ANR leaves the app running but unresponsive because the main thread is blocked, so the system offers a wait-or-close dialog.
Where can I find crashes in Play Console?
Under Monitor and improve → Android Vitals → Crashes and ANRs, where clusters link to stack traces and device, version and country breakdowns.
Why is Android Vitals showing no data?
Usually too few eligible data points for the selected filters. Check the date range and filters, and remember Console keeps only 90 days.
Do Android Vitals affect Google Play discoverability?
Core vitals do. Exceeding a bad behavior threshold is likely to make an app less discoverable and may add a store warning. It is not an approval decision.
How often should developers check Android Vitals?
Weekly is enough for most teams, plus a check within 48 hours of each release, when regressions are most likely.
Can real-device testing help reduce app quality problems?
Yes — Vitals shows where quality is failing, and real-device testing reproduces the failure so it can be fixed and verified.
Official Resources
Every Google statement in this article comes from these pages.
- Monitor your app's technical performance with Android vitals — metrics, breakdowns, data collection
- View crashes and application not responding errors — the Crashes and ANRs page, filters, SDK issues
- Android vitals on Android Developers — core vitals and the bad behavior threshold tables
- Diagnose and fix ANRs — ANR types, timeout defaults, common causes
- Address common performance issues — stability, rendering, memory and battery
- Memory and quality requirements — how Play evaluates memory metrics
Conclusion
Android Vitals answers a question no test plan can: what is actually happening to your app in the field. Core vitals tell you whether you are inside the thresholds that affect visibility, clusters tell you where to look, and trends tell you whether the fix worked.
The habit that separates teams who improve quality from teams who only react is boring: open the dashboard on a schedule, fix the largest cluster, and verify on the device that failed rather than the one on your desk. The closed testing checklist covers the surrounding release steps. TestersHQ works with developers who want quality signals and real-device validation in the same release cycle.
