Intent Resolution

Intents can be divided into two groups:

• Explicit intents designate the target component by its name (the component name field, mentioned earlier, has a value set). Since component names would generally not be known to developers of other applications, explicit intents are typically used for application-internal messages — such as an activity starting a subordinate service or launching a sister activity.

• Implicit intents do not name a target (the field for the component name is blank). Implicit intents are often used to activate components in other applications.

Android delivers an explicit intent to an instance of the designated target class. Nothing in the Intent object other than the component name matters for determining which component should get the intent.

A different strategy is needed for implicit intents. In the absence of a designated target, the Android system must find the best component (or components) to handle the intent — a single activity or service to perform the requested action or the set of broadcast receivers to respond to the broadcast announcement. It does so by comparing the contents of the Intent object to intent filters, structures associated with components that can potentially receive intents. Filters advertise the capabilities of a component and delimit the intents it can handle. They open the component to the possibility of receiving implicit intents of the advertised type. If a component does not have any intent filters, it can receive only explicit intents. A component with filters can receive both explicit and implicit intents.

Only three aspects of an Intent object are consulted when the object is tested against an intent filter: action data (both URI and data type) category

The extras and flags play no part in resolving which component receives an intent. Intent filters

To inform the system which implicit intents they can handle, activities, services, and broadcast receivers can have one or more intent filters. Each filter describes a capability of the component, a set of intents that the component is willing to receive. It, in effect, filters in intents of a desired type, while filtering out unwanted intents — but only unwanted implicit intents (those that don't name a target class). An explicit intent is always delivered to its target, no matter what it contains; the filter is not consulted. But an implicit intent is delivered to a component only if it can pass through one of the component's filters.

A component has separate filters for each job it can do, each face it can present to the user. For example, the NoteEditor activity of the sample Note Pad application has two filters — one for starting up with a specific note that the user can view or edit, and another for starting with a new, blank note that the user can fill in and save. (All of Note Pad's filters are described in the Note Pad Example section, later.)

Filters and security

An intent filter cannot be relied on for security. While it opens a component to receiving only certain kinds of implicit intents, it does nothing to prevent explicit intents from targeting the component. Even though a filter restricts the intents a component will be asked to handle to certain actions and data sources, someone could always put together an explicit intent with a different action and data source, and name the component as the target.

An intent filter is an instance of the IntentFilter class. However, since the Android system must know about the capabilities of a component before it can launch that component, intent filters are generally not set up in Java code, but in the application's manifest file (AndroidManifest.xml) as <intent-filter> elements. (The one exception would be filters for broadcast receivers that are registered dynamically by calling Context.registerReceiver() ; they are directly created as IntentFilter objects.)

A filter has fields that parallel the action, data, and category fields of an Intent object. An implicit intent is tested against the filter in all three areas. To be delivered to the component that owns the filter, it must pass all three tests. If it fails even one of them, the Android system won't deliver it to the component — at least not on the basis of that filter. However, since a component can have multiple intent filters, an intent that does not pass through one of a component's filters might make it through on another. Each of the three tests is described in detail below:

Action test

An <intent-filter> element in the manifest file lists actions as <action> subelements. For example:

<intent-filter . .

>

<action android:

name=

"com

example

project

SHOW

CURRENT"

/>

<action android:

name=

"com

example

project

SHOW

RECENT"

/>

<action android:

name=

"com

example

project

SHOW

PENDING"

/>

</intent-filter>

As the example shows, while an Intent object names just a single action, a filter may list more than one. The list cannot be empty; a filter must contain at least one <action> element, or it will block all intents.

To pass this test, the action specified in the Intent object must match one of the actions listed in the filter. If the object or the filter does not specify an action, the results are as follows:

• If the filter fails to list any actions, there is nothing for an intent to match, so all intents fail the test. No intents can get through the filter.

• On the other hand, an Intent object that doesn't specify an action automatically passes the test — as long as the filter contains at least one action.

Category test

An <intent-filter> element also lists categories as subelements. For example:

<intent-filter . . . >

<category android:name=

"android

intent

category.DEFAULT" />

<category android:name=

"android

intent

category.BROWSABLE" />

</intent-filter>

Note that the constants described earlier for actions and categories are not used in the manifest file. The full string values are used instead. For instance, the "android.intent.category.BROWSABLE" string in the example above corresponds to the CATEGORY BROWSABLE constant mentioned earlier in this document. Similarly, the string "android.intent.action.EDIT" corresponds to the ACTION_EDIT constant.

For an intent to pass the category test, every category in the Intent object must match a category in the filter. The filter can list additional categories, but it cannot omit any that are in the intent.

Data test

Like the action and categories, the data specification for an intent filter is contained in a subelement. And, as in those cases, the subelement can appear multiple times, or not at all. For example:

<intent-filter .

. >

<data android

mimeType=

"video/mpeg"

android:scheme="http" .

. />

<data android

mimeType=

"audio/mpeg"

android:scheme="http" .

. />

</intent-filter>

Each <data> element can specify a URI and a data type (MIME media type). There are separate attributes — scheme, host, port, and path — for each part of the URI:

0 0

Post a comment