In the Beginning There Was the Root, and It Was Good

The root of all manifest files is, not surprisingly, a element:

Note the namespace declaration. Curiously, the generated manifests apply it only on the attributes, not the elements (e.g., it’s , not ). However, that pattern works, so unless Android changes, stick with their pattern.

The biggest piece of information you need to supply on the manifest element is the attribute (also curiously not namespaced). Here you can provide the name of the Java package that will be considered the “base” of your application. Then, everywhere else in the manifest file that needs a class name, you can just substitute a leading dot as shorthand for the package. For example, if you needed to refer to in our example manifest, you could just use since is defined as the application’s package.

Permissions, Instrumentations, and Applications (Oh, My!)

Underneath the manifest element, you will find the following:

• elements to indicate what permissions your application will need in order to function properly. See Chapter 29 for more details.

• elements to declare permissions that activities or services might require other applications hold in order to use your application’s data or logic. Again, more details are forthcoming in Chapter 29.

• elements to indicate code that should be invoked on key system events, such as starting up activities, for the purposes of logging or monitoring.

• elements to hook in optional Android components, such as mapping services

• Possibly a element to indicate what version of the Android SDK the application was built for.

• An element defining the guts of the application that the manifest describes.

In the following example the manifest has uses‑permission elements to indicate some device capabilities the application will need – in this case, permissions to allow the application to determine its current location. And there is the application element, whose contents will describe the activities, services, and whatnot that make up the bulk of the application itself.

Your Application Does Something, Right?

The real meat of the manifest file is the children of the element.

By default, when you create a new Android project, you get a single element:

This element supplies for the class implementing the activity, for the display name of the activity, and (frequently) an child element describing under what conditions this activity will be displayed. The stock element sets up your activity to appear in the launcher, so users can choose to run it. As you’ll see later in this book, you can have several activities in one project if you so choose.

You may also have one or more receiver elements indicating non‑activities that should be triggered under certain conditions, such as when an SMS message comes in. These are called intent receivers and are described in Chapter 23.

You may have one or more provider elements indicating content providers – components that supply data to your activities and, with your permission, other activities in other applications on the device. These wrap up databases or other data stores into a single API that any application can use. Later you’ll see how to create content providers and how to use content providers that you or others create.

Finally, you may have one or more service elements describing services – long‑running pieces of code that can operate independent of any activity. The quintessential example is the MP3 player, where you want the music to keep playing even if the user pops open other activities and the MP3 player’s user interface is “misplaced.” Chapters 30 and 31 cover how to create and use services.