What the interviewer is testing

The interviewer is checking whether you understand why Android needs delegated execution across process boundaries.

A strong answer explains that another process may own the interaction, that a normal Intent only describes the action, and that a PendingIntent safely grants permission to perform that action using your app's identity.

❌ Common mistake

If they ask you to elaborate

Why Android needed PendingIntent

Imagine your app posts a notification for an order update.

Later, Android kills your process. The user taps the notification from System UI.

Now ask the important question:

Who should be allowed to open your Activity?

System UI cannot be given unrestricted access to launch arbitrary components inside your application. Instead, your app creates a PendingIntent that authorises one predefined action.

Your app defines an action
            │
            ▼
Android keeps permission to perform it
            │
            ▼
Your process may disappear
            │
            ▼
Another process owns the interaction
(System UI, AlarmManager, or the launcher)
            │
            ▼
Android performs the authorised action

That is the core mental model:

The same problem appears throughout Android:

• Notifications – System UI owns the tap.
• AlarmManager – Android owns the timer and may deliver it after your process is gone.
• App widgets – The launcher owns the Home Screen interaction.
• Foreground-service actions – System UI owns the notification buttons.

The owner changes. The solution does not.

From a production perspective, treat a PendingIntent as a security capability. Grant only the action the other process needs. Use an explicit target and make it immutable by default; use mutability only when the receiving system component genuinely needs to add or change data, such as an inline notification reply.

One common bug is several notifications opening the wrong item. Android may reuse an equivalent PendingIntent, so independent actions should have independent identities—for example, a stable request code derived from the item they represent.

Code example

fun createOrderNotification(
    context: Context,
    orderId: Long,
): Notification {
    val openOrderIntent = Intent(
        context,
        OrderDetailsActivity::class.java,
    ).putExtra(EXTRA_ORDER_ID, orderId)

    val openOrder = PendingIntent.getActivity(
        context,
        orderId.hashCode(),
        openOrderIntent,
        PendingIntent.FLAG_UPDATE_CURRENT or
            PendingIntent.FLAG_IMMUTABLE,
    )

    return NotificationCompat.Builder(context, ORDERS_CHANNEL_ID)
        .setSmallIcon(R.drawable.ic_order)
        .setContentTitle(context.getString(R.string.order_updated))
        .setContentIntent(openOrder)
        .setAutoCancel(true)
        .build()
}

System UI never receives direct access to OrderDetailsActivity. It receives permission to launch only this predefined screen. The PendingIntent is immutable because System UI does not need to change the destination, while the request code keeps each order notification independent.

Follow-up questions

What separates a senior answer

Key takeaways

Learn more