Want to keep learning?

This content is taken from the University of Southampton's online course, Secure Android App Development. Join the course to learn more.

Asynchronous IPC in Android

In Android asynchronous IPC is performed using Intents. An Intent is a type of object that can be sent from one component to another.

There are several different ways in which an Intent can be used:

  1. Explicit Intent: here the sender sends the Intent to an explicitly named recipient. Only one component receives the Intent, and it is the one explicitly named by the sender.

  2. Implicit Intent: here the sender does not explicitly name the recipient, but instead states the action they would like to be performed, e.g. send an email, or display an image. The system (possibly with the help of the user) selects an appropriate recipient that can perform the requested action and delivers the Intent to it. Only one component receives the Intent, and it is the one chosen by the system (possibly with the help of the user).

  3. Broadcast Intent: a broadcast Intent is similar to an implicit Intent, but is delivered to all Broadcast Receiver components that have declared that they can perform the requested action. Here action could mean ‘receive notification of event X’, so broadcast Intents can be used to signal events like ‘new SMS received’ to all apps that might be interested in that event. Only Broadcast Receivers receive broadcast Intents.

  4. Ordered Broadcast Intent: an ordered broadcast Intent is a special case of a broadcast Intent where the system controls the order in which the Intent is delivered to the receivers, and moreover, a receiver can ‘consume’ the broadcast by aborting the broadcast to the remaining receivers. The developer of an app can specify the priority of a Broadcast Receiver, and the system will use this to determine the order in which an ordered broadcast Intent is delivered.

Implicit and broadcast Intents

With implicit Intents and broadcast Intents the system must determine which components to deliver the Intent to. It does this by matching the requested action in the Intent to a list of components that can perform that action.

This list is assembled from information contained in the AndroidManifest.xml files of the different apps installed on the device. Each app must therefore specify in its AndroidManifest.xml file which actions its components can perform. This is done using Intent Filters.

An Intent Filter is declared by adding an <intent-filter> element to a component’s entry in AndroidManifest.xml. The component uses the <intent-filter> to specify which actions it can perform.

Activities, Services, and Broadcast Receivers can have Intent Filters.

Important: an Intent Filter is not a security mechanism. Explicit intents bypass the recipient’s Intent Filter, and as a result the recipient must perform input validation on any data contained in any received Intent, and/or use permissions to restrict who can send to it.

Private components

It is generally considered bad practice to set an Intent Filter for a private component.

Private components can only be accessed by other components in the same app, and typically when an app accesses one of its own components, the intention was to invoke that component, and only that component. An explicit Intent should therefore be used.

Invoking a private component using an implicit Intent opens the possibility that a component in a completely different app is selected. This is almost always not what was intended, and as a result could be dangerous.

If private components are always accessed via explicit Intents, then they have no need for Intent Filters.

Share this article:

This article is from the free online course:

Secure Android App Development

University of Southampton