The MindroidManifest.xml File

Every application must have an MindroidManifest.xml file (with precisely that name) in its root directory. The manifest presents essential information about the application to the Mindroid 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 &mdash: the services that the application is composed of. It names the classes that implement each of the components. These declarations let the Mindroid system know what the components are and how they can be launched.
  • It determines which lightweight processes will host application components.
  • It declares the minimum level of the Mindroid API that the application requires.

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"?>

<manifest>

    <application>

        <service>
        </service>

        <uses-library />		

    </application>

</manifest>

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.

<application>
<manifest>
<service>
<uses-library>

File Conventions

Some conventions and rules apply generally to all elements and attributes in the manifest:

Elements
Only the <manifest> and <application> 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, <service> elements can be intermixed in any sequence.

Attributes
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 <manifest> element, all attribute names begin with an mindroid: prefix — for example, mindroid:name. 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 <application> element) and its principal components — services (<service>).

If you define a subclass, as you almost always would for the component classes Service, the subclass is declared through a name attribute. The name must include the full package designation. For example, an Service subclass might be declared as follows:

<manifest . . . >
    <application . . . >
        <service mindroid:name="com.example.project.ExampleService" . . . >
            . . .
        </service>
        . . .
    </application>
</manifest>

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 <manifest> element's package attribute). The following assignment is the same as the one above:

<manifest package="com.example.project" . . . >
    <application . . . >
        <service mindroid:name=".ExampleService" . . . >
            . . .
        </service>
        . . .
    </application>
</manifest>

When starting a component, Mindroid creates an instance of the named subclass. If a subclass isn't specified, it creates an instance of the base class.

File Features

The following sections describe how some Mindroid features are reflected in the manifest file.

Libraries

Every application is linked against the default Mindroid library, which includes the basic packages for building applications (with common classes such as Service, Intent, 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 <uses-library> element to name each of the libraries.