How to Diagnose Android Crash Issues with RUM: A Step‑by‑Step Case Study

Background

App version v3.5.0 introduced asynchronous loading to improve performance. After three days the crash rate increased more than tenfold, causing user complaints, rating drops, and higher uninstall rates.

Investigation Process

Step 1 – Receive Crash Alert

RUM sends an alert when the crash rate exceeds the configured threshold.

Step 2 – Crash Overview

The dominant exception is IndexOutOfBoundsException occurring in ProductListAdapter.onBindViewHolder (line 50).

Exception type: IndexOutOfBoundsException Location:

ProductListAdapter.java:50

Step 3 – Stack Trace

The stack trace points to ProductListAdapter.onBindViewHolder() where the list index is out of bounds.

Crash location: ProductListAdapter.java:50

Method:

onBindViewHolder()

Step 4 – User Behavior

Session data shows the user opened ProductListActivity , tapped the refresh button three times, and triggered asynchronous list updates.

Step 5 – Multi‑Dimensional Analysis

v3.4.0 crash rate: 0.08%

v3.5.0 crash rate: 1.25% (≈82.5% increase)

90% of crashes occurred on 3G/4G networks, indicating that asynchronous network requests are a key factor.

All device brands were affected, ruling out hardware‑specific issues.

Step 6 – Locate Code Issue

The async loading logic clears the list before the RecyclerView finishes rendering, causing a data race.

private void loadProducts() {
    // v3.5.0 change: async loading for performance
    new Thread(() -> {
        try {
            List<Product> newProducts = ApiClient.getProducts(currentCategory);
            // Issue 1: previous request not cancelled
            // Issue 2: clear data without considering RecyclerView state
            runOnUiThread(() -> {
                productList.clear(); // dangerous operation
                productList.addAll(newProducts);
                adapter.notifyDataSetChanged();
            });
        } catch (Exception e) {
            e.printStackTrace();
        }
    }).start();
}

@Override
public void onBindViewHolder(@NonNull ProductViewHolder holder, int position) {
    // Crash point: position may exceed list size
    Product product = products.get(position); // IndexOutOfBoundsException!
    holder.bind(product);
}

Root cause: multiple concurrent async requests lead to list size mismatch when the UI renders a stale index.

Symbolization Configuration

Release builds are obfuscated with ProGuard/R8, producing unreadable stack traces. Upload the mapping.txt file to the RUM console to de‑obfuscate Java stacks.

# Example mapping.txt
com.example.ui.MainActivity -> a.b.c.MainActivity:
    void updateUserProfile(com.example.model.User) -> a
    void onClick(android.view.View) -> b
com.example.model.User -> a.b.d.User:
    java.lang.String userName -> a
    void setUserName(java.lang.String) -> a

Locate the file at app/build/outputs/mapping/release/mapping.txt.

Log in to the Alibaba Cloud console → User Experience Monitoring → Application Settings → File Management.

Upload the mapping file.

Native Symbolization

Upload the corresponding .so files for each architecture (arm64‑v8a, armeabi‑v7a, x86_64).

app/build/intermediates/cxx/release/xxx/obj/
├── arm64-v8a/   └── xxx-native.so   // contains debug symbols
├── armeabi-v7a/ └── xxx-native.so
└── x86_64/     └── xxx-native.so

Case Summary

Complete stack information – after symbolization the exact line ProductListAdapter.java:50 was identified.

User‑behavior tracing – rapid multiple refresh clicks were the trigger.

Multi‑dimensional analysis – network‑type and version comparison quantified the impact.

Real‑time alerts – the team received an alarm as soon as the crash rate spiked.

Impact quantification – 90% of crashes occurred on 3G/4G, confirming the async request timing issue.