Understanding the AndroidManifest file

3.4 Understanding the AndroidManifest file

As you learned in chapter 1, Android requires a manifest file for every applica- tion—AndroidManifest.xml. This file, which is placed in the root directory of the proj- ect source, describes the application context and any supported activities, services, intent receivers, and/or content providers, as well as permissions. You will learn more about services, intents, and intent receivers in the next chapter and about content providers in chapter 5. For now the manifest for our RestaurantFinder sample applica- tion, as shown in listing 3.11, contains only the <application> itself, an <activity> element for each screen, and several <uses-permission> elements.

Listing 3.12 The RestaurantFinder AndroidManifest.xml file

<?xml version="1.0" encoding="utf-8"?>

Include <manifest> declaration B

<manifest xmlns:android="http://schemas.android.com/apk/res/android" <application android:icon="@drawable/restaurant_icon_trans"

android:label="@string/app_short_name" android:name="RestaurantFinderApplication"

C Include RestaurantFinder-

android:allowClearUserData="true"

Application declaration

android:theme="@android:style/Theme.Black"> <activity android:name="ReviewCriteria"

D Define Review-

android:label="@string/app_short_name">

Criteria Activity

<intent-filter>

<action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity>

Define MAIN LAUNCHER Intent filter E

94 C HAPTER 3 User interfaces

<activity android:name="ReviewList"

F Define ReviewList Activity

android:label="@string/app_name_reviews"> <intent-filter>

G Define custom Intent filter

<category android:name="android.intent.category.DEFAULT" /> <action

android:name="com.msi.manning.restaurant.VIEW_LIST" /> </intent-filter> </activity>

<activity android:name="ReviewDetail" android:label="@string/app_name_review"> <intent-filter>

<category android:name="android.intent.category.DEFAULT" /> <action android:name="com.msi.manning.restaurant.VIEW_DETAIL" /> </intent-filter> </activity>

Add permissions H

</application>

<uses-permission android:name="android.permission.CALL_PHONE" /> <uses-permission android:name="android.permission.INTERNET" />

</manifest> In the RestaurantFinder descriptor file we first see the root <manifest> element dec-

laration, which includes the application’s package declaration and the Android

namespace B . Then we see the <application> element with both the name and icon attributes defined C . You don’t have to include the name attribute here unless you

want to extend the default Android Application object to provide some global state to your application (which we did to store the Review object each screen is operating on). The icon is also optional; if not specified, a system default is used to represent your application on the main menu.

After the application itself is defined, we see the child <activity> elements within.

These, obviously, define each Activity the application supports D (note that the mani-

fest file can use Android resources as well, such as with @string/app_name). As was not-

ed when discussing activities in general, one Activity in every application is the starting point; this Activity has the <intent-filter> action MAIN and category LAUNCHER des-

ignation E . This tells the Android platform how to start an application from the

Launcher , meaning this Activity will be placed in the main menu on the device. Past the ReviewCriteria Activity we see another <activity> designation for

ReviewList F . This Activity also includes an <intent-filter>, but for our own action, com.msi.manning.chapter3.VIEW_LIST G . This tells the platform that this

Activity should be invoked for this “intent.” You will learn more about exactly how this works in the next chapter. Last in our manifest we have a <uses-permission> H element. This also relates to intents and tells the platform that this application needs the CALL_PHONE permission. (We discussed several aspects of security in chapter 2, and we will touch on this in various contexts throughout the book.)

The RestaurantFinder sample application uses a fairly basic manifest file with three activities and a series of intents. This is not a comprehensive example, of course, but all of the elements an Android manifest supports are shown in table 3.4 for reference.

Summary

Table 3.4 Supported AndroidManifest.xml elements and their descriptions Element

Description <manifest>

Position

root

Defines application package and Android namespace

<uses-permission> root Requests a security permission <permission>

Declares a security permission <instrumentation> root

root

Declares a test instrumentation component <application>

root

Defines an application, class name, label, icon, or theme (one per manifest)

<activity>

Defines an Activity class <intent-filter>

child of <application>

Declares the Intent s an Activity supports <action>

child of <activity>

child of <intent-filter>

Intent action

<category>

child of <intent-filter>

Intent category

<data>

child of <intent-filter>

Intent MIME type, URI scheme, URI authority, or URI path

<meta-data>

child of <activity>

General metadata, accessible via Compo- nentInfo.metaData

<receiver>

root

Defines an IntentReceiver , responds to Intent s (also supports <intent-filter> children)

<service>

root

Defines a background Service (also supports <intent-filter> children)

<provider>

root

Defines a ContentProvider to manage persis- tent data for access by other applications

Wrapping up the description of the manifest file completes our discussion of views, activities, resources, and in general working with UIs in Android.