Talking across the wall: every way Android apps communicate

Every Android app is a separate Linux user in a separate process, and the platform is built so that two apps cannot see each other's memory or files by accident. Yet a phone is one long conversation between processes: the share sheet, a payment hand-off, a password manager filling a form, a music app driving a car display. All of it goes through a small set of doors in the wall, and every door is built on the same hinge, Binder. This article walks through the wall, the hinge, and each door in turn, with the rules that decide which one to use.

The map

Read this first when short on time. Every branch is a section below.

The wall: one Linux user per app

Android's sandbox is the ordinary Linux permission model applied with unusual discipline: every installed package gets its own user id, its own process and its own private directory, so the kernel, not the framework, is what stops one app from reading another.

At install time PackageManager assigns the app a uid from 10000 upwards (shown as u0_a123 in ps). When the app starts, Zygote forks a fresh process and switches it to that uid before any app code runs, as the app startup article describes. The app's data directory is owned by that uid with mode 0700, and SELinux puts the process in the untrusted_app domain, which spells out the few kernel objects it may touch. Two apps therefore share nothing: not memory, not files, not even the right to signal each other.

flowchart TD
  A["App A, uid 10087<br/>own process and ART heap<br/>/data/data/a, mode 0700"]
  B["App B, uid 10142<br/>own process and ART heap<br/>/data/data/b, mode 0700"]
  K["Kernel: uid checks, SELinux, Binder driver"]
  S["system_server: the broker that decides who may talk"]
  A --> K
  B --> K
  K --> S

The wall is what makes IPC necessary, and it is also what makes it safe: because the kernel tags every Binder transaction with the sender's real uid, a receiving process always knows exactly who is on the other side. That single fact underlies every permission check in the rest of this article.

One app can also be split across several processes with android:process on a component, or run helpers in an isolatedProcess that has no permissions and a uid of its own. Those processes talk to their parent through the very same doors as two unrelated apps, which is why the mechanisms below matter even for an app that never talks to anyone else.

uid

The Linux user id. On Android, one per app, or one per group of apps that share a signing key and a sharedUserId.

SELinux domain

A label on a process that a policy uses to allow or deny each kernel operation. untrusted_app is the label for ordinary apps.

isolatedProcess

A service attribute that runs the service in a process with a throwaway uid and no permissions, reachable only by its own app through bindService.

Binder: the hinge every door swings on

Binder is a kernel driver plus a thin user-space library that lets one process call a method on an object in another process as if it were local, with the caller's identity attached and the bytes copied exactly once.

Linux already had pipes, sockets and shared memory when Android was designed. Binder was chosen because it gives three things those do not give together: a notion of objects with reference counting across processes, a built-in answer to "who is calling me", and a thread pool on the receiving side so that a call feels like a function call rather than a message to be parsed. Everything in the rest of this article, including intents and content providers, is a Binder transaction underneath.

The pieces

• /dev/binder is the driver. Each process opens it once and maps a buffer of about 1 MB into which the driver writes incoming transactions.
• A Parcel is the wire format: a flat byte array of primitives and strings plus a table of "objects" (Binder references and file descriptors) that the driver translates as the Parcel crosses.
• An IBinder is a reference to a remote object. Locally it is a Binder subclass that implements onTransact; remotely it is a BinderProxy holding a handle the driver understands.
• The Stub is the server-side class that unpacks a Parcel and calls the real method; the Proxy is the client-side class that packs one. AIDL generates both, and the framework's own services use hand-written or generated pairs of exactly this shape.
• The ServiceManager is the one object everyone can find: it owns handle 0 and maps names like "activity" or "window" to the Binder objects of system services. App services are never registered there; apps receive an IBinder from ActivityManager through bindService instead.

sequenceDiagram
  autonumber
  participant C as Client thread
  participant D as Binder driver
  participant T as Binder thread
  participant S as Stub (real object)
  C->>C: Proxy writes args into a Parcel
  C->>D: ioctl BINDER_WRITE_READ, transaction
  D->>D: copy the Parcel into the receiver's mapped buffer
  D->>T: wake a thread from the pool, deliver
  T->>S: onTransact(code, data, reply)
  S-->>T: real method runs, reply Parcel written
  T-->>D: BC_REPLY
  D-->>C: reply copied back, client thread wakes

