Info

syntax:

<receiver android:enabled=["true" | "false"] android:exported=["true" | "false"] android:icon="drawable resource" android:label="string resource" android:name="string" android:permission="string" android:process="string" >

</receiver>

CONTAINED IN:

<application>

CAN CONTAIN:

<intent-filer> <meta-data>

description:

Declares a broadcast receiver (a BroadcastReceiver subclass) as one of the application's components. Broadcast receivers enable applications to receive intents that are broadcast by the system or by other applications, even when other components of the application are not running.

There are two ways to make a broadcast receiver known to the system: One is declare it in the manifest file with this element. The other is to create the receiver dynamically in code and register it with the Context.registerReceiver() method. See the BroadcastReceiver class description for more on dynamically created receivers.

attributes:

android:enabled

Whether or not the broadcast receiver can be instantiated by the system — "true" if it can be, and "false" if not. The default value is "true".

The <application> element has its own enabled attribute that applies to all application components, including broadcast receivers. The <application> and <receiver> attributes must both be "true" for the broadcast receiver to be enabled. If either is "false", it is disabled; it cannot be instantiated.

android:exported

Whether or not the broadcast receiver can receive messages from sources outside its application — "true" if it can, and "false" if not. If "false", the only messages the broadcast receiver can receive are those sent by components of the same application or applications with the same user ID.

The default value depends on whether the broadcast receiver contains intent filters. The absence of any filters means that it can be invoked only by Intent objects that specify its exact class name. This implies that the receiver is intended only for application-internal use (since others would not normally know the class name). So in this case, the default value is "false". On the other hand, the presence of at least one filter implies that the broadcast receiver is intended to receive intents broadcast by the system or other applications, so the default value is "true".

This attribute is not the only way to limit a broadcast receiver's external exposure. You can also use a permission to limit the external entities that can send it messages (see the permission attribute).

android:icon

