Device-Specific Android Vitals Triage: Crash and ANR Runbook

Device-specific triage isolates a reliability failure that disproportionately affects one hardware or software cohort, then proves cause and recovery for that cohort. It begins after the global dashboard and ends only when production evidence shows the signature has fallen.

The unit is affected users or sessions on a specific app version and cohort, not raw event count. One looping user can create thousands of events; one fatal first-launch crash can affect many users once. Preserve the exact Play filters and observation window.

• Scope: Fix app version, date range, release track and metric definition. Avoid comparing different populations.
• Signature: Group by exception, stack, ANR cluster or behaviour. Confirm symbolication and mapping files.
• Cohort: Cut by model, Android version, form factor and country. Look for shared hardware or OEM software.
• Impact: Count users, sessions and core-task exposure. Revenue and acquisition reach affect urgency.

Decision rule: Call an issue device-specific only when the cohort has meaningful exposure and materially worse risk than comparable cohorts.

Scope the cohort before you form a hypothesis, because Play Console aggregates by default and an aggregate rate can look acceptable while one model sits far above it. Fix the cohort definition — model, Android version, app version and date window — and save it, so every later comparison uses the same denominator. Changing two filters between readings is the most common way a team convinces itself a fix worked. Google's Android vitals documentation defines the user-perceived metrics the Play ranking and discoverability systems actually consume, which is why third-party dashboards are a supplement rather than a substitute.

Save a baseline cohort definition before changing filters. The Android vitals thresholds guide covers the full metric and discoverability picture.

Use Google’s core-vital thresholds as store-health guardrails while setting stricter internal limits for valuable or safety-sensitive journeys. Google’s Android vitals documentation lists 1.09% overall and 8% per-device for user-perceived crashes, and 0.47% overall and 8% per-device for user-perceived ANRs.

The thresholds are not quality targets. Reaching 7.9% of users on a handset is still catastrophic. Core vitals can affect Play discoverability, and Play generally evaluates recent windows, so delay has both user and acquisition cost.

• User-perceived crash: Track users experiencing at least one crash during active use. Compare with crash-free users carefully.
• User-perceived ANR: Track users experiencing at least one foreground ANR. Inspect cluster cause and main-thread state.
• Per-device threshold: Treat 8% as a critical ceiling, not permission. Set earlier alerts.
• Business guardrail: Weight cohort size, market importance and journey severity. A payment crash deserves faster action.

Decision rule: Respond before the Play threshold when the affected cohort is material; store enforcement is the last warning, not the first.

Translate each threshold into an absolute user count for your own install base before deciding whether it is urgent. A rate that sits just inside the bad-behaviour threshold on a model with two hundred thousand daily users is a materially larger problem than the same rate on a model with two thousand, and the two deserve different responses. Keep both numbers on the dashboard. Android's ANR documentation is explicit that the metric counts affected users rather than events, so a single user hitting the same ANR forty times moves the number far less than intuition suggests.

Document the exact Google definition, because third-party crash tools may count sessions or events instead of users. Poor vitals also raise your acquisition costs.

Start from a signature or release regression, then compare model-level affected-user rate and volume against the same version’s baseline. Sorting by event count alone favours popular devices; sorting by rate alone favours tiny samples.

Use a two-axis view: affected users and excess risk. Check whether the same signature appears across sibling models, one OEM, one OS build or one architecture. Annotate rollout percentage and acquisition campaigns that changed device mix.

• Version onset: Identify the first app version with the signature and whether an SDK changed. Test upgrade and fresh-install paths.
• Excess rate: Subtract or ratio against comparable devices with enough exposure. Retain confidence at small counts.
• User reach: Estimate current and projected affected users at full rollout. Use install base, not shipment popularity.
• Pattern: Look across OEM, OS, GPU, ABI, RAM and form factor. The visible model may be a proxy.

Decision rule: Prioritise clusters with high excess risk times exposed users, adjusted upward for critical journeys and rapid rollout growth.

Compute excess rate rather than reading the sorted list, because the top of a crash table is usually just the most popular device. Divide the model's rate by the rate across all other models on the same app version: values near one are proportionate, and values above roughly three indicate genuine concentration worth investigating. Pair that with reach so you prioritise correctly. Android's crash guidance explains how stack signatures are grouped, which matters because one visible signature can hide several distinct faults that need separating before any of them can be fixed.

Export the table rather than relying on a live sorted view, and keep the export with the incident record. Console and SDK numbers frequently disagree — reconcile before escalating.

A Play device-model label can represent variants with different memory, storage, chipset, GPU, firmware or carrier configuration. Google explicitly warns that model breakdowns may not distinguish these variants.

That is why buying one handset with the same retail name can fail to reproduce the issue. Collect a minimal privacy-reviewed runtime profile such as manufacturer, model, OS build, ABI, memory class and app version, then correlate it with the crash identifier. Avoid building a permanent fingerprinting system.