What a transaction guarantees

1. One copy. The driver copies the Parcel from the sender's memory straight into the buffer it mapped in the receiver. There is no intermediate kernel buffer that gets copied again on read.
2. A thread appears on the other side. The receiver never reads a socket. The driver wakes one of the process's Binder threads, named binder:pid_N in a thread dump; an app process allows up to 16 of them. If none is idle and the pool is full, the call waits.
3. Identity travels with the call. The driver records the sender's uid and pid in the transaction. On the receiving thread Binder.getCallingUid() reads it for exactly as long as the transaction is in progress. The sender cannot fake it.
4. Objects keep their identity. If a Parcel carries an IBinder, the driver translates it: a local object becomes a handle in the receiver, and a handle that points back at the receiver's own object turns back into that very object. This is how the same IBinder can be passed around three processes and still be recognised as one object. File descriptors are translated too, by duplicating them into the receiver.
5. Synchronous by default. The caller's thread blocks until the reply. There is no timeout. The only way a synchronous call ends without a reply is a DeadObjectException when the receiver dies.
6. Nested calls come back to the waiting thread. If the server, while handling a call, calls back into the client, the driver delivers that callback to the client thread that is already waiting rather than waking a new one. It is what makes re-entrant patterns work without deadlock, and also what lets a server run code on your thread when you least expect it.

oneway changes the shape: the call returns as soon as the driver has queued it, the reply Parcel does not exist, and calls to the same destination object are delivered in order but never concurrently with each other. The framework uses oneway for the direction where the caller must never wait, for example everything ActivityManager says to an app's ApplicationThread.

Death is a first-class event. IBinder.linkToDeath registers a callback that the driver fires when the process behind a handle disappears; ActivityManager uses it to notice app deaths, and a client of a bound service uses it, through ServiceConnection.onServiceDisconnected, to know when to rebind.

Parcel

The serialisation format of a Binder transaction: primitives, strings and a table of special objects (binders, file descriptors) that the driver rewrites in transit.

Stub and Proxy

The two halves of a remote interface. The stub lives in the server, receives Parcels and calls real code; the proxy lives in the client and turns method calls into Parcels.

oneway

A transaction with no reply. The caller returns immediately; delivery is ordered per destination object and never concurrent for the same object.

ServiceManager

The name service of Binder. System services register under a string name; apps look them up indirectly through Context.getSystemService.

Intents: a message the system delivers for you

An Intent is a description of something to be done, handed to system_server, which finds the component that should do it, starts its process if needed and delivers the message. The sender never holds a reference to the receiver; the broker does everything.

An intent is explicit when it names a ComponentName (package plus class) and implicit when it only describes what it wants with an action, a data URI and type, and categories. PackageManager matches an implicit intent against the <intent-filter> elements every app declared at install time; one match goes straight there, several produce a chooser. Explicit intents skip the matching and go where they are told.

flowchart TD
  I([startActivity]) --> Q{Component set?}
  Q -- Yes --> E["Explicit: deliver to that class"]
  Q -- No --> M["Match action, data, categories<br/>against installed intent filters"]
  M --> N{Matches?}
  N -- None --> X["ActivityNotFoundException"]
  N -- One --> E
  N -- Several --> C["Chooser dialog, or the user's default"]
  C --> E
  E --> P{Process alive?}
  P -- No --> Z["Zygote fork, bindApplication"]
  P -- Yes --> L["Deliver: onCreate or onNewIntent"]
  Z --> L

What an intent can carry

The payload is a Bundle of extras, which is a Parcel with a string key per entry. It is parcelled at send time on the sender's side, travels through ActivityManager, and is unparcelled lazily in the receiver. Three consequences follow:

• The entire transaction, extras plus the intent itself plus any ActivityOptions, must fit the Binder budget. A bitmap in an extra is the classic way to hit TransactionTooLargeException; send a URI or a file descriptor instead.
• A custom Parcelable only unparcels if the receiver has the same class. Across apps that means a shared library, or sticking to framework types.
• Extras are copied, not shared. Mutating an object after putExtra changes nothing on the other side.

Results, links and tokens

Three variations on the theme cover most cross-app flows:

