Google Play doesn't just track your crash rate for your own dashboard — it publishes specific numeric thresholds, and crossing them on a given device model can get your app excluded from discovery surfaces on that model. This isn't a vague "quality matters" claim; it's a documented, threshold-based mechanism.
Most ASO advice about "app quality" stays abstract — write good metadata, get good reviews, keep users engaged. Google Play's Android vitals system is more concrete than that: it defines exact bad-behavior thresholds for crash rate and ANR (App Not Responding) rate, evaluated per device model using your last 28 days of data, and exceeding them has a documented visibility consequence, not just a reputational one.
Google's documented thresholds are specific: a user-perceived crash rate above 1.09% overall (averaged across devices) or above 8% on any individual phone model, and a user-perceived ANR rate above 0.47% overall or above 8% on any individual phone model, are treated as "bad behavior." If your app exceeds a threshold on a specific device model, Google Play can reduce visibility specifically for users on that model — excluding the app from some discovery surfaces on that hardware, and in some cases showing a warning directly on the store listing. This is evaluated per device model, using a rolling 28-day window, which means a health problem isolated to one device model can suppress your visibility there while leaving your standing on other models untouched.
Sourced from Google Play Console Help's documented Android vitals thresholds (see footer). Same app, different visibility outcomes per device model.
Status on this device model:
Because Android vitals is evaluated against real user data rather than something you control directly through metadata, it sits outside the normal keyword-and-creative levers most ASO work focuses on — but a visibility reduction from crossing a bad-behavior threshold undermines every other ASO investment simultaneously. A well-optimized listing with strong screenshots and keyword targeting doesn't help you if Google Play has quietly excluded your app from discovery surfaces on a meaningful share of devices. Technical app health is, in this specific and measurable sense, a real ASO input, not just a separate engineering concern.
Directionally true, unverified: Google's public documentation confirms visibility reduction and store-listing warnings as consequences of crossing device-model thresholds, but doesn't fully specify every discovery surface affected or the exact magnitude of the reduction — treat the mechanism as real and the precise scope as not fully public.
A crash is intuitive — the app closes unexpectedly. An ANR (App Not Responding) is less obvious: it's triggered when the app's main thread is blocked long enough that the system considers the app unresponsive, typically because of a long-running operation (a network call, heavy computation, or disk I/O) executed on the main thread instead of a background thread. ANRs are worth treating as a distinct category from crashes in your monitoring, not folding into a single generic "stability" metric, because the underlying causes and fixes differ — a crash points to something raising an unhandled exception, while an ANR points to something blocking responsiveness without necessarily crashing at all. Google tracks them as separate thresholds precisely because they represent different failure modes from a user's perspective, even though both damage the user experience and both factor into the same visibility-suppression mechanism.
Google announced updates to its technical quality requirements in August 2026, with new bad-behavior thresholds taking effect from February 2027, and memory usage being introduced as an additional core vitals metric alongside crash and ANR rate. This matters for planning purposes: if your app currently sits comfortably under the crash and ANR thresholds but has never been evaluated against memory usage as a vitals metric, it's worth getting ahead of that change rather than discovering a new threshold problem after enforcement begins. Google's own vitals dashboards in Play Console are the authoritative place to check current and upcoming requirements, since threshold specifics can shift with policy updates.
Directionally true, unverified: exact memory-usage threshold values for the 2027 enforcement weren't fully detailed in the sources available at the time of writing — verify current specifics directly in Play Console before planning technical work around them.
"SnapNotes," a note-taking app, reviews its Android vitals dashboard. These are illustrative numbers to show the diagnostic process, not real measured data.
| Device model | Crash rate | Threshold | Status |
|---|---|---|---|
| Flagship model A | 0.8% | 8% (per-model) | Healthy |
| Budget model B | 11.2% | 8% (per-model) | Exceeded — likely visibility impact on this model |
| Older model C (low RAM) | 6.5% | 8% (per-model) | Under threshold, but trending up — worth monitoring |
The pattern here — one budget/low-spec model far exceeding the threshold while flagship models look healthy — is common: crash and ANR issues frequently concentrate on lower-memory or older devices, which a team primarily testing on newer hardware can easily miss.
Illustrative distribution for demonstration — actual concentration depends on your app's specific technical profile and target audience.
Since thresholds are evaluated on a rolling 28-day window, the most effective place to catch a developing problem is your release process itself, not a periodic dashboard check disconnected from shipping. A practical pattern: treat crash and ANR rate on your staged rollout percentage as a release gate — if a new release shows an elevated crash or ANR rate on even a small initial rollout percentage, halt the wider rollout and investigate before the regression has a chance to accumulate across the full 28-day window and risk crossing a device-model threshold. This is a meaningfully different posture than checking vitals weekly as a separate reporting task; it treats app health as part of the shipping pipeline itself, catching problems while they're still isolated to a small percentage of users rather than after they've already affected the broader rolling average that Google evaluates.
In many teams, crash and ANR monitoring lives entirely with engineering, while ASO and growth teams focus on metadata, creative, and campaigns — with no shared visibility into whether a technical quality issue is quietly suppressing discovery on a chunk of devices. Closing that gap doesn't require merging the two functions, just a lightweight shared reporting habit: engineering surfaces per-device-model vitals status to the growth team on a regular cadence (monthly is reasonable outside of active incident response), specifically flagging any model trending toward or past a threshold. This turns app health from an invisible constraint that occasionally, mysteriously undercuts a metadata experiment's results into a visible, trackable input that both teams can reason about together — which matters because a growth team debugging a conversion or visibility drop without this context might spend real time testing screenshot variants for a problem that's actually rooted in a crash-rate regression on a specific device tier.
Google Play's Android vitals system enforces specific, documented crash and ANR rate thresholds per device model, and exceeding them can reduce your app's discoverability on that model — a real, measurable ASO consequence, not just an engineering quality concern. Monitor per-device-model data (not just aggregate), pay particular attention to lower-spec hardware where issues concentrate, and treat trending-toward-threshold metrics as worth fixing before they actually cross the line.