Android crash reporting is crucial — unsolved issues can lead to 1-star user reviews and quick uninstalls.
We highlight the best tools on the market and give you best practices for your crash reporting.
Best Android Crash Reporting Tools
Android crash reporting is a simple process. Your crash reporting tools need to fulfill the following requirements:
1.) Find issues and notify you of them
2.) Give access to the crash log
3.) Get context on events and user actions that caused the crash
4.) Provide tools to monitor the health of your app
Without further ado, let’s get to the tools.
Finding crashed sessions AND getting context on it is perhaps the hardest thing about solving app issues.
You can do precisely that with UXCam – an app analytics tool for mobile apps. Start with the crashed sessions report.
Now you’ll get a list of all sessions that crashed. You’ll find information about the device, location, and time when crashes occurred.
You can click on a session to dive deeper. You can watch the session replay to get more context on how the crash happened.
Next, you can click on “Crash” to open up the crash code log.
UXCam tracks all crash types — from stack overflow to out-of-bonds. It even detects ANR (Application not responding) errors.
You can review and copy the crash log to fix it quickly.
To look at crashes on a macro-level, you can use UXCam’s Session Analytics Report. You can go to the crash-tile and group the data by app version, device, or OS version.
In doing so, you’ll quickly find out if a specific app version or device causes any problems.
Crashlytics is a part of Google Firebase (you can find our honest review for Firebase here) and offers a detailed android crash reporting.
Firebase Crashlytics gives you an overview of the health of your app. It also sends you realtime alerts when new issues appear or existing issues grow.
Additionally, Crashlytics offers advice that helps to cure common crash causes.
However, Crashlytics doesn’t give you the full context on crashes as UXCam does with video sessions. You can integrate UXCam with Crashlytics though. This will create a link to the session replay inside the Firebase crash report.
Android Crash Reporting Best Practices
Many performance issues show up unexpectedly…
- …when something doesn’t work as planned.
- …when there are more users or a bigger amount of data as expected.
- …when the app is only tested in a laboratory environment under perfect conditions.
- …and unfortunately they can just be replaced costly.
Perhaps the most important tip for android crash reporting is to test early, often, and under realistic conditions.
Performance testing is a collection of repeated smaller tests
A single crash report won’t tell the developers everything they need to know. To gather expressive and useful data, a combination of smaller tests is needed.
Moreover, it is not useful to test the whole system at once and at the end of the development cycle. An app consists of several parts such as the server, database, service, and the device it is used on.
Test the different parts separately as well as together. But: Testing each part individually doesn’t equal to testing the whole system!
Make performance testing part of the unit tests
Many times performance testing is isolated and shifted backward until the end of the development process. The problem is that it gets more difficult and costly to make changes on the product later.
To get around this problem, it’s good to implement the performance testing to the unity tests or make it part of the agile development test. This helps to identify performance issues early and solve them during the development process.
Set up realistic benchmarks
One strategy which could be followed is to stress test the app with thousands or millions of users and data.
This gives an overview of how much the app can handle at maximum, but doesn’t give a picture of the performance in real-world scenarios where traffic arrives from different devices and operating systems at different times.
It’s more realistic to play around with numbers of devices, systems, and numbers of users. Set up testing environments with the apparently random splitting of devices.
At the same time, the simulation shouldn’t start from zero. The app normally doesn’t start with no server utilization, there will always be users who already have the app and use the server capacity. A realistic test should represent this.
Understand the performance from the user’s perspective
It is easy to cheat during performance testing. The measured speed and the perceived performance from the user’s perspective are not necessarily the same.
Performance metrics tend to focus on the server performance but don’t include the user experience. Additionally, to performance tests, other tests like beta versions and user feedback should be reviewed.
Repeat the tests again and again
Especially during the app development lifecycle, the app gets changed every day. Even if the changes are very small the effects can be huge.
Getting good outcomes at one point in the development process doesn’t mean that this will last until the end. Good performance at a low or medium amount of load doesn’t mean that this will be the same when the load increases.
Extrapolated results can be dangerous. Also, it works in the opposite direction. No minimum performances and requirements based on load tests may be derived from this.
All assumptions should be verified by performance tests.
Test under different network conditions
In the real world, the network conditions of users are constantly changing. They change from one network to another, from low covered regions to completely covered ones to WiFi.
There are hand-overs between different networks. Unforeseen problems can occur quickly and should be avoided as much as possible.
Mobile application performance tests and android crash reporting should run under different and changing network conditions.
Set up as many performance scenarios as necessary
Not every performance problem can be measured during one performance testing scenario.
But there can be restrictions due to the resources for testing. The solution is somewhere in the middle.
The scenarios which are most important, riskiest, and have the greatest impact should be tested.
Combine qualitative and quantitative analytics
Simply being fast isn’t enough for sophisticated users.
An app has to be error-free, bug-free, and user-friendly as well. The combination of quantitative analytics like performance testing and qualitative analytics will increase the app’s success.