• Getting a result. registerForActivityResult with the StartActivityForResult contract starts another app's activity and gets an Intent back through setResult. The system, not the callee, routes the result, so the callee never learns who asked unless it calls callingPackage.
• Deep links and App Links. An http or https intent filter with android:autoVerify="true" becomes an App Link once the domain publishes a Digital Asset Links file naming the app's signing certificate. Since Android 12 an unverified web link opens in the browser by default instead of offering the app.
• PendingIntent. A token created by ActivityManager that wraps an intent together with the creator's identity. Whoever holds it can send() it later, and the system performs the action as the creator. Notifications, widgets, alarms and geofences all work this way: SystemUI or AlarmManager fires the token, your app receives the intent.

// Explicit: I know exactly who should handle this
val open = Intent(Intent.ACTION_VIEW, uri).setPackage("com.android.chrome")

// Implicit: anyone who can share text, let the user pick
val share = Intent(Intent.ACTION_SEND).apply {
    type = "text/plain"
    putExtra(Intent.EXTRA_TEXT, "https://example.org/post/42")
}
startActivity(Intent.createChooser(share, null))

// A token another process can fire later, acting as this app
val pi = PendingIntent.getActivity(
    context, 0, Intent(context, DetailActivity::class.java).putExtra("id", 42),
    PendingIntent.FLAG_IMMUTABLE or PendingIntent.FLAG_UPDATE_CURRENT
)

The rules that changed under everyone

Intent filter

A manifest declaration of the actions, data schemes or types, and categories a component accepts. It is what makes a component a target for implicit intents.

PendingIntent

A system-held token that lets another process perform an intent with the creator's identity and permissions at a later time.

Package visibility

The Android 11 rule that an app sees only the packages it declares in <queries>, plus those that interact with it, unless it holds QUERY_ALL_PACKAGES.

Broadcasts: one message, many listeners

A broadcast is an intent sent to every receiver that matches it rather than to one component, delivered by ActivityManager's broadcast queue with no reply. It is how the system announces events and how apps publish them to whoever cares.

There are two kinds of receiver. A manifest-declared receiver exists even when the app is not running: the system starts the process to deliver to it. A context-registered receiver, created with registerReceiver, lives only while the registering component does. Delivery is normal (all receivers, unordered, in parallel) or ordered (one at a time by android:priority, each able to modify the result or abort the chain). Sticky broadcasts, which stayed around for late listeners, are deprecated; ACTION_BATTERY_CHANGED is the last well-known survivor, and registerReceiver(null, filter) still returns its latest value.

sequenceDiagram
  autonumber
  participant A as Sender app
  participant Q as BroadcastQueue
  participant R1 as Receiver (running)
  participant R2 as Receiver (manifest)
  A->>Q: sendBroadcast(intent) or sendOrderedBroadcast
  Q->>Q: match filters, apply permissions and background rules
  Q-)R1: onReceive on the main thread
  Q->>R2: start the process, then onReceive
  R2-->>Q: finished (or goAsync, then finish)
  Note over Q,R2: 10 s for a foreground broadcast, 60 s in the background, then ANR

The rules that tamed broadcasts

Broadcasts used to wake half the phone whenever the network changed, so the platform closed the door in stages:

• Android 8: manifest receivers no longer receive implicit broadcasts, with a short exempt list (BOOT_COMPLETED, LOCKED_BOOT_COMPLETED, LOCALE_CHANGED, TIMEZONE_CHANGED, MY_PACKAGE_REPLACED, SMS_RECEIVED and a handful more). An explicit broadcast, one with setPackage or setComponent, is still delivered, and so is anything to a context-registered receiver.
• Android 3.1 onwards: an app in the stopped state that a force stop leaves behind receives nothing until the user opens it.
• Android 12 onwards: the broadcast queue defers deliveries to cached processes until they leave the cached state, so a burst of broadcasts no longer wakes every idle app at once.
• Android 14: registerReceiver must pass RECEIVER_EXPORTED or RECEIVER_NOT_EXPORTED, except for system-only broadcasts.

Permissions work in both directions. The sender can pass a permission name, and only receivers holding it get the message; the receiver can declare android:permission on its manifest entry or pass it to registerReceiver, and only senders holding it get through. System broadcasts are additionally protected: an app that tries to send ACTION_BOOT_COMPLETED gets a SecurityException.