• Memory: Low-RAM variants may trigger allocation pressure or process death. Inspect memory class and workload.
• Chipset and GPU: Media, camera and rendering defects can follow vendor drivers. Check sibling models sharing hardware.
• Firmware: OEM and carrier updates may alter WebView, permissions or background behaviour. Record build fingerprint cautiously.
• Storage state: Low space and slower storage can expose database or extraction failures. Test realistic pressure.

Decision rule: Escalate from model to hardware-variant investigation when the lab handset does not reproduce and runtime properties split the affected cohort.

Record the variant fields at crash time rather than inferring them later from a marketing name. Total and available RAM, chipset, GPU renderer string, ABI, firmware build and free storage are cheap to attach and are the difference between a reproducible bug and an unfalsifiable theory about a device family. Android's memory overview explains why the same model with different available memory behaves differently under pressure: the low-memory killer acts on what is free at that moment, not on the specification sheet, so two identical handsets diverge purely on what else the user is running.

Collect only fields needed for diagnosis and set a retention period for the enriched telemetry. Technical failures are a leading uninstall driver.

Create a compact pack containing cohort filters, signature, affected-user counts, version onset, runtime context, user journey and candidate mechanism. It should let an engineer choose the right emulator, device lab or physical handset without reopening dashboard archaeology.

Include symbolicated stack or ANR trace and the code ownership path. Add breadcrumbs immediately before failure, but remove personal content and secrets. Record whether the failure occurs on fresh install, upgrade, background return, weak network, low memory or locale-specific input.

• Console evidence: Screenshots and exports with dates, filters and denominators. Link the live cluster.
• Technical evidence: Mapping, symbols, stack, trace and relevant release diff. Confirm line numbers match the binary.
• Environment: Model, variant clues, OS build, memory and connectivity state. Separate known from inferred.
• Journey: Minimal steps, account state and frequency. Name what cannot yet be reproduced.

Decision rule: Do not purchase hardware or exclude a device until the evidence pack states a mechanism hypothesis and what that action would prove.

Write the pack so a second engineer can act without asking you a question, because device bugs are frequently handed over mid-investigation. Include the saved cohort definition, the export, the signature, the variant fields, the failed hypotheses and the exact command that reproduces the attempt. Gradle-managed devices make that command portable: the device specification lives in the build file, so a colleague or CI runner instantiates the same configuration rather than approximating it. A pack that only a laptop can run is a pack that stops when its owner is on leave.

Update the pack when a hypothesis fails, so later work does not repeat it. Automated device testing turns the reproduction into a regression check.

Reproduce in layers: deterministic local conditions, configurable device labs, then the exact physical variant when evidence justifies it. Emulators are excellent for OS, memory and lifecycle scenarios but cannot faithfully reproduce every vendor driver or firmware defect.

Start with the smallest failing journey and same signed build. Apply memory pressure, storage pressure, process death, weak networks, background restrictions, rotation and locale. Use cloud device farms for breadth and physical hardware for vendor-specific camera, GPU or firmware mechanisms.

• Local control: Inject failures and lifecycle events in repeatable tests. Add a regression test around the mechanism.
• Emulator matrix: Vary API, ABI, screen, memory and background behaviour. Keep scripts identical.
• Device lab: Run the journey across relevant OEM families and OS builds. Capture video, logs and performance.
• Physical variant: Acquire or borrow the exact hardware only after variant evidence. Preserve its firmware state.

Decision rule: A reproduction is valuable when changing one suspected condition predictably turns the failure on and off.

Work outward from cheapest to most expensive, and stop as soon as the failure reproduces. Local device with matching Android version first, then an emulator configured to the variant fields, then a hosted lab, then physically sourcing the specific handset — each step costs meaningfully more time and money than the one before. Firebase Test Lab's device catalogue is worth checking before buying hardware, since the model is often already available. Constrain memory and storage deliberately when reproducing: many device-specific faults only appear on a nearly full device, which no clean test handset reproduces.

Automate the minimal case before broad manual exploration wherever possible. A repeatable production workflow keeps the reproduction alive after the incident closes.

Halt when projected user harm exceeds the cost of delaying the release; exclude a device only when the failure is severe, concentrated and not quickly fixable. Exclusion protects current users but also removes discovery, updates or acquisition for legitimate owners of that model.

Feature flags and server fallbacks are narrower containment where available. A rollout halt prevents additional recipients but does not remove the build from users who already received it. Document projected reach at the next rollout step and what signal reopens expansion.

• Halt rollout: Use for a version-linked regression that may spread with exposure. Keep existing recipients under observation.
• Disable feature: Use when one path causes harm and remote control is reliable. Provide a safe fallback.
• Exclude model: Use for a proven hardware incompatibility with severe impact. Review market and accessibility cost.
• Ship hotfix: Use when a narrow correction is verified and faster than prolonged containment. Do not bundle unrelated work.

Decision rule: Choose the least broad containment that stops expected harm and can be reversed with evidence.

