Why Android Apps Crash with TransactionTooLargeException and How to Fix It

Preliminary Analysis

The Douyin Android team observed a spike in crashes over the past three months, with the top issue being a TransactionTooLargeException triggered during Activity stop. Multi‑dimensional feature analysis showed that high‑end OS versions and Samsung devices were most affected.

Device models: scattered, Samsung SM‑S9180 top 1.

Channels: Huawei, Xiaomi, Samsung top 3.

OS versions: Android 10‑13 dominate, Android 5.1.1 excluded.

App minor versions: align with daily active users.

The conclusion was that the crash is related to high OS versions and Samsung devices.

Crash Stack

The crash type is TransactionTooLargeException with the message

data parcel size xxx bytes

. The stack points to

BinderProxy.transactNative

near the crash site.

Key findings:

The exception is caused by Binder data transmission exceeding the driver limit.

System logs contain only Binder failure messages, no business‑level stack traces.

Log analysis showed the error code

FAILED_TRANSACTION

originates from

IPCThreadState::waitForResponse

and is associated with Bundle data.

Root Cause

During Activity stop, the system sends the Bundle saved by

Activity.onSaveInstanceState

to the ActivityManagerService (AMS) via Binder. When the Bundle size exceeds the Binder receive buffer (max ~1 MB per process), allocation fails, leading to

TransactionTooLargeException

. The failure occurs because the system’s Binder buffer cannot accommodate the large Bundle.

Solution Overview

The fix avoids modifying the kernel Binder driver and instead intercepts Bundle handling at the app level:

Register

Application.registerActivityLifecycleCallbacks

to hook

onActivityPostSaveInstanceState

and

onActivityPreCreated

.

After

onSaveInstanceState

, serialize the Bundle; if its size > 1 KB, generate a UUID, store the original Bundle in an in‑memory map, and replace the Bundle with a small key entry.

Before

onRestoreInstanceState

, retrieve the original Bundle from the map using the UUID and restore it.

This reduces the data transmitted over Binder to a tiny key, preventing the transaction failure.

Implementation Details

Key code snippets:

<code>// Hook after onSaveInstanceState
public void onActivityPostSaveInstanceState(Activity activity, Bundle outState) {
    outState.clear();
    String uuid = UUID.randomUUID().toString();
    sKey2ContentMap.put(uuid, outState);
    outState.putString("TransactionTooLargeOptKey", uuid);
}

// Hook before onRestoreInstanceState
public void onActivityPreCreated(Activity activity, Bundle savedInstanceState) {
    if (savedInstanceState != null) {
        String uuid = savedInstanceState.getString("TransactionTooLargeOptKey");
        Bundle original = sKey2ContentMap.get(uuid);
        if (original != null) {
            savedInstanceState.clear();
            savedInstanceState.putAll(original);
        }
    }
}
</code>

The map size is limited to 64 entries; when exceeded, the oldest 20% are evicted.

Demo Verification

A demo app saved a 16 MB byte array in

onSaveInstanceState

. With the optimizer enabled, the restored byte array size matched the original, confirming that the large Bundle was successfully compressed and recovered.

Results

The optimization solved 97 % of the observed crashes. Remaining issues are Samsung‑specific startActivity compatibility problems, which are not top priority.

Deployment

Integrate the optimizer by enabling the switch in APMPlus initialization:

<code>MonitorCrash.Config config = MonitorCrash.Config.app(APM_AID)
        .enableOptimizer(true)
        .build();
</code>

Documentation: www.volcengine.com/docs/6431/68852

Conclusion and Recommendations

For system‑level services, increasing the Binder buffer size could further reduce failures. For app developers, avoid passing large data via Bundles or Intents; use external storage or lightweight keys instead. The presented hook‑based approach provides a practical, low‑overhead fix for existing apps.