// Publish to one specific app: explicit, still delivered to its manifest receiver
sendBroadcast(Intent("org.example.SYNC_DONE").setPackage("org.example.companion"))

// Listen while this Activity is alive, and only to senders inside my own app
registerReceiver(receiver, IntentFilter("org.example.SYNC_DONE"),
    Context.RECEIVER_NOT_EXPORTED)

class SyncDoneReceiver : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        // Main thread. Do not block; hand real work to WorkManager.
        val pending = goAsync()            // buys time, but not past the ANR limit
        ioScope.launch {
            markSynced(intent.getStringExtra("id"))
            pending.finish()
        }
    }
}

Ordered broadcast

Delivered to one receiver at a time in priority order; each may change the result data or call abortBroadcast() to stop the chain.

Protected broadcast

A system action declared with <protected-broadcast> that only the system may send.

goAsync

Tells the system the receiver is still working after onReceive returns, keeping the process alive until finish() or the broadcast timeout.

Content providers: a table with a URL

A content provider exposes structured data or files behind a content:// URI with a fixed verb set, so that any app with permission can query it through ContentResolver without knowing which process, database or file layout stands behind it.

The URI is content://authority/path/id. The authority names the provider, the path picks a table or a file, and the verbs are query, insert, update, delete, openFile and a free-form call(method, arg, extras) for anything that does not fit a table. query returns a Cursor; openFile returns a ParcelFileDescriptor. Clients can also watch a URI with a ContentObserver and the provider pokes them with notifyChange.

Under the hood

sequenceDiagram
  autonumber
  participant A as Client app
  participant AM as ActivityManager
  participant P as Provider process
  A->>AM: get the provider for this authority
  AM->>P: start the process if needed, publish the provider
  AM-->>A: IContentProvider binder, cached in the client
  A->>P: query(uri, projection, ...) directly over Binder
  P-->>A: Cursor backed by a shared-memory CursorWindow
  A->>P: openFile(uri) directly over Binder
  P-->>A: ParcelFileDescriptor, dup'd into the client

1. The first call for an authority asks ActivityManager for it. If the provider's process is not running, the system starts it, and the provider's onCreate runs before the app's own Application.onCreate, which the startup article covers.
2. The client receives an IContentProvider binder and caches it. Later calls skip system_server entirely.
3. A query result does not travel in the Parcel. The provider fills a CursorWindow, a shared-memory block of 2 MB by default, and sends its descriptor. The client's Cursor reads rows out of it; when it moves past the window, the next window is fetched. Big result sets cross the wall without ever meeting the 1 MB limit; a single row bigger than the window fails with SQLiteBlobTooBigException.
4. Files cross as descriptors. The provider opens the file with its own permissions and the driver duplicates the descriptor into the client, which now reads a file it could never have opened by path.

There is one sharp edge. ContentResolver makes the first call through an unstable reference so that a crashing provider surfaces as an exception, but the Cursor it hands back holds a stable reference to the provider for as long as it is open. A stable reference means "my correctness depends on that process", and if the provider dies while the cursor is open, ActivityManager kills the client too. It is the reason a contacts-provider crash can take an unrelated app down, and it is why cursors should be read and closed promptly.

Sharing files the right way

A FileProvider is a stock ContentProvider configured in XML that maps directories in your private storage to content URIs. To hand a file to another app you attach the URI to an intent with FLAG_GRANT_READ_URI_PERMISSION; the system records a temporary grant for the receiving component, valid until its task finishes. Context.grantUriPermission makes an explicit, longer-lived grant; the Storage Access Framework's FLAG_GRANT_PERSISTABLE_URI_PERMISSION plus takePersistableUriPermission makes one that survives reboot.

// Manifest: a FileProvider over app-private files, never exported, grants per intent
// <provider android:name="androidx.core.content.FileProvider"
//     android:authorities="${applicationId}.files"
//     android:exported="false" android:grantUriPermissions="true">
//   <meta-data android:name="android.support.FILE_PROVIDER_PATHS" android:resource="@xml/paths"/>
// </provider>

