Parcel and Parcelable in Android IPC
Parcel and Parcelable in Android IPC
Android's inter process communication (IPC) relies on the Parcel class as its low level transport container and the Parcelable interface as the contract that objects implement to serialize themselves into a Parcel. Understanding how Parcel manages memory, how it marshals and unmarshals data, and why it is restricted to transient IPC rather than persistent storage is necessary for working with any Android component that crosses process boundaries. By the end of this lesson, you will be able to:
- Describe what a Parcel is and how it functions as a container for IPC data.
- Explain the marshaling and unmarshaling process for Parcelable objects.
- Identify why Parcel should not be used for persistent storage.
- Distinguish between the typed read/write methods and generic object handling.
- Apply best practices for implementing Parcelable in production code.
The Parcel Container
A Parcel is a mutable container of data that can be sent through Android's Binder IPC mechanism. Internally, it wraps a C++ Parcel object that manages a contiguous block of memory. Data is written sequentially and read back in the same order. The Parcel maintains a position cursor that advances with each read or write operation.
The native backing memory is not a Java byte array. It is allocated and managed by the Binder driver kernel module, which enables zero copy transfers between processes when possible. When you call Parcel.writeInt(42), the value is written directly into this native buffer at the current position, and the position advances by 4 bytes. There is no boxing, no intermediate buffer, and no serialization framework involved.
Parcels also support writing IBinder references, which allow one process to hold a handle to a live object in another process. This is how Android services expose their APIs across process boundaries. The Binder driver translates these references into kernel level handles that survive the IPC transfer.
The Parcel class also provides dataSize() to check the current byte size of the written data and dataCapacity() to check the allocated buffer capacity. When the written data exceeds the current capacity, the Parcel automatically grows its internal buffer. This reallocation is handled in native code and is generally fast, but frequent growth in a tight loop can fragment memory. Pre allocating capacity with setDataCapacity() avoids repeated resizing when you know the approximate size of the data you will write.
Writing Data to a Parcel
The Parcel API provides typed methods for every primitive type and several common compound types:
val parcel = Parcel.obtain()
parcel.writeInt(42)
parcel.writeString("hello")
parcel.writeLong(System.currentTimeMillis())
parcel.writeFloat(3.14f)
parcel.writeTypedList(listOf(user1, user2))
Each method writes the data in a format that the corresponding read method expects. The order and types must match exactly between writer and reader. Writing an Int and reading a String at the same position produces garbage data or crashes because the Parcel does not store type information alongside the values. This is a deliberate tradeoff: omitting type metadata reduces the payload size and improves transfer speed.
The Parcel also provides methods for writing arrays and lists. writeStringList() writes a list of strings with a length prefix followed by each string element. writeTypedList() writes a list of Parcelable objects by calling writeToParcel() on each element sequentially. On the reading side, createStringArrayList() and createTypedArrayList() allocate a new list and populate it from the Parcel data. These list methods handle null lists by writing a sentinel value of -1 for the length, which the read methods detect and return as null.
For Parcelable objects, writeParcelable() writes the class name followed by the object's data (produced by writeToParcel()). The class name allows the reader to instantiate the correct type via reflection. The optimized alternative, writeTypedObject(), skips the class name entirely and requires the reader to know the type in advance:
This interview continues for subscribers
Subscribe to Dove Letter for full access to exclusive interviews about Android and Kotlin development.
Become a Sponsor