For Android users, Application Not Responding (ANR) messages appear when an application “hangs” for a certain period of time. The user is truly stuck, and this unhelpful ANR message is anything but fun:
Since the only two available options are to wait (not ideal) or to force-quit the app (definitely not ideal), an ANR error is, for all intents and purposes, just as bad as a full-on crash. Not surprisingly, many users consider ANRs to be grounds for a one-star rating and the impetus to go find a different app.
Bugsnag now provides full support for ANR error detection. (Hooray 🎉!)
With a full stack trace for ANRs, developers can quickly get to the code responsible for the app hanging. Bugsnag groups ANRs by cause, which makes it easy to prioritize the errors that are happening the most and determine which ones to fix.
Because Bugsnag is detecting ANR scenarios from INSIDE the code, more data is provided to developers, such as what happened in the run-up to the ANR, which users experienced the ANR, what experiments are enabled in the app, etc.
How exactly does this error detection for ANRs work?
The information Bugsnag provides makes it a breeze to prioritize the ANR causes and determine what’s most important to fix first, as well as weigh the ANRs against other errors that are causing the app to crash.
Since ANRs count towards the app’s stability score, it’s also possible to track progress from release to release and see if new features are causing a higher rate of ANRs.
Perhaps the only thing more infuriating than the ANR user experience is the ANR developer experience. Often, there’s no insight provided into why ANR errors are occurring, and developers are limited in their capabilities to trace the source. Here’s why:
Thankfully, these ANR challenges become headaches of the past for Android developers who use Bugsnag.
Ready to take control over ANRs?
Yep, it’s really that simple. Now go forth and conquer those pesky ANRs.