val uri = FileProvider.getUriForFile(context, "${context.packageName}.files", pdf)
val view = Intent(Intent.ACTION_VIEW)
    .setDataAndType(uri, "application/pdf")
    .addFlags(Intent.FLAG_GRANT_READ_URI_PERMISSION)
startActivity(view)

// Reading someone else's provider
context.contentResolver.query(
    ContactsContract.Contacts.CONTENT_URI,
    arrayOf(ContactsContract.Contacts.DISPLAY_NAME), null, null, null
)?.use { c -> while (c.moveToNext()) names += c.getString(0) }

Access is controlled by android:exported (false by default for apps targeting API 17 and later), by readPermission and writePermission, and by <path-permission> elements for finer cuts. URI grants punch precise, temporary holes through all of those.

Authority

The host part of a content:// URI, declared in the manifest, that identifies one provider on the device.

CursorWindow

A shared-memory buffer that carries query rows between processes; 2 MB by default, paged as the cursor moves.

URI grant

A temporary, per-URI permission the system records when an intent carries FLAG_GRANT_*_URI_PERMISSION or grantUriPermission is called.

Stable reference

A provider connection whose holder is killed if the provider dies; an open Cursor holds one.

Bound services: calling a method in another process

A bound service hands a client an IBinder through onBind, and from then on the client calls methods on it as a remote object. It is the door to use when two processes need a conversation rather than a message: request and reply, callbacks, a session that lasts.

The client calls bindService(intent, connection, flags). ActivityManager starts the service's process if needed, calls onBind there, and delivers the resulting binder to the client's ServiceConnection.onServiceConnected on the client's main thread. The service stays alive while anyone is bound to it and is destroyed after the last unbindService, unless it was also started. Binding also lends the client's importance to the service's process: while a foreground app is bound, the service process is treated almost as a foreground process by the memory killer, which is why an SDK's service is rarely killed while its host is on screen.

sequenceDiagram
  autonumber
  participant C as Client
  participant AM as ActivityManager
  participant S as Service process
  C->>AM: bindService(explicit intent, connection, BIND_AUTO_CREATE)
  AM->>S: start process if needed, onCreate, onBind(intent)
  S-->>AM: IBinder
  AM-)C: onServiceConnected(name, binder), main thread
  C->>S: Stub.asInterface(binder).method(args) directly
  S-->>C: reply, or DeadObjectException if the service died
  C->>AM: unbindService(connection)
  AM->>S: onUnbind, onDestroy when nobody is bound

Three ways to build the binder

Messenger is worth knowing because it is AIDL in disguise: it wraps a Handler behind the framework's own IMessenger interface, and its serial delivery is often exactly what a small service wants. Its Message.obj field only crosses processes if it holds a framework Parcelable; anything custom goes into the data bundle with the class loader set on the receiving side.

AIDL in practice

An .aidl file declares the interface. The build generates a Java IFoo with a nested Stub (a Binder you subclass in the service) and a Proxy (what the client gets from Stub.asInterface). Kotlin uses it directly.

// IRemoteCounter.aidl
package org.example.counter;
import org.example.counter.Snapshot;      // declared elsewhere as: parcelable Snapshot;
import org.example.counter.ICounterListener;

interface IRemoteCounter {
    int increment(int by);                 // synchronous, returns a value
    Snapshot snapshot();                   // a Parcelable crossing the wall
    void fill(inout List<String> names); // inout: sent, modified, sent back
    oneway void log(String line);          // fire and forget, ordered
    void register(ICounterListener l);     // a binder going the other way
}

// Service side: methods run on Binder threads, so guard the state
class CounterService : Service() {
    private val count = AtomicInteger()
    private val listeners = RemoteCallbackList<ICounterListener>()

    private val binder = object : IRemoteCounter.Stub() {
        override fun increment(by: Int): Int {
            enforceCallingPermission("org.example.counter.USE", "counter")
            return count.addAndGet(by)
        }
        override fun snapshot() = Snapshot(count.get(), System.currentTimeMillis())
        override fun fill(names: MutableList<String>) { names += "counter" }
        override fun log(line: String) = Log.d("Counter", "${Binder.getCallingUid()}: $line")
        override fun register(l: ICounterListener) { listeners.register(l) }  // linkToDeath inside
    }
    override fun onBind(intent: Intent): IBinder = binder   // called by the system, not the client
}

