ACRA for Android: self-hosted crash reports without a Play Console
Application Crash Reports for Android
At a glance
- What is it?
- ACRA is an Apache-2.0 Kotlin library that catches uncaught exceptions in Android apps and delivers reports through senders you configure, including your own HTTP endpoint. It suits teams that ship outside Google Play or want report fields the Play Console does not expose.
- Who is it for?
- Adopt ACRA if your app ships outside Google Play, targets enterprise or regional devices, or needs report fields and user interaction the Play Console does not give you; skip it if Play Console crash data is enough or you cannot operate a report receiver.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The gap ACRA fills for Android developers
Android has had a native crash reporting path since Android 2.2 (FroYo), but the README is explicit that it is only available through the official Android Market and carries limited data. That is the constraint ACRA was built around. If your app is distributed through Google Play, you get a console view of crashes. If it is a private enterprise build, a beta APK, or an app for a region where Google Play is unavailable, that console view either does not exist or does not cover your users.
ACRA is aimed at that second group. The README lists the intended audience through features rather than a persona: developer-configurable user interaction (silent reports, Toast notification, status bar notification or dialog), more detailed crash reports about the device than the Android Market developer console shows, custom variables and debug traces attached to reports, and reports for caught exceptions or unexpected application state where no exception was thrown. It also works for any application even if not delivered through Google Play.
The library ships as a set of Gradle modules rather than a monolith. The repository root contains acra-core, acra-http, acra-mail, acra-dialog, acra-notification, acra-toast, acra-limiter and acra-advanced-scheduler, so you pull in only the sender and interaction surface you actually use. That modularity is the main architectural decision to understand before adopting it.
How ACRA captures, stores and sends a report
The data flow has four stages visible in the README and the module layout. First, ACRA installs an uncaught exception handler. When a crash occurs, the default Android force close dialog is suppressed unless you set alsoReportToAndroidFramework to true. That flag is the switch between ACRA owning the crash UX and the platform owning it.
Second, ACRA builds a report from a field set. The README points at the ReportField Javadoc for the list of device details included, and notes you can add your own variables or debug traces. Third, the report is handed to a sender. acra-http posts to an endpoint, acra-mail sends email, and the README states you can use your own self-hosted report receiver script. Fourth, delivery is not guaranteed on the spot: if there is no network coverage, reports are kept and sent on a later application restart. That persistence behavior is the reason ACRA works on flaky connections, and it is also the reason a report can arrive long after the crash it describes.
The interaction layer is separate from the sending layer. acra-dialog, acra-notification and acra-toast control how the user is told, and the README states the user is notified of an error only once. acra-limiter and acra-advanced-scheduler sit alongside these to constrain how often reports are produced or dispatched. If you skip those modules, nothing stops a crash loop from generating a report per iteration.
Installing ACRA and sending a first report
The README does not inline installation steps. It points to the website at acra.ch/docs/Setup for a step-by-step guide, and the repository carries the directories examples/acra-basic-java-example and examples/acra-basic-kotlin-example for both languages. The README states the artifacts are published to Maven Central under the ch.acra group, and the release list names acra-5.13.1 as the most recent tag. No Gradle snippet, annotation example or configuration file appears in the README or in the repository files available here, so this section gives the module list and the documented keys rather than copyable code.
The modules you would depend on are named in the repository root: acra-core for the core library, acra-http for the HTTP sender, and one of acra-dialog, acra-notification or acra-toast for user interaction. The README names two configuration keys: alsoReportToAndroidFramework, which re-enables the platform force close dialog, and the sender URI, which must point at a receiver you operate. The README links to guidance on writing your own self-hosted report receiver script.
What you should expect after a forced crash is the interaction you configured (a Toast, a dialog, a status bar notification, or nothing at all if you chose silent reports), followed by a POST to your endpoint. If the device was offline at crash time, the README states the report is kept and sent on a later application restart. The README does not document a rollback procedure for reports already queued.
Where ACRA is the wrong choice
The clearest limitation is operational, not technical. ACRA collects and sends; it does not store or analyze. The README names Acrarium as the official backend and says it is still in active development. Acralyzer was the official backend before that, runs on CouchDB, is described as feature complete but currently unmaintained, with an open invitation for anyone to pick it up. A team that adopts ACRA without a plan for the receiving end has a sender and nowhere to send.
There is a second boundary around the crash UX. Suppressing the force close dialog is the default, and that is a deliberate trade: the user sees your Toast or dialog instead of the system one, and the README states the user is notified only once. For apps where users expect the standard Android crash dialog, or where support flows depend on it, that default is a behavior change you must own.
The third boundary is the distribution assumption. ACRA's value proposition is strongest when Play Console data is missing or thin. If your app is on Google Play and the console view already answers your questions, adding a library, a sender module and a report receiver is overhead with no new signal. The README's own statistics section cites 1.57% of Google Play apps as of June 2020, which is a measure of reach, not of whether the library fits your case.
ACRA against Firebase Crashlytics
The honest alternative is Firebase Crashlytics, and the difference is where the data lands. Crashlytics is a hosted pipeline: you add the SDK, crashes appear in a Google-operated dashboard, and you do not run a receiver. ACRA is the opposite arrangement. The README positions it around senders you choose, including your own self-hosted report receiver script, and around report fields the Android Market console does not show.
That difference decides the choice. If you want zero infrastructure and you are comfortable with a hosted backend, ACRA's sender configuration is work you do not need to do. If you need reports to stay inside your own network, or you are shipping to devices where Google Play services are absent, a hosted pipeline is not an option and ACRA's self-hosted path is the point. The cost is that you own uptime, storage and retention for the receiver, and the README leaves that side to you or to Acrarium.
A second, smaller difference is the interaction surface. ACRA exposes silent reports, Toast, status bar notification and dialog as developer-configurable options, and lets you define your own notification text. A hosted SDK typically fixes that UX. If you care about what the user sees at the moment of a crash, ACRA gives you the dial.
Maintenance, versions and licence cost
The last push to the repository was on 2026-09-19, and the most recent release listed is acra-5.13.1 from 2025-09-28. Earlier releases in the list are acra-5.12.0 from 2024-11-03 and acra-5.11.4 from 2024-09-13. Read those dates together: commit activity and tagged releases do not move at the same pace, so pinning a version and tracking the release page is more useful than watching the branch. The README also points to a migration guide in the wiki for moving from 4.x, which tells you the 4.x to 5.x jump is not a drop-in.
Upgrade cost is concentrated in the annotation-driven configuration and the module split. Because senders and interaction modules are separate artifacts, a version bump can require coordinated changes across several dependency lines. The repository includes renovate.json, which suggests dependency updates are automated on the maintainer side, but that does not remove the work on yours.
ACRA is licensed under Apache-2.0, and the repository carries both a LICENSE and a NOTICE file. Apache-2.0 permits commercial and closed-source use and requires that the licence and notice be preserved. The NOTICE file existing separately means there is attribution material to carry into your distribution; how that interacts with your own legal obligations is a question for your counsel, not something this article can settle. The README does not discuss licence exceptions or commercial support terms.
Editorial conclusion
Adopt ACRA if your app ships outside Google Play, targets enterprise or regional devices, or needs report fields and user interaction the Play Console does not give you; skip it if Play Console crash data is enough or you cannot operate a report receiver. Before committing, verify three things in the repository: which sender module matches your backend, whether the Gradle coordinates you intend to use resolve from Maven Central, and whether the Acrarium backend status still matches your storage plan, since the README describes Acralyzer as unmaintained.
Frequently asked questions
What does ACRA mean in this project?
The repository is named ACRA and described as Application Crash Reports for Android. The README does not expand the acronym further than that description.
What is the full name of ACRA?
The repository description gives the full name as Application Crash Reports for Android. The project is published under the ch.acra Maven group.
Does ACRA work for apps that are not distributed through Google Play?
Yes. The README states ACRA works for any application even if not delivered through Google Play, and names beta releases, enterprise private apps, and devices or regions where Google Play is unavailable as the cases it fits.
What happens to an ACRA report if the device has no network at crash time?
The README states that if there is no network coverage, reports are kept and sent on a later application restart. Delivery is therefore deferred rather than dropped.
Which backend does ACRA use to store reports?
ACRA itself sends reports through configurable senders, including your own self-hosted receiver script. The README names Acrarium as the official backend and notes it is still in active development, while Acralyzer, the previous official backend running on CouchDB, is described as feature complete but currently unmaintained.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/acra-acra)