Focused reading
ANR and Main-Thread Stall Review
ANRs are the freezes users describe as “the app died” even when no fatal exception fired. Mixing them into crash charts hides the main-thread work that actually froze the frame.
Focused reading
ANRs are the freezes users describe as “the app died” even when no fatal exception fired. Mixing them into crash charts hides the main-thread work that actually froze the frame.
This review exists because crash dashboards treat ANRs as a second-class bucket. We read the traces as traces: who held the main thread, whether a binder call sat waiting, whether a receiver did network work during boot.
Malaysian device mixes make some ANRs look worse than they do on a fast flagship. A ContentResolver query that is merely sluggish on a new Samsung can freeze input dispatch on a mid-range Xiaomi still running an older API. The brief names that skew when the traces show it.
Teams whose Play Console shows ANR rate climbing while fatal crash rate looks acceptable — common after adding a heavy splash, a new maps SDK, or a WebView that waits on the main thread.
A ranked list of ANR signatures with likely stalls (disk on main, binder, broadcast, input dispatch) and a note on which OEM skins stretch the same code into a freeze.
ANR traces for one application ID over the last twenty-eight days. Fatal crashes are acknowledged only when they share a signature with an ANR.
You send Play Console ANR exports or bugreport snippets. We confirm version codes and whether StrictMode is already on in debug.
Stacks are grouped. Frozen input dispatch is separated from slow lifecycle work.
You receive a short document, not a crash audit pack, and a focused call.
ANR exports, mapping files for the affected versions, and a description of recent SDK additions.
We cannot reconstruct an ANR that Play never uploaded. Very new releases may need a few days of vitals before clustering is honest.