// Client side
val conn = object : ServiceConnection {
    override fun onServiceConnected(name: ComponentName, service: IBinder) {
        counter = IRemoteCounter.Stub.asInterface(service)   // Proxy, or the real object in-process
    }
    override fun onServiceDisconnected(name: ComponentName) { counter = null }  // it died; rebind
}
bindService(Intent().setClassName("org.example.counter", "org.example.counter.CounterService"),
    conn, Context.BIND_AUTO_CREATE)

Rules worth memorising, because each one is a bug in the field:

• Direction markers. Primitives and String are always in. Anything else declares in, out or inout, and every direction is a copy; inout copies twice.
• Transaction codes come from method order. Each method gets FIRST_CALL_TRANSACTION + index. Adding a method at the end keeps old clients working; reordering or removing breaks them silently, with the wrong method executing.
• asInterface short-circuits. If the binder is a local object in the same process it returns that object, so in-process "IPC" costs nothing and runs on the caller's thread.
• Only a short list of exceptions crosses. SecurityException, IllegalArgumentException, IllegalStateException, NullPointerException, UnsupportedOperationException and ServiceSpecificException are re-raised in the client. Any other exception thrown in a stub method crashes the service process, and the client sees a DeadObjectException.
• Callbacks are binders too. Registering a listener sends the client's own Binder to the service; RemoteCallbackList keeps them, links to death, and drops the ones whose process is gone.
• The intent must be explicit (since Android 5) and, since Android 11, the target package must be visible through <queries>.

AIDL

Android Interface Definition Language. A small declaration language from which the build generates the stub and proxy classes for a Binder interface.

ServiceConnection

The client-side callbacks for a binding: onServiceConnected with the binder, onServiceDisconnected when the service's process dies.

RemoteCallbackList

A framework helper that stores remote listener binders, registers death recipients for them and lets the service broadcast to the live ones.

Shared memory and file descriptors: moving big data

When the payload is a bitmap, a video frame or a database page, the data does not go through Binder at all: the sender puts it in memory or a file both sides can map, and Binder carries only the file descriptor that names it.

The trick rests on one driver feature from the Binder section: a file descriptor in a Parcel is duplicated into the receiving process. The receiver ends up with its own descriptor for the same open file, pipe, socket or memory region, exactly as if it had been forked with it. Everything else is a choice of what the descriptor refers to.

flowchart LR
  subgraph P["Producer process"]
    W["write pixels into<br/>the mapped region"]
  end
  subgraph K["Kernel"]
    M["one memfd or ashmem region<br/>(physical pages)"]
  end
  subgraph C["Consumer process"]
    R["map the dup'd fd,<br/>read the same pages"]
  end
  W --> M --> R
  P -. "Binder carries only the fd" .-> C

// Producer: allocate, fill, then make read-only before handing it out
val region = SharedMemory.create("frame", 4 * 1024 * 1024)
region.mapReadWrite().use { buf -> buf.put(pixels) }   // ByteBuffer over the pages
region.setProtect(OsConstants.PROT_READ)                  // consumers cannot write back
remote.publish(region)                                    // SharedMemory is Parcelable: the fd crosses

// Consumer: map the same pages, no copy involved
override fun publish(region: SharedMemory) {
    val view = region.mapReadOnly()
    decode(view)
    SharedMemory.unmap(view)
}

setProtect is the detail that makes shared memory safe to hand to an untrusted party: once the region is sealed read-only the consumer cannot modify pages the producer is still using, and the kernel enforces it. Sizing is the other detail: memory in a shared region is charged to whoever maps it, so a producer that shares a region with ten consumers has made ten processes look bigger to the memory killer.

ashmem and memfd

Two kernel mechanisms for anonymous shared memory referenced by a file descriptor. ashmem is Android's original driver; memfd_create is the upstream Linux replacement that newer Android releases use behind the same APIs.

dma-buf

The Linux framework for sharing device memory between drivers and processes by descriptor; the backing of HardwareBuffer.

BufferQueue

A producer-consumer queue of graphics buffers; a Surface is its producer handle.

Sockets: the door the platform itself uses

Ordinary Linux sockets work on Android, and the platform uses Unix domain sockets wherever it wants a byte stream with kernel-verified peer identity rather than a method call.

