Start from scratch-go deep into Android (practice-let's start writing code-android framework learning-8. androidmanifest. xml file)

Chapter 2 androidmanifest. xml file

Each Android Application must have an androidmanifest. xml file under the root directory (the file name must be this ). This manifest file lists the required information of the application to the Android system. with this information, the system can run the application (You know Linux ). In addition, manifest has the following functions:

◆ Lists Java packages of applications. The package name is the only identifier that identifies an application.

◆ Describes the components of the application-activity, service, broadcast receivers, and content providers. Lists the classes that implement each component and provides possible values (for example, intent information that can be processed by the class ). These declarations enable the Android system to understand the components contained in the application and their running conditions.

◆ Determines the process of the Host application component.

◆ Declares the permissions of the application so that it can use API-protected content to interact with other applications.

◆ Permissions required for interaction between other applications and the application components are also declared.

◆ Lists the instrumentation class declarations that provide performance and other information when the application is running. These declarations are used in manifest only during development and testing, and must be deleted during release.

◆ Declares the minimum Android API level supported by the application.

◆ Lists the libraries that must be linked to an application.

8.1 manifest file structure

The following code list shows the overall structure of the manifest file and all the element structures that can be used. All attributes of each element are displayed in another separate file. They are sorted alphabetically by elements. In fact, this XML format should be very familiar to many people. (See http://developer.android.com/intl/zh-CN/guide/topics/manifest/manifest-intro.html)

<?xml version="1.0" encoding="utf-8"?><manifest>    <uses-permission />    <permission />    <permission-tree />    <permission-group />    <instrumentation />    <uses-sdk />    <uses-configuration />      <uses-feature />      <supports-screens />      <compatible-screens />      <supports-gl-texture />      <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>

 

Code List 8-1

All elements in the manifest file are listed alphabetically. These are all valid elements. You cannot add custom elements or attributes.

<Action>
<Activity>
<Activity-alias>
<Application>
<Category>
<DATA>
<Grant-Uri-Permission>
<Instrumentation>
<Intent-filter>
<Manifest>
<Meta-data>
<Permission>
<Permission-group>
<Permission-tree>
<Provider>
<Cycler>
<Service>
<Supports-screens>
<Uses-configuration>
<Uses-feature>
<Uses-library>
<Uses-Permission>
<Uses-SDK>

8.2 document conventions

Some conventions and rules generally apply to all elements and attributes in the manifest file:
1. Elements(Element, node)
Only <manifest> and <Application> elements are required and can only appear once. Most other elements can appear multiple times or not, and some elements are essential to implement meaningful functions. Elements of the same level are usually not in a fixed order. Example: <activity>, <provider>,
And <service> can appear in any order. (<Activity-alias> usually appears in sequence: it must appear after <activity> .)
2. Attributes(Attribute)
Normally, all attributes are optional. However, some attributes of an element must be specified to implement the function. You can use this document as a guide. For an attribute that is really optional, it means that there will be a default value or default status when it is not specified.
Except for some attributes of the <manifest> root element, all other attributes are prefixed with Android:-for example, Android: alwaysretaintaskstate. Because the prefix is generic, this file automatically ignores the attribute name when it is referenced.
3. Declare the class name
Many elements correspond to Java objects, including application elements (<Application> and its main components -- <activity>, <service>, <javaser>, and <provider ). If a subclass is defined, for example, the child widgets (activity, service, broadcastreceiver, and contentprovider) that the user usually defines are usually declared by the name attribute. This name must include the complete package name. For example, the subclass of a service must be defined as follows: see code list 8-2:

<manifest . . . >    <application . . . >        <service android:name="com.example.project.SecretService" . . . >            . . .        </service>        . . .    </application></manifest>

 

Code List 8-2

However, if the first character of a string is a vertex, the string is added to the package name of the application (specified by the package attribute of manifest, the following values have the same effect as above, as shown in code listing 8-3:

<manifest package="com.example.project" . . . >    <application . . . >        <service android:name=".SecretService" . . . >            . . .        </service>        . . .    </application></manifest>

 

Code List 8-3

When components are used, Android instantiates the named subclass. If the child class is not specified, the parent class is instantiated.
4. Multiple values
If an element can be assigned multiple values, it is usually repeated. For example, an intent filter can list multiple actions, as shown in code listing 8-4:

<intent-filter . . . >    <action android:name="android.intent.action.EDIT" />    <action android:name="android.intent.action.INSERT" />    <action android:name="android.intent.action.DELETE" />    . . .</intent-filter>

 

Code List 8-4

5. Resource Value
The values of some attributes can be displayed to users-for example, the label and icon of activity. The values of these attributes should be localized, so they can be obtained from a resource or topic. The resource value is usually expressed in the following format: @ [Package:] type: Name
If the resource is in the same package as the application, the package name can be omitted. Type is the type of a resource. For example, "string" or "drawable" -- name is the identifier used to identify a specific resource. The sample code is shown in listing 8 = 5:

<activity android:icon="@drawable/smallPic" . . . >

 

Code List 8-5

The value obtained from the topic can be expressed in a similar way, but the first character is used? Instead @:? [Package:] type: Name
6.String Value
When the attribute value is a string, use a double backslash ('\') to escape characters. For example, '\ n' indicates a line break, or '\ uxxxx' represents Unicode characters.

8.3 file features

The following describes the android features in the manifest file:

1. Intent Filters

Core Components of the application (activities, services, broadcast)
Receivers) is activated by intent. Intent is a set of information describing the actions to be performed (an intent object)-including dependent data, Component Types for executing actions, and other related descriptions. Android uses the corresponding component to respond to the intent, instantiate the component when needed, and pass it to the intent object.
The component uses intent filters to indicate its own capabilities-the type of intent that can respond. Before running the Android system, you must specify which intent the component can process. Therefore, you can declare the intent filter in the manifest file. A component can have multiple filters, representing different capabilities. Explicitly specifying the intent of the target component will activate the component; filters does not work. However, if an intent does not specify a target by name, the component is activated only when a filters of the component is used.

2. iconsAnd labels

Many elements have the icon and label attributes, which are used to display a small icon or text to users. Some elements also have a description attribute to display longer extension information on the screen. For example, the <permission> element has more than three attributes. Therefore, when a user requests to grant permissions to an application, the icon indicating the permission and the name of the permission are displayed, and information describing the role of permissions. The icons and labels set in the application element are the default settings for each component in the application. Similarly, the icons and labels of a component, for example, the activity element, are the default settings of each intent-filter element of the component. If a tag is set for the Application element but not for the activity and intent filters, the application tag applies to both the activity and intent filters. The icons and labels set by intent filters represent the components that implement the filter function no matter when the component is displayed to the user.
For example. intent. action. main and Android. intent. category. launcher "filters indicate that the activity starts the application -- that is, when the application starts, the activity is first displayed. Therefore, the icons and labels displayed on the startup screen are the icons and labels set in the filter.

3.Permission (permissions)

Permission is to restrict access to code or data on the device. This restriction is used to protect key code and data, so as not to cause errors or affect user experience. Each permission has a unique identifier. This mark usually indicates the restricted behavior. For example, the following are some permissions defined in Android:
Android. Permission. call_emergency_numbers
Android. Permission. read_owner_data
Android. Permission. set_wallpaper
Android. Permission. device_power
A feature can be controlled by a maximum of one permission. If the application needs to access the feature protected by permissions, you must use the <uses-Permission> element in manifest to declare that the application needs to use this permission. Then, when installing the application, the installer checks the permissions of the application certificate signed by the user, or, in some cases, asks the user, to determine whether to grant the required permissions to the application. If the authorization succeeds, the application can use the protected feature. If the authorization fails, the application fails to access the protected feature without notifying the user.
Applications can also use permissions to protect their own components (activities, services, broadcast
Receivers, content providers ). All permissions defined by Android (refer)

Http://developer.android.com/intl/zh-CN/reference/android/Manifest.permission.html

Or other permissions declared by the application. Or the application can define its own permissions. The new permission is declared through the <permission> element. For example, you can use the following methods to protect the activity, as shown in listing 8-6:

<manifest . . . >    <permission android:name="com.example.project.DEBIT_ACCT" . . . />    <uses-permission android:name="com.example.project.DEBIT_ACCT" />    . . .    <application . . .>        <activity android:name="com.example.project.FreneticActivity"                  android:permission="com.example.project.DEBIT_ACCT"                  . . . >            . . .        </activity>    </application></manifest>

 

Code List 8-6

Note: In this example, the debit_acct permission not only uses the <permission> element declaration, but also uses the <uses-Permission> declaration. This permission is required when other components of the application want to run a protected activity, even if the activity is protected by the application itself. In this example, if the permission attribute has been declared elsewhere (for example, android. permission. call_emergency_numbers), you do not need to declare the <permission> element, but the <uses-Permission> element declaration is still required.

The <permission-tree> element defines a namespace for the permission group to be used in the code. The <permission-group> element defines a label for the permission group (whether the permission is declared using the <permission> element in manifest or elsewhere ). The difference is how permissions are combined when presented to users. The <permission-group> element does not specify the group to which the permission belongs. Only the group name is given. Add the group name to the <permission-group> attribute of the <permission> element to assign the permission to the group.

4.Library

Each application is connected to the default Android library, which contains the basic package required for compiling the application (the package contains frequently used classes, such as activity, service, intent, view, button, application, contentprovider, etc ).

However, some packages have their own libraries. To use the code in these packages, the application must explicitly link the libraries of these packages. The manifest file must contain independent <uses-library> elements to list all required libraries.

FAQ: 213821767