How to Diagnose and Fix Android Crashes with RUM: A Step‑by‑Step Guide

Background

The previous article explained the Java‑layer crash capture mechanism, native signal handling, Minidump processing, and symbolization of obfuscated stacks. With that theory understood, we now reproduce a production‑level issue to show how an Android developer can use RUM to collect exception data, correlate it with user context, and complete the full crash‑analysis workflow from alert to root‑cause identification.

Case Overview

A new v3.5.0 release optimized the product‑list loading performance. Three days after launch, users reported frequent app crashes and flash‑backs. The severity included a sharp increase in crash rate, lower app‑store rating, and higher uninstall rate.

Step 1 – Receive Crash Alert

When the crash rate exceeds the configured threshold, the RUM platform sends an alert to the development team. The alert includes a query example:

app.name: xxx and crash | SELECT diff[1] AS "Current", diff[2] AS "Yesterday", round(diff[3],4) AS "Ratio" FROM (SELECT compare(cnt,86400) AS diff FROM (SELECT COUNT(*) AS cnt FROM log)) ORDER BY "Current" DESC

Step 2 – View Crash Overview

In the console navigate: Home → User Experience Monitoring → Crash Statistics → Application . The crash list shows that IndexOutOfBoundsException dominates the failures, especially for version v3.5.0 .

Step 3 – Analyze Crash Stack (Initial定位)

Click the crash entry to see the stack trace. The relevant line is:

at com.example.ui.ProductListAdapter.onBindViewHolder(ProductListAdapter.java:50)

The exception message indicates an attempt to access index 5 in a list that only contains 5 items (valid indices 0‑4).

Step 4 – Trace User Behavior

Open the crash detail page, view the associated session ID, and follow the user’s action path:

Enter ProductListActivity

Rapidly tap the refresh button three times

Each tap triggers an asynchronous network request that updates the product list

Because multiple requests run concurrently, the UI may still be rendering an old item when the data set shrinks, leading to the out‑of‑bounds access.

Step 5 – Multi‑Dimensional Analysis

Use the RUM dashboard to filter crashes by network type, device brand, and app version. The data shows that 90% of crashes occur on 3G/4G networks, confirming that network latency and race conditions are the key factors. All device brands are affected, indicating a code‑logic issue rather than hardware.

Step 6 – Locate Problem Code

Open ProductListActivity.java and examine the data‑loading method:

private void loadProducts() { // v3.5.0 change: async loading for performance
    new Thread(() -> {
        try {
            List<Product> newProducts = ApiClient.getProducts(currentCategory);
            // Issues: no cancellation of previous request; direct clear & update while RecyclerView may be rendering
            runOnUiThread(() -> {
                productList.clear(); // dangerous
                productList.addAll(newProducts);
                adapter.notifyDataSetChanged();
            });
        } catch (Exception e) {
            e.printStackTrace();
        }
    }).start();
}

And the adapter binding:

@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 rapid refreshes start concurrent requests without cancellation.

Later request clears the list and updates it while RecyclerView is still rendering the previous item.

The UI state inconsistency causes the out‑of‑bounds access.

Step 7 – Symbolication (Making Stacks Human‑Readable)

Because release builds are obfuscated with ProGuard/R8, the original stack appears as:

java.lang.IndexOutOfBoundsException: Index: 5, Size: 5
    at java.util.ArrayList.get(ArrayList.java:437)
    at com.shop.a.b.c.d.a(Proguard:58)

Upload the mapping.txt file (found at app/build/outputs/mapping/release/mapping.txt) and the native .so symbol files to the RUM console. After uploading, the stack is de‑obfuscated to show the exact class, method, file, and line number.

Step 8 – Verify Symbolication

The de‑obfuscated stack now displays full class names, source file paths, and line numbers for both Java and native frames, confirming the exact crash location.

Key Takeaways

RUM provides complete, symbolized stack traces linked to precise user sessions.

Multi‑dimensional analysis (network, device, version) helps pinpoint environmental factors.

Session tracing reveals the exact user actions that triggered the crash.

Symbolication turns obfuscated stacks into readable code locations, enabling fast root‑cause identification.

Real‑time alerts allow immediate investigation, reducing mean‑time‑to‑repair.

Symbolication Procedure (Java/Kotlin)

Locate mapping file: After a release build, the mapping file is generated at app/build/outputs/mapping/release/mapping.txt.

Upload mapping to console: Log in to the RUM console, go to User Experience Monitoring → Application → Settings → Symbol Files , and upload the mapping.txt file.

Upload native symbols: For native crashes, upload the corresponding .so files located under

app/build/intermediates/cxx/release/…/obj/<abi>/yourlib.so

for each architecture (arm64‑v8a, armeabi‑v7a, x86_64).

Verify: Open a crash detail page, select the uploaded symbol files, and view the de‑obfuscated stack.

Related Links

Integration Guide: https://help.aliyun.com/zh/arms/user-experience-monitoring/access-to-android-applications