Android Manifest File in Android

Android Manifest file: To start an application component the Android system must know that it exists. For this reason applications declare their components in a manifest file. Every project must have in its root directory an AndroidManifest.xml file (with exactly that name) defining the structure and metadata of the application and its components. This structured XML file, in addition to declaring the application's components, does some other things, among which:

• Naming the Java package so that the application has a unique identifier

• Determining which processes will host application components.

• Declaring the permissions the application must have in order to access protected parts of the API and interact with other applications and the permissions that others are required to have in order to interact with the application's components.

• Listing the Instrumentation classes that provide profiling and other information as the application is running (these declarations are present in the manifest only during development and testing but are removed before the application is published)

• Declaring the minimum level of the Android API that the application requires

• Listing the libraries the application needs to be linked to.

The general structure of the manifest is showed below:

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

<manifest>

<uses-permission />

<permission />

<permission-tree />

<permission-group />

<instrumentation />

<uses-sdk />

<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 />

</provider>

<uses-library />

</application>

</manifest>

               As we can see, the file includes nodes (represented by tags) for each of the components(Activities, Services, Content Providers, and Broadcast Receivers) that make up the application and, using Intent Filters and Permissions, determines how they interact with each other and with other applications. It also offers attributes to specify application metadata (like its icon or theme), and additional top-level nodes can be used for security settings and unit tests. The root manifest tag includes all the nodes of the file, among which:

• the application node, one for each manifest, specifying the metadata for the application (including its title, icon, and theme). It also acts as a container that includes the Activity, Service, Content Provider, and Broadcast Receiver tags used to specify the application components.

• the activity tag, required for every Activity or any other screen or dialog to be displayed, with the android:name attribute to specify the class name. Trying to start an Activity that’s not defined in the manifest will throw a runtime exception. Each Activity node supports intent-filter child tags that specify which Intents launch the Activity.

• the service node, one for each Service class used in the application, also supporting intent-filter child tags to allow late runtime binding. 

Broadcast receivers can either be declared in the manifest, or they can be created dynamically in code.

- Begins with the necessary prolog, which identifies this file as an XML version 1.0 file, whose content is encoded according to the UTF-8 encoding standard.
- next presents a tag, which is this XML document’s root element; android identifies the Android namespace, package identifies the app’s Java package, and versionCode/versionName identify version information.
-Nested within is , which is the parent of app component tags.The icon and label attributes refer to icon and label resources that Android devices display to represent the app. 
NOTE: Resources are identified by the @ prefix, followed by a resource category name (such as string or drawable), /, and the resource ID (such as app_name or icon).

-The tag’s icon and label attributes specify defaults that are inherited by components whose tags don’t specify these attributes. 
-Nested within is , which describes an activity component. This tag’s name attribute identifies a class (MyActivity) that implements the activity. This name begins with a period character to imply that it’s relative to com.example.project.

NOTE: The period is not present when AndroidManifest.xml is created at the command line. However, this character is present when this file is created from within Eclipse . Regardless, MyActivity is relative to ’s package value (com.example.project).

- Nested within is . This tag declares the capabilities of the component described by the enclosing tag. For example, it declares the capabilities of the activity component via its nested and tags. 
- identifies the action to perform. This tag’s android:name attribute is assigned "android.intent.action.MAIN" to identify the activity as the app’s entry point.
- identifies a component category. This tag’s android:name attribute is assigned "android.intent.category.LAUNCHER" to identify the activity as needing to be displayed in the app launcher.

NOTE: Other components are similarly declared. For example, services are declared via  tags, broadcast receivers are declared via tags, and content providers are declared via tags. Except for broadcast receivers, which can be created at runtime, components not declared in the manifest are not created by Android.

-The manifest may also contain tags to identify permissions that the app needs. For example, an app that needs to use the camera would specify the following tag: .

NOTE: tags are nested within tags. They appear at the same level as the tag.

At app-install time, permissions requested by the app (via ) are granted to it by Android’s package installer, based upon checks against the digital signatures of the apps declaring those permissions and/or interaction with the user. No checks with the user are done while an app is running. It was granted a specific permission when installed and can use that feature as desired, or the permission was not granted and any attempt to use the feature will fail without prompting the user.

NOTE: AndroidManifest.xml provides additional information, such as naming any libraries that the app needs to be linked against (besides the default Android library), and identifying all app-enforced permissions (via tags) to other apps, such as controlling who can start the app’s activities.