Docs Platforms Android Frequently asked questions
Smartbear.com Start Free Trial
BugSnag is now Insight Hub – we're making some changes to how the product looks, but this won't impact the way you use BugSnag or any of your integrations.

Frequently asked questions

Contents

What are AnrLinkError and NdkLinkErrors?

On devices running older versions of Android, before API 23 (Marshmallow), the native library loading can be unreliable on certain OS versions. This can result in UnsatisfiedLinkErrors being thrown when BugSnag attempts to load the native libraries used for ANR and NDK detection. If this error occurs, ANR or NDK crash detection will be disabled and an AnrLinkError or NdkLinkError will be reported to BugSnag.

If you experience an UnsatisfiedLinkError we recommend linking BugSnag’s ANR plugin and/or NDK plugin using the Relinker library to reduce their incidence.

More recent Android versions (API 23+) do not have the same issue with native library loading so we recommend using this approach conditionally for older Android versions only.

Add the Relinker library using the installation instructions, then load the appropriate BugSnag plugin with:

ReLinker.loadLibrary(this, "bugsnag-ndk");

ReLinker.loadLibrary(this, "bugsnag-plugin-android-anr");

Does BugSnag support multi process apps?

Yes – if your app uses multiple processes then you should initialize BugSnag once in each process, with a unique persistenceDirectory value.

Configuration config = Configuration.load(this);
config.setPersistenceDirectory(new File("/my-custom-dir"));
Bugsnag.start(this, config);

Bugsnag.start(this, Configuration.load(this).apply {
  persistenceDirectory = File("/my-custom-dir")
})

Failing to make the persistenceDirectory unique will cause undefined behavior in the storage of error and session reports.

If one of your processes uses an app component that is not an Activity then you should manually track sessions for that process. This is because automatic session tracking relies on activity lifecycle callbacks.

Because each process uses a separate JVM any custom configuration, such as attaching custom diagnostics, will need to be carried out on each BugSnag instance.

Why do I see StrictMode violations in my dashboard?

BugSnag can capture StrictMode violations depending on the policy you have set. See BugSnag’s StrictMode docs for more information.

How can I tell if BugSnag has finished initializing?

Calling BugSnag static client methods, such as Bugsnag.leaveBreadcrumb() and Bugsnag.addMetadata(), will throw an exception if you have not yet called Bugsnag.start().

We recommend calling Bugsnag.start() in the main thread as early as possible in your app’s lifecycle in order to catch all errors. Once this method has been invoked, it is safe to use other methods on the BugSnag client from any thread; a lock will cause the calling thread to wait for startup to complete fully.

In the unusual case where it’s not possible to determine whether or not Bugsnag.start() has been invoked, you can use Bugsnag.isStarted() to guard uses of BugSnag client methods.

How does BugSnag detect ANRs?

BugSnag detects ANRs using the SIGQUIT signal handler that runs at the same time as the ANR dialog is shown (giving the user the option to force quit the app or wait). SIGQUIT is used to dump the current runtime state and is called once the runtime determines the process should be killed due to an ANR. BugSnag’s ANR handler will only capture ANRs when the app’s UI is unresponsive, as SIGQUIT only occurs for unresponsive UI issues due to the main thread being blocked.

How does BugSnag report ANRs?

We schedule the delivery of ANR reports immediately, but these could be delayed until restart if the app is terminated before or during the send. In these cases we cannot guarantee delivery.

Does BugSnag capture background ANRs?

Background ANRs – such as taking too long to respond to a broadcast message – cannot be captured in the same way as ANRs that occur whilst the app is in use, since a signal we use to detect ANRs is not sent when the app is not in the foreground. This can also be the case when the user puts the app into the background before the ANR dialog can be shown.

However, since v6.11.0 of the bugsnag-android SDK, the bugsnag-plugin-android-exitinfo plugin can be used to detect background ANRs using the ApplicationExitInfo API. For devices running Android 11 (API 30) and above, an ANR event will be sent to your BugSnag dashboard if the Android runtime reports an ANR that wasn’t captured by our foreground detection.

See Reporting app exit information for more information.

Why am I seeing a discrepancy between ANR counts in BugSnag and Google Play Console?

As described above, v6.11.0 of the bugsnag-android SDK and the bugsnag-plugin-android-exitinfo are important when comparing ANR events in your dashboard to the data in the Google Play Console, to ensure that background ANRs are reported to BugSnag.

However, there are other caveats to be aware of:

  • BugSnag background ANRs will only be reported for Android 11 (API 30) and above.
  • BugSnag will often need an app restart for the event to be sent to your dashboard, so there may be a delay or the event may never be sent. By contrast Google uses Play Services to send their error reports, which does not require the app to be running.