# bugsnag/bugsnag-android: the Android notifier SDK behind a hosted crash reporting service

> bugsnag-android is the open source Kotlin SDK that captures crashes, handled exceptions, breadcrumbs and user data in an Android app and ships them to a hosted reporting service. The SDK is MIT licensed, but the pipeline behind it is a commercial account, and the repository is organised as a core notifier plus a set of plugins for ANRs, app hangs, exit info, NDK crashes, OkHttp and React Native.

**bugsnag/bugsnag-android** — BugSnag crash monitoring and reporting tool for Android apps

- Repository: https://github.com/bugsnag/bugsnag-android
- Website: https://www.bugsnag.com/platforms/android/
- Stars: 1,245 · Forks: 208
- Language: Kotlin
- License: NOASSERTION
- Published: 2026-10-19 · Updated: 2026-10-19 · Language: en
- Canonical page: https://hysenlabs.com/projects/bugsnag-bugsnag-android

## An open source SDK in front of a commercial service

bugsnag-android is a crash monitoring and reporting tool for Android apps, written in Kotlin, and the README describes it as an error monitoring and exception reporter for Android. Its job is to detect crashes in an Android application, collect diagnostic information, and notify the development team.

The important thing to understand before evaluating the code is what the repository actually is. The notifier library is open source, and the README states that the BugSnag Android SDK is free software released under the MIT License, with the details in the `LICENSE` file. The other half is not in this repository at all. The first step of the documented getting started is to create a BugSnag account, and the crash data goes to a hosted service reachable at bugsnag.com, a SmartBear product.

So the open source part is the code that runs inside your app, and the paid part is the pipeline that receives, stores, groups and presents the reports. That split is normal for a hosted service with an open client, and it is the right question to ask about data before you add the dependency, because the diagnostic information that gets collected is exactly the information that describes your users' devices and sessions.

## Unhandled crashes, handled exceptions, breadcrumbs and user identity

The feature list is short enough to read in full, which is unusual for a crash reporter, and it covers four things.

Uncaught exceptions and crashes are reported automatically. Handled exceptions are reported on demand through `Bugsnag.notify`, which is the API you call at a catch block to record an error your code recovered from but that still indicates a defect. Log breadcrumbs are attached to crash reports and are described as adding insight into users' actions, so the report contains a trace of what happened before the failure rather than only the failure. And user information can be attached, which the documentation frames as the way to determine how many people are affected by a crash.

The user identifier point cuts both ways and deserves attention during evaluation. Attaching user data is exactly what makes crash counts actionable, because a crash affecting most of your users is a different problem from one affecting three of them. It is also the mechanism by which personal data leaves your application, so what you attach, and whether it includes anything identifying, is your decision rather than the library's.

The documented workflow is short: create an account, follow the integration guide to report unhandled exceptions, use `Bugsnag.notify` for handled ones, and then adjust behaviour through the configuration options.

## The repository is a core notifier plus a plugin set

The top level tree explains how the SDK is put together. There is a `bugsnag-android-core/` module, a `bugsnag-android-http-api/` module that holds the API client, and a `bugsnag-android/` module for the Android specific parts. Alongside them sit a set of plugins, each in its own directory, and a `bugsnag-benchmarks/` module for performance measurement.

The plugin list tells you what the SDK can see beyond a plain Java or Kotlin exception. There is `bugsnag-plugin-android-anr` for application not responding events, `bugsnag-plugin-android-apphang` for app hangs, and `bugsnag-plugin-android-exitinfo` for Android exit information. There is `bugsnag-plugin-android-ndk` for native crashes, `bugsnag-plugin-android-okhttp` for HTTP client activity, and `bugsnag-plugin-android-react-native` for React Native applications.

Each of these closes a gap that a plain exception handler leaves open. A native crash produces a signal, not a Java exception, so without the NDK plugin it is invisible. A freeze does not crash the process, so ANR and app hang detection need a separate mechanism. And exit info is the platform's own record of why a process died, which is a different source of truth from the SDK's own bookkeeping.

The `examples/sdk-app-example/` directory holds a sample application, and the `docs/` directory and the online documentation at docs.bugsnag.com cover the integration guide, the reporting of handled exceptions and the configuration options in detail.

## Building the notifier across four Android ABIs

The build is Gradle based, and the Makefile wraps the tasks that matter. The default target builds the whole project with an explicit list of Android ABIs:

```bash
./gradlew build -PABI_FILTERS=arm64-v8a,armeabi-v7a,x86,x86_64
```

That list is the interesting part. An SDK that ships native code has to decide which instruction sets to include, and this one filters them explicitly rather than shipping every ABI, which keeps the download size of your app in check.

The other targets follow the same shape. `make test` runs `./gradlew connectedCheck`, the instrumentation test task, which needs a connected device or emulator. There is a `notifier` target that builds and publishes the notifier to the local Maven repository with a placeholder version, which is how a local build is consumed by the test fixtures:

```bash
./gradlew -PVERSION_NAME=9.9.9 assembleRelease publishToMavenLocal -x check
```

And there are fixture targets, `fixture-r19`, `fixture-r21` and `fixture-r28`, each pinning a specific NDK version through `-PTEST_FIXTURE_NDK_VERSION` and a fixture name, then copying the built files into place with a Ruby script. The point of the fixture matrix is version coverage: an SDK that behaves differently on older platform levels needs to be exercised against each one, and the NDK version is pinned per fixture because native symbolication depends on it.

## End to end tests on real devices through Maze Runner

