ANR in Bugsnag.start (ForegroundDetector.getProcessInfo) about bugsnag-android

[johnkiely1]

Thanks for the additional info @Deishelon, we agree something does look a little odd. We're now taking a look at getting this addressed.

[azabost]

I see, thanks. Keep us posted, please 🙏

[johnkiely1]

Hey @Deishelon,

It looks like you are using v5.19.2, would you be able to upgrade to the latest version v5.28.4?
We did make some changes recently which may be related. It would be good to verify if the issue you are reporting still exists on the latest version. Thanks

[Deishelon]

Sounds good, will get back on this

[Deishelon]

Hi team,

We have updated bugsnag sdk to v5.28.4, and we still seen ANRs.

Additionally, we did notice that ANR were happening in various places in bugsnag sdk, which is probably indicating that it takes longer than Android is liking to initialize the sdk as the whole, and android throws ANR while sdk is executing init code.

So, attaching a trace file of the bugsnag's Bugsnag.start function call. Which should show all the details.
2023-03-10_12-06-39_310.trace.zip

You can import this file into Android Studio to see visual,
here is the preview:

Thanks!

[johnkiely1]

Hi @Deishelon, after some investigation on our side, this ANR would only occur when using BOOT_COMPLETED listeners.

One way to reliably fix this issue right now would to move the notifyNdkInForeground onto a background thread, however this is not something we can do on our side currently as would create a window where an NDK crash will report the incorrect “in foreground” state (while the task to update it is still on the queue).

The best work around for you and the lesser of two evils would be for you to implement code to triggerBugsnag.starton a background thread. Hopefully that is a workable solution for you.

In the longer term, we expect this will stop being a problem as we are looking into alternative ways of foreground tracking. I don't have an eta on that as yet but we will post here with further updates.

[Deishelon]

Hi, we have trial'ed this over last several weeks, and we don't see this ANR anymore. Thank you for the suggestion.

Do you think there should be documentation update that recommends launching bugsnag on another thread for apps that use BOOT_COMPLETED ?

[johnkiely1]

Hey @Deishelon, yeah adding it to the docs sounds like a good idea, we will do that as soon as we can.

[azabost]

@johnkiely1 Hey. I've just noticed the recommendation to call Bugsnag.start in a separate thread in your docs and found this issue while looking for more details. I would like to ask some questions regarding the suggested workaround.

---

First of all, I suppose starting BugSnag in a separate thread may result in missing some crashes because of a race condition between BugSnag's initialization and an early crash. Here's an example of such a situation:

Can you confirm or deny my hypothesis?

---

The second question is related to what you said about foreground detection:

In the longer term, we expect this will stop being a problem as we are looking into alternative ways of foreground tracking.

Since I'm working on an app that mostly contains only services and almost no UI (kind of specialized launcher), then maybe it would be better to just disable the foreground detection in BugSnag somehow to avoid this issue. Is that possible or could it be added to BugSnag's API?

[clr182]

Hi @azabost

You are exactly right. When initialising the notifier on a background thread there is a window where crashes may not be detected as the relevant handlers might not have been installed yet.

We don’t currently have a mechanism in place to disable foreground detection. while it would be possible to add an option to disable at the moment our preference is to continue with the planned work to remove the call to ActivityManager and replace with ActivityLifecycleCallbacks to solve this issue in all cases rather than add what amounts to a workaround at the cost of some functionality.

[clr182]

Hi @azabost

Thank you for your patience!

Our BugSnag Android notifier v6.+ has been released, which includes a behaviour change for foreground tracking. This update should solve your issue, however if after upgrading, you are still seeing issues then please feel free to reopen this thread let us know

[azabost]

Thanks for the update 🙏

[szymon-miloch]

Hey, @clr182 thanks for handling it.

I still see in the docs that you suggest to use separate thread for initialization, is it irrelevant now?
Source: https://docs.bugsnag.com/platforms/android/#basic-configuration

[mclack]

Hi @szymon-miloch

Yes, that documentation is now outdated. You should only need to follow that advice if you are using a version of the bugsnag-android notifier below 6.0.0.

We've added a task to update our documentation to explain this. Thank you for raising it with us.