Articles in this section

See more

Handling Mobile App Crashes and Stack Traces: Android

Amir Rozenberg Agent
  • Updated
Follow

Table of Contents

Introduction

The Blue Triangle SDK captures and reports crashes and errors to help correlate user-experience issues with business impact. Because of this, you may see Blue Triangle SDK methods appear in a crash stack trace. This does not necessarily mean the SDK caused the crash—only that it detected the crash and was in the call chain when it reported it.

Example: User Tap

Consider the following example, where a button’s touch listener triggers an exception:

checkoutButton.setOnTouchListener { v, e ->
    emptyList<String>()[99] // throws an IndexOutOfBoundsException
    true
}

When the user taps this button, the app crashes inside your touch listener due to the out-of-bounds access. Because the BlueTriangle SDK intercepts touch events for tracking purposes, the crash stack trace will show BlueTriangle frames above the line where the exception occurred. This may give the appearance that the crash is related to our SDK, but in this scenario, the root cause lies entirely within your app’s touch-handling code.

Sample Stack Trace

Below is an example of how this crash appears in Android Studio. Notice that the crash originates from your app’s code, while Blue Triangle appears higher in the stack only because it intercepts touch events for tracking:

java.lang.IndexOutOfBoundsException: Empty list doesn't contain element at index 99.
        at kotlin.collections.EmptyList.get(Collections.kt:37)
        at kotlin.collections.EmptyList.get(Collections.kt:25)
        at com.example.ui.cart.CartFragment.onCreateView$lambda$6(CartFragment.kt:72)
        ...
        at android.app.Activity.dispatchTouchEvent(Activity.java:4196)
        at androidx.appcompat.view.WindowCallbackWrapper.dispatchTouchEvent(WindowCallbackWrapper.java:70)
        at com.bluetriangle.analytics.screenTracking.TouchEventInterceptor.dispatchTouchEvent(TouchEventInterceptor.kt:31)
        at fsimpl.H.a(Unknown Source:20)
        at fsimpl.H.b(Unknown Source:46)

In this case, the exception is clearly thrown within your app’s own logic (CartFragment.kt:72). The BlueTriangle entries appear only because the SDK is integrated into the event dispatch chain, not because it caused the crash.

 

Best Practices: Determining Whether a Crash Originates from the SDK or the App

When the crash is likely to originate in the Blue Triangle SDK

A crash can potentially be attributed to the BlueTriangle SDK when the root cause—the initial frames of the “Crashed” stack—points directly to classes within our package name: com.bluetriangle.analytics.

Example Scenario

Suppose your crash reporting tool shows the following stack trace:

java.util.ConcurrentModificationException:
       at java.util.ArrayList$Itr.checkForComodification(ArrayList.java:1111)
       at java.util.ArrayList$Itr.next(ArrayList.java:1064)
       at com.bluetriangle.analytics.screenTracking.ActivityLifecycleTracker.unregister(ActivityLifecycleTracker.java:75)
       at com.bluetriangle.analytics.Tracker.deInitializeScreenTracker(Tracker.kt:266)
       at com.bluetriangle.analytics.Tracker.updateSession$analytics_release(Tracker.kt:689)
       at com.bluetriangle.analytics.sessionmanager.SessionManager$observeAndUpdateSession$1$1.invokeSuspend(SessionManager.kt:181)
       at com.bluetriangle.analytics.sessionmanager.SessionManager$observeAndUpdateSession$1$1.invoke(SessionManager.kt:12)
       at com.bluetriangle.analytics.sessionmanager.SessionManager$observeAndUpdateSession$1$1.invoke(SessionManager.kt:12)

In this example, the earliest frames referencing your app’s failure point clearly involve classes under the com.bluetriangle.analytics package. This indicates that the crash was triggered within the BlueTriangle SDK itself.

 

When the crash is unlikely to originate in Blue Triangle SDK

A crash unlikely to be caused by the BlueTriangle SDK when the com.bluetriangle.analytics package appears somewhere in the stack trace but not in the root cause frames. In these cases, your application code invoked our SDK, but the crash originated from your own logic.

Example Scenario

java.lang.IndexOutOfBoundsException: Empty list doesn't contain element at index 99.
      at kotlin.collections.EmptyList.get(Collections.kt:37)
      at kotlin.collections.EmptyList.get(Collections.kt:25)
      at com.example.ui.cart.CartFragment.onCreateView$lambda$6(CartFragment.kt:72)
      ...
      at android.app.Activity.dispatchTouchEvent(Activity.java:4196)
      at androidx.appcompat.view.WindowCallbackWrapper.dispatchTouchEvent(WindowCallbackWrapper.java:70)
      at com.bluetriangle.analytics.screenTracking.TouchEventInterceptor.dispatchTouchEvent(TouchEventInterceptor.kt:31)
      at fsimpl.H.a(Unknown Source:20)
      at fsimpl.H.b(Unknown Source:46)

In this example, the crash is clearly caused inside the app’s own code (CartFragment.onCreateView, line 72). The BlueTriangle method TouchEventInterceptor.dispatchTouchEvent only appears later in the stack trace because the SDK is involved in processing user touch events, not because it triggered the exception.

Summary

When investigating an app crash:

  • Start by reviewing the crash in the Error Explorer within the portal. There, you can see details such as the device, OS version, application version, and SDK version. If you have session replay enabled, you can also view the user’s actions leading up to the crash. Together, these details can help narrow down the root cause.

  • Share the crash information—including app details, the stack trace, and any other relevant context—with Blue Triangle’s customer support team for further assistance.

 

 

 

Related articles

Comments

0 comments

Please sign in to leave a comment.