Application manifest Introduction

Each Android application contains a manifest file named androidmanifest. XML, which is stored in the root directory of the project. This file defines the structure and metadata of the application and their components.

 

It contains activities, services, content providers, and broadcast referers. These components constitute the entire application. In addition, intent filter and permission are used to determine how they affect each other and how they affect other applications.

 

It also provides features to specify the metadata of an application (such as an icon or theme). It also provides high-level nodes for security setting and unit testing. Description:

The manifest file uses the <manifest/> label as the root and contains the package feature to set the package name of the project. It also includes the xmlns: Android feature to import namespaces and provide some system features. A typical manifest node is shown in the following XML snippet:

 

<Manifest xmlns: Android = http://schemas.android.com/apk/res/android

Package = "com. my_domain.my_app">

[... Manifest nodes...]

</Manifest>

 

The <manifest/> label contains nodes of application components, which are application components, security settings, and test classes. The following list provides an overview of the available manifest label nodes and a demonstration of XML fragments:

 

Using Application

The manifest file can only contain one application node. You can specify the metadata of an application, such as title, icon, and theme through feature settings. At the same time, it can be represented as a container that holds the tags of activity, service, content provider, and broadcast aggreger.

 

<Application Android: icon = "@ drawable/icon"

Android: theme = "@ style/my_theme">

[... Application nodes...]

</Application>

 

Publish Activity

The activity displayed in the application must define an activity tag to specify the class name through the Android: Name feature. It must contain the activity used in the startup activity and other screens or dialogs. If you try to start an activity that is not defined in manifest, a runtime exception is thrown. Each activity node supports the intent-filter sub-tag to specify which intents start the activity.

 

<Activity Android: Name = ". myactivity" Android: Label = "@ string/app_name">

<Intent-filter>

<Action Android: Name = "android. Intent. Action. Main"/>

<Category Android: Name = "android. Intent. Category. launcher"/>

</Intent-filter>

</Activity>

 

Container Service

Like the activity tag, define a service tag for the Service (service details are described in Chapter 8th) class used in the application. The service tag also supports the intents-filter sub-tag to allow binding during later running.

 

<Service android: enabled = "true" Android: Name = ". myservice"> </service>

 

❑ Provider

The provider tag is used to indicate the content provider in the application. Content Provider is used to manage database access and sharing between applications (exercises in Chapter 6th ).

 

<Provider Android: Permission = "com. paad. my_permission"

Android: Name = ". mycontentprovider"

Android: enabled = "true"

Android: Authorities = "com. paad. MyApp. mycontentprovider">

</Provider>

 

Aggregatorer

By adding the receiver tag, you can register a broadcast receiver before starting the application. As you can see in Chapter 5th, the broadcast receiver is like a global event listener. Once registered, it will be executed when the application broadcasts the corresponding intents. By registering a broadcast receiver in manifest, the application starts automatically when the corresponding intent is broadcast and the registered broadcast receiver runs.

 

<Cycler Android: enabled = "true"

Android: Label = "my broadcast receiver"

Android: Name = ". mybroadcastreceiver">

</Cycler>

 

❑ Uses-Permission

As part of the security model, the uses-Permission label declares the authorization required for the proper operation of the application. These authorizations include whether the user is authorized to perform operations during installation. Many Android services contained in the device need authorization, especially those services that require money or security (such as phones, sending and receiving SMS, or using local services ). As shown below, third-party programs, including yours, can specify authorization before providing the use power of shared program components.

 

<Uses-Permission Android: Name = "android. Permission. access_location">

</Uses-Permission>

 

❑ Permission

Before you restrict the use of application components, You need to define an authorization in the manifest file. Use the permission label to create an authorization definition. The application component is used by adding the Android: Permission feature. Other applications also need to include uses-permission in their manifest files before using those post-protected components.

With the permission tag, you can specify the authorization level (normal, dangerous, signature, signatureorsystem), tag, and description (defined in the external resource string, explaining the risk of authorization.

 

<Permission Android: Name = "com. paad. detonate_device"

Android: protectionlevel = "dangerous"

Android: Label = "self destruct"

Android: Description = "@ string/detonate_description">

</Permission>

 

❑ Instrumentation

The instrumentation class provides a framework for testing activity and service at runtime. They provide hooks to monitor applications and interact with system resources. Create a node for the test class defined in the program.

 

<Instrumentation Android: Label = "my test"

Android: Name = ". mytestclass"

Android: targetpackage = "com. paad. apackage">

</Instrumentation>

 

For more detailed descriptions of manifest and each node, see:

Http://code.google.com/android/devel/bblocks-manifest.html

 

ADT's new project wizard automatically creates a manifest file when creating a new project. Only when you introduce new components to an application will you return to the manifest file.