XML usage and the AndroidManifest.xml File
XML on Android
The Android platform is an open source mobile development platform. It gives you access to all aspects of the mobile device that it runs on, from low level graphics, to hardware like the camera on a phone. With so many things possible using Android, you might wonder why you need to bother with XML. It is not that working with XML is so interesting; it is working with the things that it enables. XML is commonly used as a data format on the Internet. If you want to access data from the Internet, chances are that the data will be in the form of XML. If you want to send data to a Web service, you might also need to send XML. In short, if your Android application will leverage the Internet, then you will probably need to work with XML. Luckily, you have a lot of options available for working with XML on Android.
One of the greatest strengths of the Android platform is that it leverages the Java programming language. The Android SDK does not quite offer everything available to your standard Java Runtime Environment (JRE,) but it supports a very significant fraction of it. The Java platform has supported many different ways to work with XML for quite some time, and most of Java's XML-related APIs are fully supported on Android. For example, Java's Simple API for XML (SAX) and the Document Object Model (DOM) are both available on Android. Both of these APIs have been part of Java technology for many years. The newer Streaming API for XML (StAX) is not available in Android. However, Android provides a functionally equivalent library. Finally, the Java XML Binding API is also not available in Android. This API could surely be implemented in Android. However, it tends to be a heavyweight API, with many instances of many different classes often needed to represent an XML document. Thus, it is less than ideal for a constrained environment such as the handheld devices that Android is designed to run on. In the following sections, you will take a simple source of XML available on the Internet, and see how to parse it within an Android application using the various APIs mentioned above. First, look at the essential parts of the simple application that will use XML from the Internet.
In a Java environment, you can often use the SAX API when you want a fast parser and want to minimize the memory footprint of your application. That makes it very well suited for a mobile device running Android. You can use the SAX API as-is from the Java environment, with no special modifications needed to run on Android.
Easier SAX parsing
The Android SDK contains a utility class called android.util.Xml.
Working with DOM
DOM parsing on Android is fully supported. It works exactly as it works in Java code that you would run on a desktop machine or a server.
The XML pull parser
As mentioned earlier, Android does not provide support for Java's StAX API. However, Android does come with a pull parser that works similarly to StAX. It allows your application code to pull or seek events from the parser, as opposed to the SAX parser that automatically pushes events to the handler.
Every application must have an AndroidManifest.xml file (with precisely that name) in its root directory. The manifest presents essential information about the application to the Android system, information the system must have before it can run any of the application's code. Among other things, the manifest does the following:
- It names the Java package for the application. The package name serves as a unique identifier for the application.
It describes the components of the application â€” the activities, services, broadcast receivers, and content providers that the application is composed of. It names the classes that implement each of the components and publishes their capabilities (for example, which
Intentmessages they can handle). These declarations let the Android system know what the components are and under what conditions they can be launched.
- It determines which processes will host application components.
- It declares which permissions the application must have in order to access protected parts of the API and interact with other applications.
- It also declares the permissions that others are required to have in order to interact with the application's components.
It lists the
Instrumentationclasses that provide profiling and other information as the application is running. These declarations are present in the manifest only while the application is being developed and tested; they're removed before the application is published.
- It declares the minimum level of the Android API that the application requires.
- It lists the libraries that the application must be linked against.
Structure of the Manifest File
The diagram below shows the general structure of the manifest file and every element that it can contain. Each element, along with all of its attributes, is documented in full in a separate file. To view detailed information about any element, click on the element name in the diagram, in the alphabetical list of elements that follows the diagram, or on any other mention of the element name.
xml version="1.0" encoding="utf-8"?>
/> /> /> /> /> /> /> /> /> /> /> /> />/> /> . . . /> . . . . . . /> /> /> />
All the elements that can appear in the manifest file are listed below in alphabetical order. These are the only legal elements; you cannot add your own elements or attributes.
Some conventions and rules apply generally to all elements and attributes in the manifest:
elements are required, they each must be present and can occur only once. Most of the others can occur many times or not at all â€” although at least some of them must be present for the manifest to accomplish anything meaningful.
If an element contains anything at all, it contains other elements. All values are set through attributes, not as character data within an element.
Elements at the same level are generally not ordered. For example,
elements can be intermixed in any sequence. (An
element is the exception to this rule: It must follow the
it is an alias for.)
In a formal sense, all attributes are optional. However, there are some that must be specified for an element to accomplish its purpose. Use the documentation as a guide. For truly optional attributes, it mentions a default value or states what happens in the absence of a specification.
Except for some attributes of the root
element, all attribute names begin with an
android:prefix â€” for example,
android:alwaysRetainTaskState. Because the prefix is universal, the documentation generally omits it when referring to attributes by name.
- Declaring class names
Many elements correspond to Java objects, including elements for the application itself (the
element) and its principal components â€” activities (
), services (
), broadcast receivers (
), and content providers (
If you define a subclass, as you almost always would for the component classes (
ContentProvider), the subclass is declared through a
nameattribute. The name must include the full package designation. For example, an
Servicesubclass might be declared as follows:
. . . > . . . > android:name="com.example.project.SecretService" . . . > . . .. . .
However, as a shorthand, if the first character of the string is a period, the string is appended to the application's package name (as specified by the
packageattribute). The following assignment is the same as the one above:
package="com.example.project" . . . > . . . > android:name=".SecretService" . . . > . . .. . .
When starting a component, Android creates an instance of the named subclass. If a subclass isn't specified, it creates an instance of the base class.
- Multiple values
If more than one value can be specified, the element is almost always repeated, rather than listing multiple values within a single element. For example, an intent filter can list several actions:
. . . > android:name="android.intent.action.EDIT" /> android:name="android.intent.action.INSERT" /> android:name="android.intent.action.DELETE" /> . . .
- Resource values
Some attributes have values that can be displayed to users â€” for example, a label and an icon for an activity. The values of these attributes should be localized and therefore set from a resource or theme. Resource values are expressed in the following format,
where the package name can be omitted if the resource is in the same package as the application, type is a type of resource â€” such as "string" or "drawable" â€” and name is the name that identifies the specific resource. For example:
android:icon="@drawable/smallPic" . . . >
Values from a theme are expressed in a similar manner, but with an initial '
?' rather than '
- String values
Where an attribute value is a string, double backslashes ('
\\') must be used to escape characters â€” for example, '
\\n' for a newline or '
\\uxxxx' for a Unicode character.
The following sections describe how some Android features are reflected in the manifest file.
The core components of an application (its activities, services, and broadcast receivers) are activated by intents. An intent is a bundle of information (an
Intentobject) describing a desired action â€” including the data to be acted upon, the category of component that should perform the action, and other pertinent instructions. Android locates an appropriate component to respond to the intent, launches a new instance of the component if one is needed, and passes it the Intent object.
Components advertise their capabilities â€” the kinds of intents they can respond to â€” through intent filters. Since the Android system must learn which intents a component can handle before it launches the component, intent filters are specified in the manifest as
elements. A component may have any number of filters, each one describing a different capability.
An intent that explicitly names a target component will activate that component; the filter doesn't play a role. But an intent that doesn't specify a target by name can activate a component only if it can pass through one of the component's filters.
For information on how Intent objects are tested against intent filters, see a separate document, Intents and Intent Filters.
Icons and Labels
A number of elements have
labelattributes for a small icon and a text label that can be displayed to users. Some also have a
descriptionattribute for longer explanatory text that can also be shown on-screen. For example, the
element has all three of these attributes, so that when the user is asked whether to grant the permission to an application that has requested it, an icon representing the permission, the name of the permission, and a description of what it entails can all be presented to the user.
In every case, the icon and label set in a containing element become the default
labelsettings for all of the container's subelements. Thus, the icon and label set in the
element are the default icon and label for each of the application's components. Similarly, the icon and label set for a component â€” for example, an
element â€” are the default settings for each of the component's
elements. If an
element sets a label, but an activity and its intent filter do not, the application label is treated as the label for both the activity and the intent filter.
The icon and label set for an intent filter are used to represent a component whenever the component is presented to the user as fulfilling the function advertised by the filter. For example, a filter with "
android.intent.action.MAIN" and "
android.intent.category.LAUNCHER" settings advertises an activity as one that initiates an application â€” that is, as one that should be displayed in the application launcher. The icon and label set in the filter are therefore the ones displayed in the launcher.
A permission is a restriction limiting access to a part of the code or to data on the device. The limitation is imposed to protect critical data and code that could be misused to distort or damage the user experience.
Each permission is identified by a unique label. Often the label indicates the action that's restricted. For example, here are some permissions defined by Android:
A feature can be protected by at most one permission.
If an application needs access to a feature protected by a permission, it must declare that it requires that permission with a
element in the manifest. Then, when the application is installed on the device, the installer determines whether or not to grant the requested permission by checking the authorities that signed the application's certificates and, in some cases, asking the user. If the permission is granted, the application is able to use the protected features. If not, its attempts to access those features will simply fail without any notification to the user.
An application can also protect its own components (activities, services, broadcast receivers, and content providers) with permissions. It can employ any of the permissions defined by Android (listed in
android.Manifest.permission) or declared by other applications. Or it can define its own. A new permission is declared with the
element. For example, an activity could be protected as follows:
. . . > android:name="com.example.project.DEBIT_ACCT" . . . /> android:name="com.example.project.DEBIT_ACCT" /> . . . . . .> android:name="com.example.project.FreneticActivity" android:permission="com.example.project.DEBIT_ACCT" . . . > . . .
Note that, in this example, the
DEBIT_ACCTpermission is not only declared with the
element, its use is also requested with the
element. Its use must be requested in order for other components of the application to launch the protected activity, even though the protection is imposed by the application itself.
If, in the same example, the
permissionattribute was set to a permission declared elsewhere (such as
android.permission.CALL_EMERGENCY_NUMBERS, it would not have been necessary to declare it again with a
element. However, it would still have been necessary to request its use with
element declares a namespace for a group of permissions that will be defined in code. And
defines a label for a set of permissions (both those declared in the manifest with
elements and those declared elsewhere). It affects only how the permissions are grouped when presented to the user. The
element does not specify which permissions belong to the group; it just gives the group a name. A permission is placed in the group by assigning the group name to the
Every application is linked against the default Android library, which includes the basic packages for building applications (with common classes such as Activity, Service, Intent, View, Button, Application, ContentProvider, and so on).
However, some packages reside in their own libraries. If your application uses code from any of these packages, it must explicitly asked to be linked against them. The manifest must contain a separate
element to name each of the libraries. (The library name can be found in the documentation for the package.)