How to Diagnose App Issues Using Crash Logs

Last updated: October 2025

Mobile app crashes can be a real headache in the world of software development. They not only lead to user frustration and productivity loss but also tarnish your organization’s reputation. As a mobile developer, one of the most valuable tools in your troubleshooting arsenal is the crash log. 

When mobile apps crash, they generate logs that contain information related to the issues that caused the crash. Examining the log is a good starting point for diagnosing and resolving the crash.

In this post, we’ll investigate the cause of a crash in an example Android app called Short Code Manager. Short code Manager does the following:

• Allow users to store short USSD codes, such as *123#.
• Have a user interface (UI) that enables the app user to dial short codes directly from the app.

The issue we will be diagnosing occurred in an early release of Short Code Manager. For some users, the app crashed whenever they attempted to dial USSD codes from the app. At the end of this post, I’ll show you how to diagnose and fix the issue using crash logs and how SolarWinds Papertrail can be an invaluable ally in this process. 

Prerequisites 

Before we get started, make sure you have the following so you can follow along with this tutorial:

• A basic understanding of Java and Gradle.
• The current version of the Android Studio IDE and Android SDK installed. You can download Android Studio for Windows, Mac, or Linux from the official download page. The Android SDK will automatically install the first time you launch Android Studio.
• An Android device or emulator to run our example app. You can set up an emulator on Android Studio via the AVD Manager.
• Gradle and other dependencies used in the project, installed and upgraded to their latest versions. 

The source code for the example app is available here.

Understanding Crash Logs 

Crash logs are files that contain information about the state of an application when it unexpectedly terminates or crashes. They can help developers identify and fix the root causes of app issues, such as bugs, memory leaks, or compatibility problems. Crash logs can also provide helpful feedback for improving the app’s performance, stability, and user experience.

Types of Android Crash Logs 

Crash logs in Android development can be categorized into two main types: native crashes and Java crashes.

• Native crashes: These crashes occur in the native code, typically written in languages like C or C++. The associated logs provide detailed information about the crash’s low-level details.
• Java crashes: Java crashes involve issues in the application’s Java code. The logs contain information about the Java stack trace, helping developers identify the problematic Java methods. 

Components of an App Crash Log 

Crash logs typically include some of the following key information:

• Stack trace: This is the most critical part of the crash log. It shows the sequence of method calls that led to the crash, starting from the main method or entry point of the app. It helps you pinpoint the exact location in your code where the crash occurred. 
• Exception type and message: This information tells you what kind of error or exception caused the crash. It’s often accompanied by a description that can help you understand the issue (such as NullPointerException or OutOfMemoryError).
• Caused by: If another exception causes the exception, this section will provide information about the root cause. It’s essential to trace back through these causes to find the initial trigger.
• Thread information: Crash logs may contain details about the threads running in your app at the time of the crash. You can use this information to identify potential concurrency issues.
• Device information: The logs also include details about the device, such as the model, operating system version, and memory usage. This can help reproduce the issue on specific devices.
• Date and time: Indicates when the crash occurred. 

Reasons Why an App Might Crash 

Several factors can trigger app crashes, including:

• User actions: Unpredictable user interactions, such as rapid tapping, entering unexpected data, or executing actions not accommodated by the app’s design, can lead to crashes. 
• Operating system updates: Changes in the underlying operating system can sometimes clash with an app’s code, resulting in crashes if the app isn’t updated to sync with the latest OS version. 
• Memory issues: Apps may crash if they consume more memory than the device can provide, often due to memory leaks, inefficient memory management, or extensive data processing. 
• Uncaught exceptions and poor error handling: Inadequate error-handling mechanisms can spell disaster. Uncaught exceptions—whether they’re related to network issues, unexpected user inputs, or system failures—can cause abrupt app termination.
• Compatibility and resource issues: Apps must seamlessly function across diverse devices, operating systems, and versions. Incompatibility with specific device elements or other installed apps can result in crashes.
• Network connectivity problems: Apps heavily reliant on network connections may falter if they mishandle network-related issues, such as poor connectivity, timeouts, or server-side problems. 

Getting the Crash Log 

In this section, we will guide you through four steps to obtain the crash log after your app crashes. We’ll use Android Studio while running the example app on a physical Android phone. If you don’t have an Android phone, you can use an emulator as an alternative.

Step 1: Enable USB debugging on device 

To enable communication between the Android Debug Bridge (ADB) and a physical Android device, we need to enable Developer options and USB debugging. The steps may vary slightly across devices. For a Google Pixel device, for example, follow these steps:

• Navigate to Settings ➜ About phone.
• Find Build number and tap it seven times. You should receive a message that says, “You are now a developer.”
• Return to the main Settings UI. Navigate to System, which has a new system setting for Developer options.
• In Developer options, toggle USB debugging to on. 