Decide the containment thresholds in advance, in writing, because the decision is otherwise made under pressure by whoever is loudest. State the excess rate, absolute affected users and confidence level that trigger a rollout halt, a remote feature disable, a device exclusion and a hotfix respectively. Play's staged rollout controls let you halt without a new binary, which is almost always the faster containment. Device exclusion is the heaviest option and the hardest to reverse cleanly: it suppresses the signal along with the harm, so the underlying fault stops being visible in your own metrics.

Communicate containment to support and annotate acquisition dashboards. The staged rollout runbook covers halt-and-resume mechanics in detail.

Fix the mechanism—memory, main-thread blocking, driver-sensitive media, lifecycle assumptions or OEM background behaviour—rather than adding a model-name conditional first. Device allowlists and denylists age badly and often hide a broader class of failures.

For crashes, inspect allocation, native libraries, WebView, camera/media codecs and vendor APIs. For ANRs, identify the blocked main thread, lock owner, binder call or slow I/O. Add capability checks and timeouts instead of assuming uniform platform behaviour.

• Memory: Reduce peak allocation, stream large assets and handle process recreation. Test low-memory callbacks and cold restoration.
• Main thread: Move I/O and expensive work off UI, remove lock inversions and bound binder waits. Trace actual stalls.
• Media and graphics: Query capabilities, handle codec failure and offer lower-cost paths. Expect vendor differences.
• Background and OEM: Use supported scheduling and tolerate delayed or killed work. Never depend on perpetual processes.

Decision rule: Prefer capability- and state-based fallbacks; use a model-specific guard only as temporary containment with an expiry review.

Match the fix to the signature class rather than applying general performance advice. Out-of-memory faults concentrated on low-RAM variants point at image decoding and cache sizing; ANRs point at main-thread work such as synchronous disk or network access in lifecycle callbacks; renderer-specific crashes point at GPU driver behaviour that needs a capability check rather than a model allowlist. Android's core app quality guidance lists the checks worth running before release. OEM background restrictions are their own category: work that survives on one manufacturer's build is silently killed on another, and no amount of code review reveals it without a device.

Link every code change to the exact production signature it intends to move. Release cadence determines how quickly that link can be tested.

Release gradually and compare the same signature and device cohort on the fixed version after enough affected-user exposure. A lab pass proves the proposed mechanism; production proves the population outcome.

Keep cohort definitions stable and compare against the previous version over aligned windows. Watch for signature mutation, where a caught exception becomes a timeout or a nearby crash. Include core-task completion and performance so the workaround does not merely suppress reporting.

• Exposure target: Estimate how many target-device users must receive the build for a readable result. Do not use 1% blindly.
• Signature outcome: Track affected users for the original and adjacent clusters. Confirm symbols and versions.
• Product guardrails: Watch activation, task success, latency and support on the cohort. A disabled feature needs scrutiny.
• Decision: Expand, hold, revise or remove temporary guard at a scheduled checkpoint. Name the owner.

Decision rule: Declare fixed only when target-cohort production risk returns to an acceptable range and no compensating regression appears.

Define the verification window by exposure rather than by elapsed days. A fix reaching two per cent of a device cohort tells you very little after twenty-four hours; the same fix at fifty per cent tells you a great deal. Set the target exposure and the minimum affected-user count before staging, then hold the rollout at that step until both are met. Play's vitals reporting lags real time by a day or more, so a same-day 'all clear' is reading an incomplete window. Watch the specific signature, not only the headline rate, because an unrelated regression can mask a genuine improvement.

Remove temporary logs and model guards after the verification window, not before. Play release controls set what you can adjust mid-rollout.

Use a repeatable detect, scope, contain, reproduce, fix, stage and verify loop with one incident owner. The runbook can be short, but every transition needs evidence and a reversible decision.

Review global and device core vitals after each rollout and weekly otherwise. Alert on sudden version-relative movement as well as fixed limits. Keep symbol and mapping uploads part of release completion, maintain access to a device lab and rehearse feature-disable controls.

• Detect and scope: Capture definition, version, signature, cohort, numerator and denominator. Estimate full-rollout harm.
• Contain: Choose halt, flag, fallback or exclusion and record the reopening gate. Tell support and growth owners.
• Diagnose and fix: Build the evidence pack and reproduce the mechanism. Add regression coverage.
• Stage and verify: Expose enough target devices, inspect adjacent metrics and close temporary controls. Write the incident lesson.

Decision rule: No incident closes with “new build released”; it closes with production evidence for the affected cohort and assigned follow-up work.

Keep the runbook short enough that someone uses it at two in the morning. One page, four phases, a named owner per phase, and the containment thresholds already agreed — anything longer becomes a document people intend to read rather than a procedure people follow. Store completed incidents in the same place with their evidence packs attached, so recurring OEM patterns accumulate into something searchable. Android's ANR reference is worth linking directly from the runbook, because the definitions are the part teams most often misremember under pressure.

Keep a linkable incident record so recurring OEM patterns become organisational knowledge. Console anomalies often share a root cause with device-specific faults.