Android Vitals: What the Numbers Mean and What to Fix First

What Android vitals actually measures

Android vitals is the technical quality reporting Google Play builds from data collected on users' devices. Google Play collects it, and you can read it two ways: in the Android vitals dashboard in Play Console, or through the Play Developer Reporting API. The two do not retain data for the same length of time: Play Console shows the previous 90 days, while the Reporting API goes back three years.

It is worth reading closely, because these numbers are not merely advisory. If your app exceeds a bad behaviour threshold, Play may reduce your title's visibility, and may show users a warning on your store listing to set expectations. If you want the wider picture of how testing and visibility interact across the store, our review of the state of Google Play closed testing covers that side.

Which metrics count as core vitals

Not every figure in the dashboard carries the same weight. Google's core vitals, grouped as Google groups them:

• Stability (all apps): user-perceived crash rate, user-perceived ANR rate
• Battery: excessive partial wake locks (all apps), excessive battery usage (watch face apps)
• Memory (all mobile apps): memory usage (anonymous RSS plus swap), bitmap memory usage

Those are the metrics that affect visibility. Alongside them, Android vitals surfaces a longer list of alerting metrics: excessive wakeups, stuck partial wake locks, excessive background Wi-Fi scans, excessive background network usage, app startup time, slow rendering, slow sessions, low memory killers (LMKs) and permission denials. These matter to your users, but they are not the headline thresholds.

The bad behaviour thresholds

The stability and battery figures are published directly. To maximise your title's visibility on Google Play, keep it under these (developer.android.com):

Metric	Overall (average across devices)	Per phone model	Per watch model
User-perceived crash rate	1.09%	8%	4%
User-perceived ANR rate	0.47%	8%	5%
Excessive battery usage	1%	-	1%
Excessive partial wake locks	5%	-	-

A dash means Google publishes no threshold for that combination. Read the per-device column carefully. Google defines a per-device bad behaviour as, for example, "at least 8% of daily active users experience a user-perceived ANR for a single-device model". That is a different measurement from the overall average, and the two thresholds can be breached independently.

The memory thresholds change with hardware

Memory is the part most developers never look at, and it has no single number. Google sets a different threshold for each device RAM tier and each app state, and the values differ again between apps and games. For a non-game app, the foreground ceiling rises with the device: 2.00 GB at the 4 GB tier, 2.25 GB at 6 GB and 8 GB, 3.25 GB at 12 GB, and 4.25 GB at 16 GB. The user-perceived and services states carry lower ceilings than foreground, rising from 1.00 GB at the 4 GB tier to 2.00 GB at 16 GB. Games are allowed considerably more at every tier.

Two details are easy to miss. The 0 to 4 GB tier and the 16 GB and above tier have no memory threshold published at all, so a low-end or very high-end device will not flag here. And bitmap memory usage is measured separately: 200 MB in the foreground, user-perceived and services states, and 400 MB cached.

One caveat that affects your device targeting: Google defines each tier by the usable memory available to apps, not the advertised figure. Usable RAM varies because of hardware carve-outs and differences between advertised and actual memory, so a device you think is in the 8 GB tier may not be measured there.

One threshold you must stay above, not below

DEX code optimisation inverts the logic. Every other metric on this page is a ceiling; this one is a floor. If your app ships more than 10 MB of DEX code (more than 50 MB for a game), Google's requirement is that optimisation, obfuscation and shrinking account for a minimum of 25%. Google's own wording is to keep it above the threshold.

A February 2027 deadline worth knowing now

Google states plainly that apps exceeding the thresholds for memory usage, bitmap memory usage, or code optimisation may see store visibility impact starting from February 2027. Stability and battery have been enforced for years; the memory and DEX metrics are on a later clock. If your app has never been measured against them, that is the reason to start.

How Play assesses you, and how long a fix takes to show

This is where most explanations stop, and it matters for planning:

• Play checks your key performance indicators daily, using a 28-day average. When that average improves, the Android vitals warnings disappear. Store listing warnings may be removed sooner if Play's system detects improvement.
• Android vitals flags emerging issues: problems affecting devices for more than 7 days on crashes and ANRs. Google frames this as giving you 21 days to address them before the situation is fully reflected.

