Performance & Crash Debugging

TransactionTooLargeException: Reduce Binder Payloads, Not Heap Usage

TransactionTooLargeException usually points to an oversized Binder transaction, such as a large saved-state bundle or intent payload. Increasing the app's heap limit does not fix the transport boundary that failed.

By , FounderUpdated 3 min read

Locate the transferred data

Read the exception reference and identify the call that crosses a process or framework boundary. The documented Binder transaction buffer is shared by transactions in progress, so treating its nominal size as a safe per-request payload budget is a mistake.

Inspect saved instance state, navigation arguments, intent extras and service calls. Large bitmaps, long lists and serialized screen models are common suspects.

Pass identity instead of the entire object

Prefer a stable record ID or a controlled content URI, then load the necessary data at the destination. Persist data that must survive process death rather than placing an entire repository snapshot into a Bundle.

Payload Better design question
Full-resolution image Can the receiver read a granted URI?
Thousands of rows Can it load by query or page?
Complete screen model Which minimal state reconstructs the screen?
Large nested JSON Can it live in controlled storage?

URI permissions and storage access still need correct handling.

Test lifecycle transitions

Reproduce rotation, background/foreground transitions and process recreation with realistic data. A screen may work during ordinary navigation but fail when the framework saves its state.

Do not merely remove all state saving: that can turn a crash into lost user work. Keep the small state required to restore the experience and move bulk data elsewhere.

Reduce the transaction, then verify behavior

Measure or inspect the serialized payload where practical. Test the largest supported input and concurrent operations. Catching the exception at a high level without correcting the data flow leaves the same boundary vulnerable.

Use the crash trace to guide the fix

APKLint's Crash / ANR Analyzer can help interpret a redacted stack trace. It cannot inspect your runtime Bundle or determine a universally safe byte count. The fix record should identify the oversized data, its new storage/transfer path and the lifecycle cases that now work.

Persist the draft and save a small reference

Imagine a document editor that places the entire draft, attachment previews and undo history into saved instance state. A short draft works, but a long editing session fails when the activity stops. Replace the bulk payload with an appropriately persisted draft and a compact identifier plus essential UI position. Restoration can then load the draft through the application's data layer instead of moving all content through one state Bundle.

Use Android's UI-state guidance to choose between retained in-memory state, small saved state and persistent storage. An in-memory singleton alone does not restore data after process death. Conversely, disabling state saving merely to avoid the exception discards recovery behavior rather than solving the data-transfer design.

Treat the Binder limit as a shared constraint

The exception reference documents a Binder transaction buffer shared by concurrent transactions in a process. Its stated size is not a safe maximum for each individual request. Arguments, responses and simultaneous work all matter, so a payload that happened to succeed once is not a dependable production threshold.

For an interprocess file operation, consider transferring an appropriate content URI or descriptor under the platform's access contract instead of embedding a bitmap or large byte array. Keep the recipient's read permission and the resource lifetime explicit. A URI to a deleted temporary file avoids a large parcel but still leaves a broken workflow.

Test the editor with a long draft, multiple attachments, backgrounding, rotation and process recreation. Confirm that the restored text and cursor refer to the correct persisted draft, and that a failed save is surfaced before a success message. For remote service calls, account for partial failure: the exception does not by itself prove whether the remote operation ran. Use an operation identifier or other suitable duplicate-handling design before retrying a state-changing request. Keep parcel contents small by design and record measured payload categories during testing without logging private drafts. Increasing the Java heap is unrelated to repairing this shared transaction-buffer boundary, so validation must exercise the actual interprocess or saved-state path.

Sources and further reading

  1. Android Developers: TransactionTooLargeException

Reference review: 29 September 2026. Examples illustrate the workflow; check your installed versions, release artifact and account-specific Console requirements before applying them. This guide is not a claim that APKLint executed your project or verified your private account.

APKLint

Android inspection tools and practical release guides. About APKLint · Report a correction