An icon representing the broadcast receiver. This attribute must be set as a reference to a drawable resource containing the image definition. If it is not set, the icon specified for the application as a whole is used instead (see the <application> element's icon attribute).

The broadcast receiver's icon — whether set here or by the <application> element — is also the default icon for all the receiver's intent filters (see the <intent-filter> element's icon attribute).

android:label

A user-readable label for the broadcast receiver. If this attribute is not set, the label set for the application as a whole is used instead (see the <application> element's label attribute).

The broadcast receiver's label — whether set here or by the <application> element — is also the default label for all the receiver's intent filters (see the <intent-filter> element's label attribute).

The label should be set as a reference to a string resource, so that it can be localized like other strings in the user interface. However, as a convenience while you're developing the application, it can also be set as a raw string.

android:name

The name of the class that implements the broadcast receiver, a subclass of BroadcastReceiver. This should be a fully qualified class name (such as, "com.example.project.ReportReceiver"). However, as a shorthand, if the first character of the name is a period (for example, ". ReportReceiver"), it is appended to the package name specified in the <manifest> element.

There is no default. The name must be specified.

android:permission

The name of a permission that broadcasters must have to send a message to the broadcast receiver. If this attribute is not set, the permission set by the <application> element's permission attribute applies to the broadcast receiver. If neither attribute is set, the receiver is not protected by a permission.

For more information on permissions, see the Permissions section in the introduction and a separate document, Security and Permissions.

android:process

The name of the process in which the broadcast receiver should run. Normally, all components of an application run in the default process created for the application. It has the same name as the application package. The <application> element's process attribute can set a different default for all components. But each component can override the default with its own process attribute, allowing you to spread your application across multiple processes.

If the name assigned to this attribute begins with a colon (':'), a new process, private to the application, is created when it's needed and the broadcast receiver runs in that process. If the process name begins with a lowercase character, the receiver will run in a global process of that name, provided that it has permission to do so. This allows components in different applications to share a process, reducing resource usage.

INTRODUCED IN: API Level 1

Except as noted, this content is licensed under Apache 2.0. For details and restrictions, see the Content License. ! Go to top

Site Terms of Service - Privacy Policy - Brand Guidelines

developers

<service>

syntax:

<service android

enabled=["true" | "false"]

android:

exported[="true" | "false"]

android:

icon="drawable resource"

android:

label="string resource"

android

name="string"

android:

permission="string"

android:

process="string" >

</service>

<application>

CONTAINED IN:

<application>

CAN CONTAIN:

<intent-filer> <meta-data>

DESCRIPTION:

Declares a service (a Service subclass) as one of the application's components. Unlike activities, services lack a visual user interface. They're used to implement long-running background operations or a rich communications API that can be called by other applications.

All services must be represented by <service> elements in the manifest file. Any that are not declared there will not be seen by the system and will never be run.

attributes:

android:enabled

Whether or not the service can be instantiated by the system — "true" if it can be, and "false" if not. The default value is "true".

The <application> element has its own enabled attribute that applies to all application components, including services. The <application> and <service> attributes must both be "true" (as they both are by default) for the service to be enabled. If either is "false", the service is disabled; it cannot be instantiated.

android:exported

Whether or not components of other applications can invoke the service or interact with it — "true" if they can, and "false" if not. When the value is "false", only components of the same application or applications with the same user ID can start the service or bind to it.

The default value depends on whether the service contains intent filters. The absence of any filters means that it can be invoked only by specifying its exact class name. This implies that the service is intended only for application-internal use (since others would not know the class name). So in this case, the default value is "false". On the other hand, the presence of at least one filter implies that the service is intended for external use, so the default value is "true".

This attribute is not the only way to limit the exposure of a service to other applications. You can also use a permission to limit the external entities that can interact with the service (see the permission attribute).

android:icon

An icon representing the service. This attribute must be set as a reference to a drawable resource containing the image definition. If it is not set, the icon specified for the application as a whole is used instead (see the <application> element's icon attribute).

The service's icon — whether set here or by the <application> element — is also the default icon for all the service's intent filters (see the <intent-filter> element's icon attribute).

android:label

A name for the service that can be displayed to users. If this attribute is not set, the label set for the application as a whole is used instead (see the <application> element's label attribute).

The service's label — whether set here or by the <application> element — is also the default label for all the service's intent filters (see the <intent-filter> element's label attribute).

The label should be set as a reference to a string resource, so that it can be localized like other strings in the user interface. However, as a convenience while you're developing the application, it can also be set as a raw string.

android:name

The name of the Service subclass that implements the service. This should be a fully qualified class name (such as, "com.example.project.RoomService"). However, as a shorthand, if the first character of the name is a period (for example, ".RoomService"), it is appended to the package name specified in the <manifest> element.

There is no default. The name must be specified. android:permission

The name of a permission that that an entity must have in order to launch the service or bind to it. If a caller of startService(), bindService(), or stopService(), has not been granted this permission, the method will not work and the Intent object will not be delivered to the service.

If this attribute is not set, the permission set by the <application> element's permission attribute applies to the service. If neither attribute is set, the service is not protected by a permission.

For more information on permissions, see the Permissions section in the introduction and a separate document, Security and Permissions.

android:process

The name of the process where the service is to run. Normally, all components of an application run in the default process created for the application. It has the same name as the application package. The <application> element's process attribute can set a different default for all components. But component can override the default with its own process attribute, allowing you to spread your application across multiple processes.

If the name assigned to this attribute begins with a colon (':'), a new process, private to the application, is created when it's needed and the service runs in that process. If the process name begins with a lowercase character, the service will run in a global process of that name, provided that it has permission to do so. This allows components in different applications to share a process, reducing resource usage.

see also:

<application> <activity>

introduced in: API Level 1

t Go to top

Except as noted, this content is licensed under Apache 2.0. For details and restrictions, see the Content License. J-

Site Terms of Service - Privacy Policy - Brand Guidelines

developers

<uses-configuration>

syntax:

<uses-configuration android

reqFiveWayNav=["true" | "false"!

android:

reqHardKeyboard=l""true" | "false"!

|

reqKeyboardType=l""undefined

| "nokeys"

| "qwerty"

1

"twelvekey'

!

android

reqNavigation=["undefined"

"nonav" |

"dpad" |

"trackball"

"wheel"!

| |

reqTouchScreen=T"undefined"

| "notouch"

| "stylus"

"finger"] />

CONTAINED IN: <manifest>

CONTAINED IN: <manifest>

DESCRIPTION:

Indicates what hardware and software features the application requires. For example, an application might specify that it requires a physical keyboard or a particular navigation device, like a trackball. The specification is used to avoid installing the application on devices where it will not work.

If an application can work with different device configurations, it should include separate <uses-configuration> declarations for each one. Each declaration must be complete. For example, if an application requires a five-way navigation control, a touch screen that can be operated with a finger, and either a standard QWERTY keyboard or a numeric 12-key keypad like those found on most phones, it would specify these requirements with two <uses-configuration> elements as follows:

<uses-configuration android:reqFiveWayNav="true" android:reqTouchScreen="finger"

android:reqKeyboardType="qwerty" /> <uses-configuration android:reqFiveWayNav="true" android:reqTouchScreen="finger"

android:reqKeyboardType="twelvekey" />

attributes:

android:reqFiveWayNav

Whether or not the application requires a five-way navigation control — "true" if it does, and "false" if not. A five-way control is one that can move the selection up, down, right, or left, and also provides a way of invoking the current selection. It could be a D-pad (directional pad), trackball, or other device.

If an application requires a directional control, but not a control of a particular type, it can set this attribute to "true" and ignore the reqNavigation attribute. However, if it requires a particular type of directional control, it can ignore this attribute and set reqNavigation instead.

android:reqHardKeyboard

Whether or not the application requires a hardware keyboard — "true" if it does, and "false" if not.

android:reqKeyboardType

The type of keyboard the application requires, if any at all. This attribute does not distinguish between hardware and software keyboards. If a hardware keyboard of a certain type is required, specify the type here and also set the reqHardKeyboard attribute to "true".

The value must be one of the following strings: I-1-1

Value

Description

"undefined"

The application does not require a keyboard. (A keyboard requirement is not defined.) This is the default value.

"nokeys"

The application does not require a keyboard.

"qwerty"

The application requires a standard QWERTY keyboard.

"twelvekey"

The application requires a twelve-key keypad, like those on most phones — with keys for the digits from 0 through 9 plus star (*) and pound (#) keys.

android:reqNavigation

The navigation device required by the application, if any. The value must be one of the following strings:

Value

Description

"undefined"

The application does not require any type of navigation control. (The navigation requirement is not defined.) This is the default value.

"nonav"

The application does not require a navigation control.

"dpad"

The application requires a D-pad (directional pad) for navigation.

"trackball"

The application requires a trackball for navigation.

"wheel"

The application requires a navigation wheel.

If an application requires a navigational control, but the exact type of control doesn't matter, it can set the reqFiveWayNav attribute to "true" rather than set this one.

android:reqTouchScreen

The type of touch screen the application requires, if any at all. The value must be one of the following strings:

Value

Description

"undefined"

The application doesn't require a touch screen. (The touch screen requirement is undefined.) This is the default value.

"notouch"

The application doesn't require a touch screen.

"stylus"

The application requires a touch screen that's operated with a stylus.

"finger"

The application requires a touch screen that can be operated with a finger.

introduced in: API Level 3

see also:

configChanges attribute of the <activity> element

Except as noted, this content is licensed under Apache 2.0. For details and restrictions, see the Content License. ! Go to top

Site Terms of Service - Privacy Policy - Brand Guidelines

0 0

Post a comment