Every application must have an
AndroidManifest.xml file (with precisely that
name) in its root directory. The manifest file
provides essential information about your app to the Android system, which
the system must have before it can run any of the app's
Among other things, the manifest file does the following:
Intentmessages that they can handle. These declarations inform the Android system of the components and the conditions in which they can be launched.
Instrumentationclasses that provide profiling and other information as the application runs. These declarations are present in the manifest only while the application is being developed and are removed before the application is published.
Note: As you prepare your Android app to run on Chromebooks, there are some important hardware and software feature limitations that you should consider. See the App Manifest Compatibility for Chromebooks document for more information.
The code snippet 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 fully documented in a separate file.
Tip: To view detailed information about any of the elements that are mentioned within the text of this document, simply click the element name.
Here is an example of the manifest file:
<?xml version="1.0" encoding="utf-8"?> <manifest> <uses-permission /> <permission /> <permission-tree /> <permission-group /> <instrumentation /> <uses-sdk /> <uses-configuration /> <uses-feature /> <supports-screens /> <compatible-screens /> <supports-gl-texture /> <application> <activity> <intent-filter> <action /> <category /> <data /> </intent-filter> <meta-data /> </activity> <activity-alias> <intent-filter> . . . </intent-filter> <meta-data /> </activity-alias> <service> <intent-filter> . . . </intent-filter> <meta-data/> </service> <receiver> <intent-filter> . . . </intent-filter> <meta-data /> </receiver> <provider> <grant-uri-permission /> <meta-data /> <path-permission /> </provider> <uses-library /> </application> </manifest>
The following list contains all of the elements that can appear in the manifest file, in alphabetical order:
Note: These are the only legal elements – you cannot add your own elements or attributes.
This section describes the conventions and rules that apply generally to all of the elements and attributes in the manifest file.
<application>elements are required. They each must be present and can occur only once. Most of the other elements can occur many times or not at all. However, at least some of them must be present before the manifest file becomes useful.
If an element contains anything at all, it contains other elements. All of the values are set through attributes, not as character data within an element.
Except for some attributes of the root
element, all attribute names begin with an
android:alwaysRetainTaskState. Because the prefix is
universal, the documentation generally omits it when referring to attributes
<application>element) and its principal components: activities (
<activity>), services (
<service>), broadcast receivers (
<receiver>), and content providers (
If you define a subclass, as you almost always would for the component classes
the subclass is declared through a
name attribute. The name must include
the full package designation.
For example, a
Service subclass might be declared as follows:
<manifest . . . > <application . . . > <service android:name="com.example.project.SecretService" . . . > . . . </service> . . . </application> </manifest>
However, if the first character of the string is a period, the
application's package name (as specified by the
attribute) is appended to the string. The following assignment is the same as that shown above:
<manifest package="com.example.project" . . . > <application . . . > <service android:name=".SecretService" . . . > . . . </service> . . . </application> </manifest>
When starting a component, the Android system creates an instance of the named subclass. If a subclass isn't specified, it creates an instance of the base class.
<intent-filter . . . > <action android:name="android.intent.action.EDIT" /> <action android:name="android.intent.action.INSERT" /> <action android:name="android.intent.action.DELETE" /> . . . </intent-filter>
You can ommit the package name if the resource is in the same package as the application. The type is a type of resource, such as string or drawable, and the name is the name that identifies the specific resource. Here is an example:
<activity android:icon="@drawable/smallPic" . . . >
The values from a theme are expressed similarly, but with an initial
\\) to escape characters, such as
\\nfor a newline or
\\uxxxxfor a Unicode character.
The following sections describe the way that some Android features are reflected in the manifest file.
The core components of an application, such as its activities, services, and broadcast
receivers, are activated by intents. An intent is a
bundle of information (an
Intent object) describing a
desired action, including the data to be acted upon, the category of
component that should perform the action, and other pertinent instructions.
The Android system locates an appropriate component that can respond to the intent, launches
a new instance of the component if one is needed, and passes it the
The components advertise the types of intents that they can
respond to through intent filters. Since the Android system
must learn the intents that a component can handle before it launches the component,
intent filters are specified in the manifest as
elements. A component can have any number of filters, each one describing
a different capability.
An intent that explicitly names a target component activates that component, so the filter doesn't play a role. 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.
A number of elements have
label attributes for a
small icon and a text label that can be displayed to users. Some also have a
description attribute 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 are all presented to the user.
In every case, the icon and label that are set in a containing element become the default
label settings for all of the container's subelements.
Thus, the icon and label that are set in the
element are the default icon and label for each of the application's components.
Similarly, the icon and label that are set for a component, such as 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 that are set for an intent filter represent a component
whenever the component is presented to the user and fulfills the function
that is advertised by the filter. For example, a filter with
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
that are set in the filter are displayed in the launcher.
A permission is a restriction that limits 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. Here are some permissions that are defined by Android:
A feature can be protected by only one permission.
If an application needs access to a feature that is protected by a permission,
it must declare that it requires the permission with a
element in the manifest. When the application is installed on
the device, the installer determines whether 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 fail
without any notification to the user.
An application can also protect its own components with permissions. It can employ
any of the permissions that are defined by Android, as listed in
android.Manifest.permission, or declared
by other applications. It can also define its own. A new permission is declared
element. For example, an activity could be protected as follows:
<manifest . . . > <permission android:name="com.example.project.DEBIT_ACCT" . . . /> <uses-permission android:name="com.example.project.DEBIT_ACCT" /> . . . <application . . .> <activity android:name="com.example.project.FreneticActivity" android:permission="com.example.project.DEBIT_ACCT" . . . > . . . </activity> </application> </manifest>
Note that, in this example, the
DEBIT_ACCT permission is not only
declared with the
element, its use is also requested with the
element. You must request its use 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 shown above, the
permission attribute was set to a
permission that is declared elsewhere,
android.permission.CALL_EMERGENCY_NUMBERS, it would not
be necessary to declare it again with a
element. However, it would still be necessary to request its use with
element declares a namespace for a group of permissions that are defined in
code, and the
defines a label for a set of permissions, both those declared in the manifest with
elements and those declared elsewhere. This affects only how the permissions are
grouped when presented to the user. The
element does not specify the permissions that belong to the group, but
it gives the group a name. You can place a permission 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, and ContentProvider).
However, some packages reside in their own libraries. If your application
uses code from any of these packages, it must explicitly ask to be linked
against them. The manifest must contain a separate
element to name each of the libraries. You can find the library name in the
documentation for the package.