The `docker-compose.yml` in the repository shows how the project verifies the whole pipeline rather than just the library. There are services for a common Android image, a CI base image, a publisher for signing and uploading, and a `maze-runner` service built from the `latest-v11-cli` image. The environment carries API keys for the various Appium based drivers, including separate keys for maze runner, Appium and scenario runs, plus a `TEST_FIXTURE_SYMBOL_DIR` pointing at the symbols needed to read native crash fixtures.

Maze Runner is the end to end harness here, and the port mapping and volume mounts show what it needs: the built APK, the features directory, the maze output and the reports. The remote test target in the Makefile drives the same idea from the host, requiring BrowserStack credentials and pointing at a fixed list of devices:

```bash
INSTRUMENTATION_DEVICES='["Google Nexus 5-4.4", "Google Pixel-7.1", "Google Pixel 3-9.0"]' \
  docker-compose up --build android-instrumentation-tests
```

Two details in that list are worth noting. A device on Android 4.4 is included, which is a reminder that the SDK still has to work on platform versions far older than current. And the existence of the `TEST_FIXTURE_SYMBOL_DIR` variable shows that a crash report from a native fixture is only readable if the matching symbols are available, which is the same requirement you will have for your own native code.

## Where the SDK is not the answer

The clearest case where this is the wrong tool is an organisation that cannot send crash data to a third party. The notifier is MIT licensed and the source is readable, but the reports land in a hosted service, and there is no self hosted backend in this repository to point it at. If your policy rules that out, the SDK as shipped does not solve your problem, and the realistic alternatives are a crash reporter you host yourself or an in-app logging library with no network component.

A second case is native code you cannot symbolicate. The NDK plugin exists, but a native crash report without the matching unstripped symbols for that build is a report you cannot act on, and the fixture targets in the Makefile show how much of the project's own effort goes into keeping symbols and NDK versions aligned. That discipline has to exist on your side too.

A third is an app that barely crashes. The notifier is a dependency that runs in every session of every user's device, and the project's own `bugsnag-benchmarks/` module exists because the cost of that is a real consideration. Whether the trade is worth it depends on how much of your support load is crash shaped, which is a number you should know before adding the SDK rather than after.

## Release cadence, branches and the licence file

Work on the SDK is regular. v6.27.0 was published on 2026-08-25, v6.27.1 on 2026-09-21 and v6.28.0 on 2026-10-07, and the last push to the repository was on 2026-10-07. The default branch is `next`, with `main` referenced elsewhere for the contributing guide and the licence, so the development branch and the published line are separate, and a `CHANGELOG.md` and an `UPGRADING.md` sit in the tree.

That `UPGRADING.md` file is the file to read before a version bump, since it exists specifically to record breaking changes in a library you embed in a shipped application.

The licence needs one clarification. The repository's metadata lists a custom licence that GitHub cannot classify, while the README states that the SDK is free software released under the MIT License and points to the `LICENSE` file for details. The operative text is the file in the repository, so read it, particularly if you are redistributing the notifier inside a commercial application. The `SECURITY.md` file is where a vulnerability in a component that captures crash data should be reported, and the OpenSSF Scorecard badge in the README header is the project's own published view of its supply chain posture.

## Conclusion

Adopt bugsnag-android if you want a managed crash pipeline for a released Android app and you are willing to send crash data, including stack traces, breadcrumbs and user identifiers, to a third party service, because the SDK is only half of the system. Do not adopt it if your data handling policy forbids sending application data outside your own infrastructure, since the reporting service is a hosted commercial product and the SDK alone has no self hosted backend in this repository. Verify first that the plugin set covers your stack, in particular the NDK plugin if you ship native code, that your build can symbolicate the crash fixtures you will test against, and that the version you adopt matches the release you read the documentation for, with v6.28.0 published on 2026-10-07.

## FAQ

### How do I add crash reporting to an Android app with bugsnag-android?

Create a Bugsnag account, follow the integration guide for reporting unhandled exceptions, report handled exceptions with `Bugsnag.notify`, and adjust the integration through the configuration options. The SDK itself is added as a Gradle dependency to your Android project.

### Is bugsnag-android free to use?

The SDK is open source and the README states it is free software released under the MIT License, with details in the `LICENSE` file. The crash reporting service behind it is a hosted commercial product, and getting started requires a Bugsnag account.

### What does the bugsnag-android NDK plugin do?

The `bugsnag-plugin-android-ndk` module handles native crashes, which a plain Java or Kotlin exception handler never sees. There are also plugins for ANRs, app hangs, Android exit info, OkHttp and React Native, plus a `bugsnag-android-core` module and a `bugsnag-android-http-api` module.

### How is bugsnag-android tested against real devices?

The repository uses Maze Runner for end to end tests through `docker-compose.yml`, with BrowserStack credentials for remote device runs, and the Makefile has a `remote-test` target listing devices such as Google Nexus 5-4.4, Google Pixel-7.1 and Google Pixel 3-9.0. Local instrumentation tests run through `make test`, which calls `./gradlew connectedCheck`.

## Sources

- [bugsnag/bugsnag-android on GitHub](https://github.com/bugsnag/bugsnag-android)
- [Issues](https://github.com/bugsnag/bugsnag-android/issues)
- [Project website](https://www.bugsnag.com/platforms/android/)
- [README](https://github.com/bugsnag/bugsnag-android/blob/next/README.md)
- [Releases](https://github.com/bugsnag/bugsnag-android/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bugsnag-bugsnag-android