Google Play does not judge your app on policy compliance alone. Android vitals has become the store's official technical quality signal, and its core metrics feed directly into how visible your title is in search and browse. Exceed a bad behavior threshold and Play may reduce your app's visibility and show shoppers a warning on your store listing. The good news is that these are the most predictable rules on the entire platform: the thresholds are published, the measurement window is known, and every step below maps to a documented number.

What you are solving today: the exact bad behavior thresholds, where each metric lives in Play Console, the 28-day window that decides your fate, how to automate monitoring through email alerts and the Developer Reporting API, the fix order that actually moves the numbers, and the memory, bitmap and DEX thresholds that begin affecting store visibility in February 2027.

1. The thresholds you are measured against

Google separates five core vitals because they affect your app's visibility on Google Play: user-perceived crash rate, user-perceived ANR rate, excessive partial wake locks, memory usage, and bitmap memory usage. The stability pair is where most developers first get flagged.

Read the wording carefully. The overall numbers are averages across all devices, so a single bad phone model cannot sink you on its own — but it can, because the per-model threshold is 8%, which is roughly seven times looser than the overall bar. That asymmetry tells you exactly where to look first: fix what hurts the most users, then clean up the device-specific clusters. Google's own guidance is explicit: if you have both an overall and a per-device problem, attack the largest overall crash and ANR clusters first. The full threshold table lives on the Android vitals documentation page.

2. Step 1 — Read your own numbers in Play Console

The data is not in your build; it comes from Android devices. When a user allows it, their device reports stability, performance, battery and permission metrics back to Google, and Play aggregates them into the Android vitals dashboard in Play Console. You do not need to instrument anything to see it, but you do need to know what is missing from it: Android vitals only counts certified devices running apps installed from Google Play, and only from users who agreed to share diagnostic data. Clusters are hidden until there is enough data for anonymous reporting, which means small apps and brand-new releases look emptier than they really are.

Start from the vitals overview, then open Crashes and ANRs and sort by the number of users affected rather than by raw error count. Play's device side panel gives you user numbers, revenue, ratings and reviews for each device so you can judge whether a cluster is worth your week. When a cluster points at hardware or firmware rather than your code, the right answer can be device targeting and exclusion rules instead of a hotfix.

3. Step 2 — Understand the measurement window before you panic

Play assesses your app's quality using the last 28 days of data and recalculates your key performance indicators daily. Two consequences follow. First, a release that fixed a crash wave will not clear the warning overnight: the bad days stay in the average until they age out. Second, a slow bleed is invisible in any single day, which is why you should watch the trend, not the value.

There is also a deliberate grace period. Android vitals flags emerging issues — problems affecting devices for more than seven days for crashes and ANRs — and that flag gives you 21 days to address them before the issue escalates. Treat day seven as your alarm and day twenty-one as your hard deadline, not the day you start investigating.

One more definition worth knowing before you argue with your analytics vendor: a user session is the sum of usage activity in a 24-hour period starting at midnight Pacific Time. Android vitals reports issues per daily active user, while SDK-based crash reporters usually count per session. If a user opens your app three times in a day and crashes once, Android vitals records a 100% crash rate for that user while a third-party tool reports 33%. That difference is arithmetic, not a bug.

4. Step 3 — Automate the monitoring (alerts plus the reporting API)

Manual dashboard checks fail on the days you are busy. Two mechanisms exist and you should use both:

  1. Email alerts in Play Console. Register your operations address so a regression reaches a human the day it appears, not at your next monthly review.
  2. The Google Play Developer Reporting API. It exposes the same metrics programmatically, which is what you want if you run more than a couple of titles. Pull crash rate and ANR rate per package on a schedule, store history, and alert only on change instead of on absolute value.

Alerts alone will not save a portfolio. What saves it is a threshold you commit to in advance: write down the number at which you stop shipping features and start fixing stability, and automate the check so the decision is not a matter of mood.

5. Step 4 — Fix the biggest crash clusters first

  1. Make the stack traces readable. If you obfuscate with R8, upload the mapping file. An unreadable trace is a crash you cannot fix.
  2. Group by root cause, not by report. One null dereference in a cold-start path can produce thousands of events across dozens of device models. Fix the cause, and the cluster collapses.
  3. Use the tooling you already have. Android Studio's App Quality Insights surfaces Android vitals reports inside the IDE, and from Android Studio Meerkat onward its Insights tab uses Gemini to summarise a crash, propose next steps and link to documentation — most useful when you also give it local code context.
  4. Ship the fix through a staged rollout. If you are already using percentage releases, hold at a small share until the crash rate for that release is flat, then expand.

6. Step 5 — Drive the ANR rate down

ANRs are almost never random. They are main-thread work: disk access, synchronous network calls, large JSON parsing, bitmap decoding or a broadcast receiver that does too much before returning. Audit the code paths that run during startup and on lifecycle callbacks first, since those block the app while the user is watching. Then use StrictMode in internal builds to catch the ones you cannot see by reading. ANR rate and crash rate are judged separately with different thresholds, so being comfortable at 1% crash rate buys you nothing here — 0.47% is the bar.

7. Step 6 — Keep partial wake locks under 5%

Excessive partial wake locks are the classic background-service signature: a lock held to keep a socket or a sync loop alive. Replace the pattern with WorkManager or JobScheduler so the platform schedules your work, and release any lock you still need through a try/finally block, because a lock leaked by an exception is held until the process dies. This metric is measured as one overall number with no per-device escape hatch, so one careless SDK can flip your whole app into bad behavior by itself — including an advertising or analytics SDK you did not write.

8. Step 7 — Bank the February 2027 deadlines early

Stability is not the only door into reduced visibility anymore. Google states that apps exceeding the thresholds for memory usage, bitmap memory usage, or code optimization may see store visibility impact starting from February 2027. The three metrics work differently, and all three have numbers attached:

Which means: turning off R8 to make debugging easier is now a business decision with a dated bill attached. Check what the RAM tiers your actual users carry imply, and verify that code optimization is enabled and delivering its 25% before February 2027 rather than during it.

9. Step 8 — Confirm recovery, then keep the guardrails on

  1. Wait for the average, not the release. Warnings clear when the 28-day average improves. Play may drop store listing warnings faster if its systems detect improvement, but do not plan around that.
  2. Re-check per-device views after the fix. Overall numbers can look clean while one model still sits above the 8% bar.
  3. Know why your numbers differ from other tools. Android vitals sees crashes before an SDK initialises and ANRs on older Android versions, counts per daily active user and covers certified devices only. Different denominator, different rate.
  4. Keep the alerts on after the crisis. The failure mode that hurts is the quiet one: a new SDK added in a feature release, a background service that grew, a bitmap cache that never shrinks.

What this means if you run a portfolio

Quality is the one part of a Play account that compounds silently. A single app sitting above the ANR threshold does not just lose its own organic traffic — it trains Play's systems to treat the whole developer account as a lower-quality source. If you operate several titles under one account, put the vitals checks in your release checklist and your monitoring cron, treat the emerging-issue week as a stop-ship signal, and keep the February 2027 memory and DEX thresholds on the calendar now, while they are cheap.

Sources