LocalSocket and LocalServerSocket wrap Unix domain sockets. The name lives in one of three namespaces: abstract (a name in the kernel, no file, the default), filesystem (a path, protected by directory permissions) or reserved (under /dev/socket, created by init for daemons). getPeerCredentials() returns the uid, gid and pid of the other end, so a server can apply the same "who is calling" logic as a Binder service. Descriptors can be sent over them too, with SCM_RIGHTS, the same trick Binder performs for a Parcel. The Linux sockets and IPC article covers the API itself.

Plain TCP on the loopback interface also works. Any app with INTERNET permission can connect to 127.0.0.1:port, and the kernel does not tell the server who connected, so a local HTTP server that trusts its callers is trusting every app on the phone. Authenticate with a token exchanged through a safer door, or use a Unix socket and read the peer uid.

flowchart TD
  Z["Zygote<br/>/dev/socket/zygote"] -->|"fork request"| AP["new app process"]
  WM["WindowManager"] -->|"socketpair: InputChannel"| AP
  D["adbd"] -->|"abstract: jdwp, devtools"| AP
  AP -->|"TCP 127.0.0.1"| L["another app's local server"]

The smaller doors: RemoteViews, storage and system-brokered data

A few mechanisms move data between apps without looking like IPC at all, and it helps to see that each is one of the doors above wearing a different coat.

• RemoteViews. A notification's custom layout or an app widget is not drawn by your app. You build a RemoteViews, a Parcelable recipe of a layout resource and a list of setter calls, and SystemUI or the launcher inflates it in their process, resolving your resources through PackageManager. Only the whitelisted view classes and setters work, which is why widgets feel limited. Jetpack Glance compiles a Compose-like tree down to exactly this.
• Shared storage. Since scoped storage (Android 10 and 11) the shared parts of external storage are reached through MediaStore for media and the Storage Access Framework for documents, both content providers. Two apps that write and read the same file are doing provider IPC with a file descriptor at the end.
• sharedUserId. Apps signed with the same key could declare the same shared user id and literally become one uid with one data directory. It is deprecated since API 29 because it can never be undone for installed users; signature permissions and providers do the same job without fusing identities.
• Clipboard. ClipboardManager is a system service holding a ClipData; since Android 10 only the foreground app and the current keyboard can read it, and since Android 12 the system shows a toast when an app reads it.
• System-brokered services. Autofill, Accessibility, notification listeners and input methods all receive other apps' content, but only through system_server, only after the user enabled them in Settings, and only as the platform's own AIDL interfaces describe.

Guarding the doors: knowing who is on the other side

Every door above is only as safe as the check on the receiving side, and every check comes down to the same two questions: which uid sent this, and does that uid hold the right permission or the right signature?

Answering "who is calling"

1. Inside a Binder call, Binder.getCallingUid() gives the sender's uid; it is set by the driver and cannot be forged. getCallingPid() is available too but a pid is recyclable and a uid is not.
2. packageManager.getPackagesForUid(uid) turns it into package names. A uid maps to one package unless the apps share a user id.
3. PackageManager.hasSigningCertificate, given the package and the expected SHA-256, confirms the package is signed by the key you expect, because a package name proves nothing by itself: anyone can publish com.android.vending on a sideloading site.
4. For a permission check, checkCallingPermission and enforceCallingPermission do steps 1 and the lookup in one call. Use the calling variants; checkSelfPermission asks about your own process and always says yes.
5. If your service needs to call onwards with its own identity rather than the caller's, wrap the call in Binder.clearCallingIdentity() and restoreCallingIdentity(token), and be aware you have just made a decision on the caller's behalf.

Activities have weaker tools. callingPackage is set only when the caller used startActivityForResult, referrer is a hint the caller controls, and getLaunchedFromUid() arrived only in Android 14. An exported activity should therefore treat every extra as untrusted rather than trying to identify the sender.

Declaring what is allowed

The traps with names