The practical consequence: a fix you ship today is diluted by up to four weeks of historical data. A rate that looks stubbornly unchanged a few days after a release is usually the 28-day window, not a failed fix.

Why the numbers differ from your own crash reporting

If you run a third-party crash tool, expect a mismatch, and do not assume either side is wrong. Google lists the reasons:

• Android vitals data comes from the Android system and includes events SDKs do not see, such as crashes before SDK initialisation and ANRs before Android 12.
• It only counts issues from certified devices and apps installed from Google Play.
• It only uses data from users who agreed to share it, and Play only reports figures once there is enough data to keep reporting anonymous.
• Issue rates may be calculated differently between the two systems.

This is also why vitals is not a substitute for your own instrumentation, and why your instrumentation is not a substitute for vitals. One sees the system, the other sees your code.

The triage order that wastes the least time

Google states that all combinations of overall and per-device bad behaviour are possible, and gives this priority order directly:

1. To improve app quality overall, fix the crashes and ANRs affecting the most users.
2. For better quality on specific devices, fix the biggest crash and ANR groups on those devices.
3. If you have both, focus first on the largest overall crash and ANR clusters.

Two console features do the sorting for you. The Critical issues section separates bad behaviours (metrics over threshold) from anomalies (significant changes, such as a sharp rise in the user-perceived ANR rate). And when many devices show problems, vitals highlights possible links to RAM, Android version and processor type, which is often a hardware or OEM issue rather than your code. If you are still assembling a group to test with, our breakdown of what testers actually do during closed testing explains what vitals will and will not see from a small, early cohort.

What Android vitals cannot tell you

• It will not tell you that a tester never opened your app. That is not a crash or an ANR, so it is invisible here; the reasons a closed test stalls or fails are worth reading separately.
• It will not explain the cause. It gives you the cluster and the stack trace; the diagnosis is still yours.
• It says nothing about your listing, screenshots or title.
• It cannot be configured by notification for threshold breaches. Google notes that Play Console notifications are currently only available for anomalies, not for bad behaviours, so a metric quietly crossing its threshold will not email you. Check the dashboard or pull the Reporting API on a schedule instead.
• Rates are sensitive to sample size. A small daily active user base produces noisy percentages, and one low-volume device model can dominate the per-device figure.

Frequently asked questions

What is a good user-perceived crash rate?

Google's overall bad behaviour threshold is 1.09%, averaged across devices. Keep the app under it to maximise visibility on Google Play. It is a ceiling, not a target.

Why is my per-device rate over 8% when the overall figure looks fine?

They are separate measurements against separate thresholds. The overall number averages across all devices; the per-device number is calculated for a single model. A handful of affected users on a low-volume model can cross 8% while the overall average stays under 1.09%.

Does crossing a threshold remove my app from Google Play?

No. Google's documented consequence is reduced visibility, plus a possible warning on your store listing. Removal and suspension are separate enforcement actions.

How long after a fix do the warnings disappear?

Play recalculates daily using a 28-day average, and warnings clear when that average improves. Store listing warnings may be removed sooner if the system detects improvement. Budget up to four weeks for a fix to be fully reflected.

What are emerging issues?

Problems affecting devices for more than 7 days on crashes and ANRs. Google describes this as giving you 21 days to address them, which is the real warning window before a bad behaviour is fully established.

Why does Android vitals show ANRs my crash tool misses?

Android vitals reads from the Android system and includes events SDKs cannot see, including ANRs before Android 12 and crashes before SDK initialisation. It also only counts certified devices and Google Play installs, from users who opted into sharing.

Do I need to worry about memory and DEX for now?

They are not enforced on the same schedule as stability. Google states that apps exceeding the memory, bitmap memory, or code optimisation thresholds may see visibility impact from February 2027. Measuring early is cheaper than discovering a problem in 2027.

Do vitals matter during closed testing?

Only cautiously. A closed test has a small, unrepresentative user base, so percentages are volatile, and vitals becomes genuinely useful once you have a broad installed base.

Sources

• Android vitals: bad behaviour thresholds, memory tiers, core vitals FAQ (developer.android.com)
• Android vitals overview (developer.android.com)
• Monitor your app's technical quality with Android vitals (Play Console Help)
• ANRs (developer.android.com)
• Crashes (developer.android.com)