If you use a different model of Android device, you should be able to find device-specific steps to enable Developer options and USB debugging for your device.

If you are running the app on an emulator, you can skip the above step.

Step 2: Install the app via Android Studio and ADB 

With USB debugging enabled, Android Studio should be able to detect the Android device connected to your computer via a standard USB cable. If you are connecting a device for the first time, a prompt may be displayed on your Android device requesting permission to allow ADB to connect. Make sure you accept the request.

Check “Always allow from this computer” to prevent the dialog from showing in the future. 
Ensure your device or emulator is selected in the Android Studio device drop-down menu, and then click the green play button to install the app, just as you would during debugging.

Step 3: Produce the crash

Let’s try to crash our example app. After the app has been installed and is running, add some short codes using the app’s UI. With some codes already saved, let’s try to dial one of the codes. In some cases, our app is expected to crash. However, for this article, we’ve written the code for the app so that it crashes on the first try, allowing us to receive the crash log message instantly. In real-life and production applications, the case is quite different. We’ll discuss that later in the post. 

To dial a code, tap the phone icon next to the code on the app UI. 

Just after that, the app crashes with a message like “Short Code has stopped working…” and force closes.

Step 4: Investigate the crash using LogCat 

With the device already connected via USB before the crash occurred, Android Studio’s Logcat feature will display information about the app and the crash.

To switch to Logcat view on Android Studio, click on the Logcat label in the bottom tool window. 

Below is the report from Logcat just after the crash occurred: 

The Logcat window allows you to search and filter logs. Changing the log level to Error helps narrow down the issues, allowing us to identify the critical problem that caused the app crash. The Logcat window also shows the current device and app (using the package name). Ensure you are reading logs for the correct device and app.

The following info from the log trace gives some clues about why our app crashed:

java.lang.SecurityException: Permission Denial: starting Intent { 
     act=android.intent.action.CALL dat=tel:xxx 
     cmp=com.android.server.telecom/.components.UserCallActivity }

Reading the trace further, we can see where the error occurred in our app, including the associated class and line of code. From the information provided in Logcat, we can diagnose the cause of the crash and start working on a fix.

Fixing the Crash 

Fortunately, the log entry included sufficient information, allowing us to pinpoint which part of our code was executing immediately before the crash. Creating event messages like this is crucial for quickly identifying what’s happening. If you’re interested in some best practices for creating event messages, check out the article on JSON logging.

Logcat shows that our app crashed due to a security exception. In Android, before an application can use specific operating system (OS) features and services—such as the camera, phone calls, internet, and read/write storage—the app must request permission, and the user must grant access. 

Our example app requires permission to make phone calls (android.permission.CALL_PHONE). Currently, the app doesn’t verify whether the user has granted the app permission. We just have a method that kickstarts the phone call. Not explicitly confirming that the user has granted the required permission may lead to crashes on specific devices and Android versions.

To resolve this issue, we must verify that users on the affected OS version have granted the necessary permissions before running the code that initiates a phone call.

Crashing Is Inevitable. Burning Is Optional 

By running our app on a device connected to Android Studio via ADB, we were able to view crash logs on Logcat. We used the information from Logcat to detect the issue with our app. Logcat also reports the class, method, and line of code associated with the crash. Thanks to that, we were able to diagnose and fix the issue that caused our example Short Code Manager app to crash.

Our example here is a simple case. In production applications, diagnosing issues in an app could be more complex. Logcat alone can’t help you detect and fix problems. For example, an application in production might:

• Be installed on hundreds, thousands, or even more devices.
• Be installed on devices with various configurations (e.g., different releases of Android).
• Include user-specific logic to generate behavior for different users based on their accounts and user-generated content.
• Include integrations with external services or other applications. 

For the above cases, much more effort is required to collect logs effectively.

As a developer, you can only test on a limited number of devices, and users are very likely to interact with your apps in new and unexpected ways that you didn’t imagine. It’s essential to diagnose app crashes promptly and provide a timely fix to prevent a poor user experience.

While Logcat is a powerful tool for retrieving crash logs and debugging apps during development, the process becomes more intricate when dealing with production-level apps across multiple devices and users. This is where services like SolarWinds Papertrail come in handy.

How SolarWinds Papertrail Can Help 

SolarWinds Papertrail is a cloud-based logging management solution that efficiently collects, centralizes, and analyzes logs from various sources, including applications, servers, and systems. SolarWinds Papertrail combines logs from multiple services and applications, allowing you to search them from a single UI.

For crash logs, the tail feature in SolarWinds Papertrail is invaluable. You can livestream logs (like you would at the command line with tail -f) and search and filter them as they’re written.

Interested in seeing this for yourself? Sign up for a free SolarWinds Papertrail trial today!