Why ANRs are Hard to Solve and What You Can Do to Make it Easier
summary
Embrace monitors mobile apps and argues ANRs are broader than UI-thread blocks, with Google enforcing a 47% DAU threshold (only ~1 in 213 users can have an issue daily) and now judging user‑perceived ANRs separately. GPC captures ~5s samples and often reports native pull once entries that are useless (30–60% of user‑impacting ANRs). Android 11 adds Application Exit Info; many teams build custom detectors (collecting up to 80 samples) and find ad SDKs, Unity/native code, and long rollout lifetimes (months to cut ANRs ~70%) are the real problems.
AI-written summary · about
chapters (17)
- 0:00Introduction to ANRs
- 1:14What ANRs really are
- 3:03Why ANRs matter
- 4:33How Google enforces ANRs
- 6:19Changes in ANR enforcement
- 7:43ANRs vs crashes
- 8:48Why ANRs are hard to debug
- 11:16Native ANR challenges
- 12:42Prioritizing ANR fixes
- 15:31Data sources for ANRs
- 17:39Application exit info
- 21:01Signal handlers and ANRs
- 22:08Custom ANR detection
- 23:14End-user experience focus
- 25:40Native code and ANRs
- 27:28ANR persistence after fixes
- 28:32Summary and closing
related talks
29mHow the Android Framework Monitors, Processes, and Triggers ANRs
12mUnderstanding and debugging ANR's (Android Not Responding)
29mHow the Android Framework Monitors, Processes, and Triggers ANRs
22mANR overview at Uber + Leveraging ApplicationExitInfo API
39mWhere Is Your ANR Coming From? — Diagnosing How It Occurs and Prescribing Remedies by Symptom
19mRevolutionizing ANR Detection at Sentry
40mAndroid vitals: Debug app performance and reap rewards
40mUnblocking The Main Thread: Solving ANRs and Frozen Frames