• Custom permission squatting. The first installed app to define a permission name owns its definition. Android 5 made installation fail when a second app with a different signature redefines it, but a permission that an older app defined as normal stays normal. Prefix names with your package and declare them in every app that uses them.
• Implicit PendingIntent hijack. A mutable PendingIntent built on an implicit intent can be filled in by whoever receives it and then fired with your identity; the classic outcome is another app starting your non-exported activity or reading your files through a URI grant. Always name the component, and use FLAG_IMMUTABLE unless a system feature demands otherwise.
• Intent redirection. Pulling an Intent out of an extra and passing it to startActivity or setResult lets the caller reach components only you can reach. Check the component's package first, or strip the intent to what you expect. StrictMode.detectUnsafeIntentLaunch(), from Android 12, flags exactly this in debug builds.
• Trusting a package name. Verify the signing certificate of any app you bind to or accept calls from, as the Play Billing library does with the Play Store.
• World-readable files. MODE_WORLD_READABLE is gone since API 24 and file:// URIs throw since Android 7. Every shared file goes through a provider grant now, and that is the design, not a limitation.

Signature permission

A permission that is granted automatically to apps signed with the same key as the app that defined it, and to no one else.

Digital Asset Links

A file at /.well-known/assetlinks.json where a domain lists the Android apps (by package and certificate hash) it trusts.

Intent redirection

Forwarding an intent received from an untrusted caller so that it runs with the forwarding app's identity and reach.

Choosing the door

The choice is usually decided by two questions: does the caller need a reply, and how big is the payload?

flowchart TD
  S([Two processes need to talk]) --> U{User-visible?}
  U -- Yes --> I["Intent to an activity,<br/>result if needed"]
  U -- No --> R{Need a reply?}
  R -- No --> B["Broadcast, or a oneway AIDL call"]
  R -- Yes --> D{Data or API?}
  D -- Rows or files --> P["Content provider"]
  D -- Methods --> A["Bound service with AIDL"]
  P --> X{Bulk bytes?}
  A --> X
  X -- Yes --> M["add a fd or SharedMemory"]
  X -- No --> N["Parcel is fine"]

Watching it happen

All of this is visible from a shell, which turns "I think the broadcast was delivered" into a fact.

# Who is bound to what, with connection flags and client pids
adb shell dumpsys activity services org.example.counter

# Pending and historical broadcasts, per queue, with receivers and timings
adb shell dumpsys activity broadcasts

# Published providers and which clients hold references to them
adb shell dumpsys activity providers

# Every registered system service name (the ServiceManager table)
adb shell service list

# Drive the doors by hand
adb shell am start -a android.intent.action.VIEW -d "geo:0,0?q=coffee"
adb shell am broadcast -a org.example.SYNC_DONE -n org.example.companion/.SyncDoneReceiver
adb shell content query --uri content://org.example.files/documents --projection _id:name
adb shell cmd package query-activities --brief -a android.intent.action.SEND -t text/plain

# Binder traffic: per-process transaction stats collected by system_server
adb shell dumpsys binder_calls_stats

For timing, Perfetto with the binder tracks enabled draws every transaction as a slice on the calling thread ("binder transaction") with a matching "binder reply" slice on the server thread, so a slow bindService or a chatty SDK is visible as a wall of tiny bars. On a rooted device or emulator, /dev/binderfs/binder_logs/transactions lists every in-flight transaction with its buffer size, which is the fastest way to find out who is eating the 1 MB budget.

Mistakes that keep coming back

• A bitmap or a big list in an intent extra or saved state. The 1 MB budget is shared and TransactionTooLargeException appears only under load. Send a URI or a descriptor.
• An implicit intent for a service, or an implicit broadcast to a manifest receiver, that "used to work". Both have been closed for years; make it explicit with setPackage or setClassName.
• Checking the caller in onBind. The system calls onBind. Check inside the methods.
• Touching UI from an AIDL stub method or a Messenger handler on a background thread. Stubs run on Binder threads; post to the main thread or use a main-thread Handler.
• A synchronous remote call on the main thread that blocks while the other process starts. Bind early, call from a background dispatcher, or use oneway plus a callback.
• Reordering AIDL methods in a new release. Old clients now call the wrong method; append only.
• Building a PendingIntent on an implicit intent, or forwarding a nested intent from an extra. Both hand your identity to a stranger.
• Trusting a package name without checking its certificate.
• Holding a Cursor open across a screen's lifetime. If the provider dies, your process goes with it.
• A local TCP server with no authentication. Every app with INTERNET is a client.

Recap