Expected behavior

return original exception

Observed behavior

returns BugsnagException

Steps to reproduce

Use version 4.18+

Version

4.18+

Additional information

The return type of report.getError().getException() should either be a Throwable or a BugsnagException. Throwable is preferred because instanceof can be used to quickly and safely determine the exception type, whereas BugsnagException requires a string compare on the exception name.

Expected behavior

Let's say I create two distinct Bugsnag clients, like so:

Client client1 = new Client(application, "key1", false);
Client client2 = new Client(application, "key2", false)

These two clients use two distinct keys, and are expected to upload errors to two distinct bugsnag projects.

Observed behavior

If there is no network when we try to notify and the errors get stored on the filesystem, the API keys stored in the errors will be ignored and the errors will be uploaded to the project of whichever client flushes first.

Steps to reproduce

• Turn of Wifi
• Create a client instance with API KEY 1
• Send an error to client (it gets stored because no wifi)
• Kill the app
• Start the app
• Create a client instance with API KEY 2, get it to flush
• => the crash 1 gets uploaded to project 2 instead of project 1.

Version

Still happening on master, all releases have this bug.

Additional information

At this line: https://github.com/bugsnag/bugsnag-android/blob/master/sdk/src/main/java/com/bugsnag/android/ErrorStore.java#L125

    private void flushErrorReport(File errorFile, ErrorReportApiClient errorReportApiClient) {
        try {
            Report report = new Report(config.getApiKey(), errorFile);
            errorReportApiClient.postReport(config.getEndpoint(), report,
                config.getErrorApiHeaders());
// ...

The report is uploaded with the API Key from the config of the error store, not the API Key from that config that was used when the error was created (that config is actually stored in the error).

Possible solutions

1. Allow customizing the error store and session store folders. This would allow each client to store data in a distinct folder and avoid clients stepping over each other
2. Read the content of the error before uploading it, to retrieve the proper API key. This is potentially risky.
3. Fix this server side, check for Error file content with config.apiKey set to something different than the API Key that was used to upload.

Behavior

We (Airbnb) have received an enormous number of ANRs from the new SessionTracker code on the sessionStore lock between these two lines: https://github.com/bugsnag/bugsnag-android/blob/master/sdk/src/main/java/com/bugsnag/android/SessionTracker.java#L154 https://github.com/bugsnag/bugsnag-android/blob/master/sdk/src/main/java/com/bugsnag/android/SessionTracker.java#L107

This is a high severity crash and we already have to do a cherry-pick to fix this so let us know what the solution is or we'll have to revert the new session tracking code and delay the use of the release dashboards feature again.

Version

4.2.2

@BenSchwab @fractalwrench @kattrali

Hi, we just shipped a new release of our app with the latest version (v4.13.0) of the Bugsnag library.

We are noticing a lot of ANR exceptions coming exclusively from HUAWEI devices. The stacktraces have been relatively unhelpful. I noticed some of them happening when an activity calls onResume() and I noticed some others happening at random after the app has been in the background for a while (1 hour+).

My thought is that HUAWEI protected apps / phone manager features are doing something menacing that slows down or stops processing which leads to these ANR errors popping up. I don't see any ANR errors popping up on the Play Store Console and no other devices have similar ANR errors.

I don't have a HUAWEI device to test on. I am just going off what I see on our bugsnag dashboard from our production users.

For now we are just going to ignore these errors. Maybe someone else can shed some light on this issue or report similar results.

Thanks!

FairEmail is a privacy friendly email app and has a quite critical user base. It appeared that Bugsnag is using the accelerometer via the Android OrientationEventListener, which is unwanted in this app. I have disabled the listener with an ugly hack, but IMHO this should be possible by using the client configuration.

Can this please be added?

Expected behavior

native crash reports should be sent to the server

Observed behavior

no crash report in dashboard

Steps to reproduce

cause a crash in native code

Version

4.9.2

Additional information

All tests have been run on armeabi-v7a builds on both 32bit and 64bit devices

A 32bit build (x86) on an intel device (Nexus Player) was also tested and the report was sent to the dashboard but it had extra entries for bugsnag code in the stack trace: /data/app/com.sling.dev-HhT1kRrppLHTyD_iePSWfQ==/lib/x86/libbugsnag-ndk.so:36310bsg_unwind_stack_libunwind /data/app/com.sling.dev-HhT1kRrppLHTyD_iePSWfQ==/lib/x86/libbugsnag-ndk.so:35160bsg_unwind_stack /data/app/com.sling.dev-HhT1kRrppLHTyD_iePSWfQ==/lib/x86/libbugsnag-ndk.so:33868bsg_handle_signal /system/bin/app_process32:101120xf417f780 /system/lib/libc.so:1260480xf0b29c60 ../../../build/jenkins-slave/workspace/AdaptivePlayer-Android-Test/src/native/integrations/AVController/MovePlayerController.cpp:1439eventListener ../../../build/jenkins-slave/workspace/AdaptivePlayer-Android-Test/src/native/integrations/Android/jni/MovePlayerControllerJni.cpp:68Java_com_echostar_apsdk_MovePlayerController_nativeInit /data/app/com.sling.dev-HhT1kRrppLHTyD_iePSWfQ==/oat/x86/base.odex:670275oatexec

Can't comment on Issues?

Some users have been unable to comment on Github issues when an adblocker extension is enabled. We recommend temporarily disabling the extension, or if that fails, contacting [email protected].

Bugsnag's default is to be as passive as possible as it is obviously desirable that including the library in one's app has a very low impact.

This means that currently Bugsnag passively probes whether a device is rooted or not, in practice this means that the bug report indicator for "rooted" is not necessarily reliable. If an app deals with root, the app could already be doing an active root-check. It would make the bug reports more accurate if we could manually update this value then.

I think you can manually use Error.addToTab("device", "jailbroken", <boolean>) to change the value, but a less "hacky" way might be useful, e.g. making DeviceData editable. Currently DeviceData is initialized on Client init and not changeable: https://github.com/bugsnag/bugsnag-android/blob/752d748ac67b24d8de96fec6a382cf922098a468/sdk/src/main/java/com/bugsnag/android/Client.java#L142

Looking for some feedback on this idea.

• Introduced builder pattern for User, User is now immutable.
• Reduced duplicate/simplified code related to User and moved User related implementation details from Client to `User´
• Removed methods that were just used internally and migrated them to Client.setUser(user)
• Tagged/deprecated all public APIs that set specific User fields. In the next semvar major release these could be removed.
• Added unit tests for the new code and adapted the existing tests such that both the new and the now deprecated methods are covered.

1. Cleaner API after the next major release removes the deprecated methods
2. Easier future SDK updates. Want to add new User information? Just update User.
3. User is now exposed via Client.getUser() which solves my issue in #265

@fractalwrench

Goal

Captures the trace of Thread.currentThread(), which was previously omitted, and to identify it with a boolean flag in the serialised JSON.

Changeset

• Alter ThreadState to stop removing the current thread from serialisation
• Conditionally write errorReportingThread boolean flag by checking thread ID

Tests

Added unit tests for general ThreadState serialisation, and for checking that the current thread is now captured. Ran mazerunner locally, tested with dashboard.

Review

For the submitter, initial self-review:

• [ ] Commented on code changes inline explain the reasoning behind the approach
• [x] Reviewed the test cases added for completeness and possible points for discussion
• [x] A changelog entry was added for the goal of this pull request
• [x] Check the scope of the changeset - is everything in the diff required for the pull request?
• This pull request is ready for:
  • [x] Initial review of the intended approach, not yet feature complete
  • [x] Structural review of the classes, functions, and properties modified
  • [x] Final review

For the pull request reviewer(s), this changeset has been reviewed for:

• [x] Consistency across platforms for structures or concepts added or modified
• [x] Consistency between the changeset and the goal stated above
• [x] Internal consistency with the rest of the library - is there any overlap between existing interfaces and any which have been added?
• [x] Usage friction - is the proposed change in usage cumbersome or complicated?
• [x] Performance and complexity - are there any cases of unexpected O(n^3) when iterating, recursing, flat mapping, etc?
• [x] Concurrency concerns - if components are accessed asynchronously, what issues will arise
• [ ] Thoroughness of added tests and any missing edge cases
• [x] Idiomatic use of the language

warning: Ignoring InnerClasses attribute for an anonymous inner class
(com.bugsnag.android.Async$1) that doesn't come with an
associated EnclosingMethod attribute. This class was probably produced by a
compiler that did not target the modern .class file format. The recommended
solution is to recompile the class from source, using an up-to-date compiler
and without specifying any "-target" type options. The consequence of ignoring
this warning is that reflective operations on this class will incorrectly
indicate that it is *not* an inner class.

Trying to build or open the project in Android Studio is failing with:

ABIs [armeabi] are not supported for platform. Supported ABIs are [arm64-v8a, armeabi-v7a, x86, x86_64].

The reason is armeabi was removed from the NDK. See NDK changelog

Support for ARMv5 (armeabi), MIPS, and MIPS64 has been removed. Attempting to build any of these ABIs will result in an error.

Also see:

• https://github.com/android/ndk/issues/961
• https://github.com/android/ndk/issues/911
• https://stackoverflow.com/questions/52233971/abis-armeabi-mips-are-not-supported-for-platform-android-ndk

There have been no new devices that only support armeabi but not armeabi-v7a for 10 years or so.

This PR removes the references to armeabi from the default list of abiFilters, allowing the build to pass again.

@kattrali - You already removed it from example app as part of #493, but in a0519a4cae3624a1b1c4ec05cd9659ca1f0a4a7d you're mentioning "Needed for lib release" - Can you elaborate on it?

Goal

In the case where client.notify is called and the event is modified to be treated as unhandled:

client.notify(throwable, new OnErrorCallback() {
      @Override public boolean onError(@NonNull Event event) {
        event.setUnhandled(true);
       ...
      }
    });

we should cache the event, similar to how it is done for an unhandled exception. With an unhandled exception, the app's availability will cease - and if we are marking an event as unhandled, we are indicating this will be the case.

We use our own default exception handler which allows us to customize crash handling and send crashes to distinct destinations. Using the bugsnag client with client.notify with setUnhandled = true as part of that handler and being able to rely upon similar behavior as the bugsnag default exception handler rather than forward to the bugsnag exception handler would simplify the structure of our code, and remove the hacky bugsnag workarounds we've had to implement.

Design

Change delivery logic to view events marked as unhandled to behave as a typical unhandled exception in bugsnag.

Changeset

Testing

Description

Bugsnag grouping of crashes does not work well for Android native crashes that happen inside of dynamically loaded libraries. Bugsnag seems to be using a whole path for where the error happens when grouping events into errors and the path seems to depend on the device's manufacturer. This leads to a situation in which the same crash is recognized by Bugsnag as a few separate errors which makes following up on the underlying crash hard/confusing.

Example

Let's take a look at one of the native crashes that's being reported by Bugsnag as two separate errors - even though bought of them represent exactly the same crash.

The last two stacktrace entries in Bugsnag error 1 (coming from Google pixel phones):

/apex/com.android.runtime/lib64/bionic/libc.so:536992 abort
/data/app/me.lyft.android-e5wo6hyI4Ov_FwVO9wyp8g==/split_config.arm64_v8a.apk!/lib/arm64-v8a/libenvoy_jni.so:17669316 Envoy::Network::DnsResolverImpl::AddrInfoPendingResolution::availableInterfaces() [/data/app/me.lyft.android-e5wo6hyI4Ov_FwVO9wyp8g==/split_config.arm64_v8a.apk!/lib/arm64-v8a/libenvoy_jni.so:17669316 Envoy::Network::DnsResolverImpl::AddrInfoPendingResolution::availableInterfaces()]()

The last two stacktrace entries in Bugsnag error 2 (coming from Samsung 95%/LG 5%):

/apex/com.android.runtime/lib64/bionic/libc.so:325724 abort
/data/app/~~A9JzPlzk_YgX3GgLEeqI4A==/me.lyft.android-OUs7t61Y4otTWqNTPl8p4A==/split_config.arm64_v8a.apk!/lib/arm64-v8a/libenvoy_jni.so:17669316 Envoy::Network::DnsResolverImpl::AddrInfoPendingResolution::availableInterfaces()

Describe the solution you'd like Stop using the whole path when grouping Bugsnag events - use the last path component only.

Describe alternatives you've considered N/A

Additional context An example stacktrace entries come from a crash that happens in an Android app running Envoy Mobile networking library. It's open source and available at https://github.com/envoyproxy/envoy-mobile in case it's helpful.

Description

We've set up Bugsnag in our UI tests to report failures to a central place and track crashes that cause random failures / flaky tests in CI. We call Bugsnag.notify() to report those.

Unfortunately, Bugsnag.notify() is async by nature, so if the test finishes before the upload then the VM is killed and the app is uninstalled, so we sometimes never get crash reported. I fixed this with some reflection hack to reach into Bugsnag's internals for now.

Ideally, we'd either get a new Client.notifyBlocking() API, or a callback based API to know when the provided throwable is done being uploaded.

Description

My Android Bugsnag crash reports include the integer Android version, i.e. Android 11, but they don't include the security patch version; this would be useful to have when diagnosing whether an Android security patch is the cause of a crash/exception. Apparently this was added in API level 23: https://developer.android.com/reference/android/os/Build.VERSION#SECURITY_PATCH

Describe the solution you'd like

Please add SECURITY_PATCH to the default report metadata.

Describe alternatives you've considered I could probably figure out how to add it manually but this seems like the correct default.

The SIGQUIT-based ANR tracker that's present in the library doesn't track ANRs that happen in background if user has "Show background ANRs" switched off (which is the default value) in Developer options.

Any workaround for this?

Logs when the ANR occurs (without any dialog):

Thread[4,tid=14199,WaitingInMainSignalCatcherLoop,Thread*=0x712fa7be90,peer=0x12c40cd8,"Signal Catcher"]: reacting to signal 3
I  Wrote stack traces to tombstoned

Process com.my.package (PID: 14189) ended

Some people are on tight data bundles or allowances, for example people an ships relying on satellite communication. For those people every byte counts / is expensive.

They would highly appreciate an option to disable / defer sending Bugsnag data when there is a metered internet connection only (generally mobile data or paid WiFi hotspots).

This could be a simple property of com.bugsnag.android.Configuration checked by com.bugsnag.android.DefaultDelivery.