Android vitals bad behavior thresholds are the lines Google Play uses to decide whether your app is technically healthy enough to recommend. The two that matter most are a user-perceived crash rate of 1.09% and a user-perceived ANR rate of 0.47%, both measured over the last 28 days. Cross either one and Google Play may show your app to fewer people. Cross the per-device version, 8% on a single phone model, and users on that phone can see a warning on your store listing before they install.
Those two numbers have been stable since late 2022, but the list around them has grown. A battery threshold became enforceable on March 1, 2026, and on August 26, 2026 Google announced memory and code optimization thresholds that start affecting visibility in February 2027. This guide covers every current threshold, how each one is measured, what crossing it costs, how long recovery takes, and what a solo developer should fix first.
What are the Android vitals bad behavior thresholds?
The Android vitals bad behavior thresholds are a 1.09% user-perceived crash rate, a 0.47% user-perceived ANR rate, and excessive partial wake locks in 5% of sessions, each measured across all devices over 28 days. Crash and ANR rates also carry a per-device threshold of 8% on any single phone model.
Google calls the metrics that carry these thresholds core vitals, and its documentation is direct about why they are separated from everything else: core vitals affect your app's visibility on Google Play. Here is the full set as of October 2026:
| Core vital | Overall threshold | Per-device threshold |
|---|---|---|
| User-perceived crash rate | 1.09% of daily users | 8% per phone model, 4% per watch model |
| User-perceived ANR rate | 0.47% of daily users | 8% per phone model, 5% per watch model |
| Excessive partial wake locks | 5% of user sessions | None |
| Excessive battery usage (watch faces only) | 1% | 1% per watch model |
| Memory usage and bitmap memory | Limits vary by device RAM. Visibility impact starts February 2027. | |
Everything else in Android vitals is informational. Slow startup (a cold start of 5 seconds or more, a warm start of 2 seconds or more), slow rendering, excessive wakeups, and permission denials are tracked and worth fixing, but none has a published visibility penalty attached.
What counts as a user-perceived crash or ANR?
A user-perceived crash is one that happens while your app is displaying an activity or running a foreground service, so the user probably noticed it. A user-perceived ANR is currently an input dispatching timeout, where the app fails to respond to a touch or key press within 5 seconds. Background failures are tracked separately.
The word "rate" trips people up. Both metrics are the percentage of daily active users who hit at least one such failure that day, not a percentage of sessions or launches. A user whose app crashes six times on Tuesday counts once for Tuesday, so one unlucky power user cannot drag your number over the line alone.
Two details narrow the definition in your favor. A crash inside a background sync job, with no activity on screen and no foreground service running, shows up in the plain crash rate but not in the user-perceived one. And although Android raises ANRs for several reasons (a service that takes too long to start, a broadcast receiver that overruns, a foreground service that never calls startForeground), Play Console's own help page says the user-perceived rate currently counts only the "input dispatching timed out" type. The others still deserve a fix. They are just not what Google Play is grading.
The data comes from users who have opted in to share usage and diagnostics, on a subset of Android devices and OS versions. It is a sample, which matters for small apps.
What happens when your app crosses a threshold?
When an app crosses an overall bad behavior threshold, Google Play may reduce its visibility across discovery surfaces for every user. When it crosses the 8% per-device threshold, the reduction applies to users on that phone model, and Google Play can show a warning on the store listing saying the app may not work properly on their device.
The per-device warning has been live since November 30, 2022, the date Google set when it introduced the current thresholds. The battery version is newer. Since March 1, 2026, an app over the wake lock threshold can be excluded from prominent discovery surfaces such as recommendations, and its listing can carry a warning that the app may cause excessive battery drain.
This is not a policy strike, and your app is not suspended or removed. Google's wording is "may" throughout, and it has never published how large the visibility reduction is. The surfaces it names are recommendations and discovery placements, which is exactly where an app without brand recognition gets found. Stability is one of the quality inputs described in how Google Play's search algorithm works, and it is the only one you can fix without touching your listing.
A store listing warning is the expensive outcome. It appears at the moment a user is deciding whether to install, on the exact device where your app is failing, and no amount of keyword work or screenshot polish offsets it.
How long does it take to recover after a fix?
Recovery takes up to 28 days, because Google Play assesses quality on the last 28 days of data. A fix does not reset the number. Each day after the fixed release adds one clean day and drops one bad day, so the rate falls gradually and crosses back under the threshold partway through the window.
A worked example makes the timing concrete. Say a bad release pushed your user-perceived crash rate to 2.5%, and the fix brings the daily rate down to 0.3%. Treating the 28-day figure as a simple average of daily rates, the number after d days is 2.5 minus (2.2 × d ÷ 28). That drops below 1.09% on day 18. Google does not publish its exact aggregation, so treat this as an estimate, but the shape holds: a serious regression costs you two to three weeks of reduced standing even when you fix it the same afternoon.
Users do not all update at once, so the daily rate keeps some of the old version's crashes until adoption catches up, which stretches the timeline further. The practical lesson runs the other way: the cheapest regression is the one you catch at a 5% staged rollout, before the bad days enter the window at full weight. The target API level guide walks through that staged approach, and IOn Emit lets you set the rollout percentage for each release track from your desktop.
Do small apps need to worry about Android vitals?
Small apps do need to watch Android vitals, but the data behaves differently at low volume. Android vitals only reports a metric once enough opted-in users have generated data, so a new app may show nothing at all. Once numbers appear, a small user base makes them volatile, and one bad release can cross a threshold.
The arithmetic is less forgiving than the percentages look. An app with 100 daily active users generates 2,800 user-days in a 28-day window. The crash threshold of 1.09% works out to about 30 of those user-days containing a visible crash, roughly one affected user per day. The ANR threshold of 0.47% is about 13 user-days, fewer than one every two days. One slow database query at startup, freezing a handful of older phones, is enough.
The per-device threshold is where small apps get caught most often. Your overall rate can be fine while one phone model with a quirky OS build fails constantly. If 25 of your users are on that model and 2 of them crash each day, you are at 8% for that device. This is one reason the closed testing period with 12 testers is more useful than it feels: it is your chance to see device-specific failures before they count against a public listing.
What changes in February 2027?
From February 2027, memory usage, bitmap memory usage, and DEX code optimization join the thresholds that can affect visibility on Google Play. Google announced the change on August 26, 2026. Memory is judged at the 90th percentile against limits that vary by device RAM, and large apps need at least 25% code optimization coverage.
The announcement frames this as a response to hardware supply constraints on device memory. The memory metric is anonymous RSS plus swap, meaning the private memory your process holds, including the compressed portion. These are the published limits for apps (games get higher ones), from the Play Console technical quality requirements:
| Device RAM | Foreground | User-perceived services | Background |
|---|---|---|---|
| 4 GB | 2 GB | 1 GB | 1 GB |
| 6 GB | 2.25 GB | 1.25 GB | 1.25 GB |
| 8 GB | 2.25 GB | 1.5 GB | 1.5 GB |
| 12 GB | 3.25 GB | 1.75 GB | 1.75 GB |
| 16 GB | 4.25 GB | 2 GB | 2 GB |
Bitmap memory has its own limits at the 90th percentile: more than 200 MB while running user-perceived services or in the background, and more than 400 MB while cached. There is no foreground bitmap limit. The memory rules apply to phones and tablets only.
The code optimization rule applies to apps with more than 10 MB of DEX code and games with more than 50 MB, and asks for a minimum of 25% coverage across optimization, shrinking, and obfuscation. In practice that means building release variants with R8 enabled. Most small apps fall under the 10 MB line.
One wording difference deserves attention. For crashes and ANRs, Google talks about visibility. For the 2027 requirements it says that not meeting them can affect "visibility and publishing capabilities", which suggests an over-limit app could eventually have trouble shipping updates.
How do you check your Android vitals in Play Console?
To check your Android vitals, open your app in Play Console and select Android vitals, then Overview. The page lists each core vital with your 28-day rate beside its bad behavior threshold and flags any metric that exceeds it. The Crashes and ANRs page groups failures into clusters with stack traces and affected devices.
A monthly check takes about ten minutes if you do it in this order:
- Read the overview. Compare your user-perceived crash rate and ANR rate to 1.09% and 0.47%.
- Check per-device status. Android vitals warns you when a specific phone model exceeds 8%. Note the model and Android version.
- Open Crashes and ANRs. Sort clusters by affected users over the last 28 days, and filter by app version to separate a new regression from an old problem.
- Look at the battery section. The excessive partial wake locks metric includes a table of wake lock tags with their P90 and P99 durations.
- Look at memory. The new memory metrics and an out-of-memory filter on the Crashes and ANRs page began rolling out with the August 2026 announcement.
Do not rely on email to tell you. Play Console's help page states that notifications are currently only available for anomalies, meaning sudden changes. A rate that creeps upward over three releases may never trigger one. For real alerting, the Play Developer Reporting API exposes the same metrics to scripts. For everything else in the console worth a recurring look, see the solo developer's guide to Play Console.
How do you get back under the thresholds?
To get back under a bad behavior threshold, fix the largest cluster first. In most apps a few clusters on the Crashes and ANRs page account for the bulk of the rate. Ship the fix through a staged rollout, confirm the new version's numbers are clean, then release to everyone and let the 28-day window clear.
Crashes
Google's own documentation notes that null pointer exceptions are the largest cause of app crashes on Google Play, so start with the unglamorous candidates: a view accessed after its fragment was destroyed, a null result from an intent or a network call, a lifecycle callback that fires after teardown. Use the device and Android version filters to tell a general bug from a device-specific one.
ANRs
Nearly every input-timeout ANR comes down to the main thread being busy or blocked: disk or network I/O, a long calculation, a synchronous binder call to a slow process, or lock contention with a background thread. Enable StrictMode in debug builds to catch accidental main-thread I/O, and move the work onto coroutines or WorkManager. On Android 11 and higher, ApplicationExitInfo lets your app read why its previous process died, including ANR traces.
Wake locks
A session counts as excessive when all partial wake locks together run for 2 or more hours in a 24-hour period, and Google suggests investigating any wake lock tag with a P90 or P99 duration above 60 minutes. Only time held in the background or under a foreground service counts. Wake locks created by audio playback, location, and user-initiated JobScheduler APIs are exempt. The usual culprit is a lock acquired manually and never released on an error path. Release in a finally block, or let WorkManager manage the lock.
Memory
Release bitmaps and caches when your UI is no longer visible, and respond to onTrimMemory. Background and cached states are where the 2027 limits are tightest.
Clean numbers compound with the rest of your store work. Fewer crashes means fewer one-star reviews, which feeds the rating side covered in getting more app reviews, and a stable app is a precondition for anything in the Google Play ASO guide to work.
The takeaway
The Android vitals bad behavior thresholds are short enough to memorize: 1.09% for user-perceived crashes, 0.47% for user-perceived ANRs, 8% for either on a single phone model, and 5% of sessions for excessive partial wake locks, all over a rolling 28 days. Memory and code optimization limits join them in February 2027.
Crossing a line does not get your app removed. It gets it recommended less, and in the per-device and battery cases it can put a warning on your listing. Because the window is 28 days, a regression costs weeks even after a same-day fix, which is the argument for staged rollouts and a ten-minute monthly check.