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 what the resulting crash log looks like in Android Studio. Note that the crash originates from inside the app code, while Blue Triangle appear higher in the stack simply because it intercepts the user event:
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)
Though the stack trace may contain
com.bluetriangle.analytics.screenTracking.TouchEventInterceptor.dispatchTouchEvent(TouchEventInterceptor.kt:31)
this is not originated from the BlueTriangle SDK.
Since the SDK intercepts touch events before forwarding them back to Android’s original event handling flow, the SDK can appear in the stack trace even when the actual crash occurs inside application code.
For example, the following frames indicate that the touch event passed through the BlueTriangle interception layer and was handed back to the Android framework:
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)
The real crash in this example actually occurs at:
at com.example.ui.cart.CartFragment.onCreateView$lambda$6(CartFragment.kt:72)
Unlike the above example, in some special cases the first few frames may not clearly indicate application code. Still, the presence of:
com.bluetriangle.analytics.screenTracking.TouchEventInterceptor.dispatchTouchEvent(TouchEventInterceptor.kt:31)
indicates that the BlueTriangle interceptor passed execution successfully back to the Android framework, and the issue could instead be related to the application’s event handling or memory management logic.
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.
Comments
0 comments
Please sign in to leave a comment.