ACRA v4 IS NOW STABLE!

A new version of ACRA is available. Lots of new data are added to reports (did you want some logcat?) and new features like an API to let you implement your own report sender. Please join the discussion on acra-discuss !

The Beta is over, ACRA v4 is now the only supported version. Docs for previous versions are still available in the Wiki but there won't be any bugfix or change in v3.X (and v2.X).

I would like to thank every one of you who helped by testing, reporting issues and discussing about the project during these months. Many special thanks go to Isneesh, William, Pierre-Yves and Scott.

- Kevin

What is ACRA ?

ACRA is a library enabling Android Application to automatically post their crash reports to a GoogleDoc form. It is targetted to android applications developers to help them get data from their applications when they crash or behave erroneously.

See BasicSetup for a step-by-step installation and usage guide.

A crash reporting feature for android apps is native since Android 2.2 (FroYo) but only available through the official Android Market (and with limited data). ACRA is a great help for Android developers :

• developer configurable user interaction : silent reports, Toast notification, status bar notification + dialog
• usable with ALL versions of android (compiled with 1.5, not tested on 1.0/1.1 but might work... but who does really care ?)
• more detailed crash reports about the device running the app than what is displayed in the Android Market developer console error reports
• you can add your own variables content or debug traces to the reports
• you can send error reports even if the application doesn't crash
• works for any application even if not delivered through Google's Android Market => great for devices/regions where the Android Market is not available, beta releases or for enterprise private apps
• can be used with your own self-hosted report receiver script
• google doc reports can be shared with a whole development team. Other benefits from the Google Docs platform are still to be investigated (stats, macros...)

ACRA's notification systems are clean. If a crash occurs, your application does not add user notifications over system's crash notifications or reporting features. If you use the Toast or Status bar notification modes, the "force close" dialog is not displayed anymore and devices where the system native reporting feature is enabled do not offer the user to send an additional report.

The user is notified of an error only once, and you might add the percieved quality of your application by defining your own texts in the notifications/dialogs.

Please do not hesitate to open defects/enhancements requests in the issue tracker.

ACRA v4.X main new features

You can read in the ChangeLog that many things have been added since ACRA 3.1. Here is a summary:

• In addition to standard logcat data, reports can contain eventslog and radioevents data
• Reports will contain the result of the "adb shell dumpsys meminfo <pid>" command which gives details about your application memory usage right after the crash.
• Introduction of an abstraction layer for report senders. This allows to:
• use the formUri parameter to send reports to your custom server script with POST parameters names not related to Google Forms naming. POST parameters will have easy to understand names.
• introduce a new report sending mode: email (see below)
• create your own custom report senders. There is now a simple public interface allowing you to code your own class in charge of handling report data. Your sender(s) can be added to default senders or replace them.
• Reports can now be sent via email (through an ACTION_SEND intent so the user has to choose the email client he wants to use and then send the email containing report fields in the body). The list of report fields included is configurable. This allows to get rid of the INTERNET permission in apps where it does not make any sense.
• Custom report receiver server scripts can be secured with basic http authentication (login/password can be configured in ACRA)
• If the READ_PHONE_STATE permission is granted, reports include the Unique Device Identifier (IMEI). This can be really useful for enterprise applications deployment.

And after that?

Now that ACRA is stabilized on the device side (there shouldn't be much more data required...), the effort should be placed on crash data analysis and reports management tools for developers.

You can look at some contributions that have already been published. Most of them are work in progress, so if you feel like joining the effort, please do!