Translate Android API Guides:app Manifest

The original is here: http://developer.android.com/guide/topics/manifest/manifest-intro.html

*manifest translation "List", the use of English is easy to understand, other terms the same.

* * Links in the text will be redirected to the Android developer site.

APP Manifest

Each application must have a copy of the Androidmanifest.xml file in its root directory (this name must be used). The Android system must be aware of some important information before running any code for the app, which comes from this manifest file. Manifest do things including but not limited to the following:

• It provides the name of the Java package in the app. The package name is the identifier used to differentiate between the current app and other apps.
• It describes all the components in the application-the Activity,service,broadcast receiver and the content provider that make up the application. It also names the classes that implement these components and publishes their scope (such as what intent they can handle). These announcements allow Android to understand which components are applied and under what circumstances they can be launched.
• It determines which process the component of the application is running in.
• It declares which permissions the app needs. Permissions are used to access some of the protected system APIs and to interact securely with other applications.
• It also declares the permissions that the app created itself. Other apps if you want to interact with the currently applied components, you need to declare these permissions in your own manifest.
• It lists the instrumentation classes that are applied. This class can provide profiling and other information that is applied at run time. It is only required during the development and testing phases to be listed in manifest, and should be removed before the app is published.
• It declares the minimum Android API level the app needs.
• It lists some of the libraries that the app must link to.

* About profiling and instrumentation I incompetence, the decisive use of English, explanation see here: http://dbanotes.net/database/instrumentation_profiling.html

Structure of the manifest file

Displays the general structure of the manifest file and all of its available elements. All of the elements, including all of its properties, have a single complete document. You can see the details of the corresponding element by clicking on the list of elements in the diagram or below the graph, or by any of the element names that have links.

<?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/>            <path-permission/>        </provider>        <uses-library/>    </Application></Manifest>

All the elements that can appear in the manifest are listed below. Only they are legitimate elements, and you cannot add your own 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>
<receiver>
<service>
<supports-screens>
<uses-configuration>
<uses-feature>
<uses-library>
<uses-permission>
<uses-sdk>

Practice

Some of the conventions and rules that are applied to all elements and attributes in manifest.

Elements

Only the <manifest> and <application> elements are required, and they must be present in manifest and can only occur once. Most of the other elements can occur many times or do not appear-although to make your manifest meaningful, there are some elements to be written in.

If an element can completely contain everything, it will contain some other elements. All data is set through attributes, not through the element's character data (which may be the term XML).

Elements of the same level are generally unordered. For example, <activity>, <provider>, and <service> elements can be mixed in any order. (The activity-alias> element is an exception, it must follow the <activity> that it wants to alias.) ）

Property

In normal terms, all properties are optional. However, some properties can only be used for specific elements to complete its functionality. Please refer to the documentation for guidance. For those that are truly optional, if left blank, the system assigns a default value.

In addition to some of the attributes used in the <manifest> element of the root node, all properties are prefixed with Android:-for example, Android:alwaysretaintaskstate. Because this prefix is universally common, it is generally omitted when the name of the property is mentioned in the document.

declaring the class name
Many elements correspond to Java objects, including elements that represent the application itself (<application> elements), and its basic components--<activity>, <service>, <receiver> <provider>.

If you define a subclass, you will, of course, use the subclass of the component class in most cases, a subclass that needs to be declared by the name attribute. Its name must include the package name of the owning package. For example, a service subclass should be defined as follows:

<Manifest. . . >    <Application. . . >        <ServiceAndroid:name= "Com.example.project.SecretService" . . . >            . . .        </Service>        . . .    </Application></Manifest>

However, it is easier to do this if the first character of the string is a period (note: Full stop, just a dot, ".") ), this character is automatically extended with the app's package name (defined in the <manifest> element's Packages property). The following method can achieve the same assignment effect as above:

<Manifest Package= "Com.example.project" . . . >    <Application. . . >        <ServiceAndroid:name=". Secretservice " . . . >            . . .        </Service>        . . .    </Application></Manifest>

When the system launches a component, Android creates an instance of this named subclass. If you do not specify a subclass, the system creates an instance of the base class.

Multiple Values
When multiple values can be specified, declare multiple elements repeatedly, instead of having multiple values in one element. For example, a intent filter can list multiple actions:

<Intent-filter. . . >    <ActionAndroid:name= "Android.intent.action.EDIT" />    <ActionAndroid:name= "Android.intent.action.INSERT" />    <ActionAndroid:name= "Android.intent.action.DELETE" />    . . .</Intent-filter>

Resource Data
Some properties have values that can be displayed to the user-for example, activity labels and icons. The values of these properties are assigned and set from the resource or subject. The value of the resource should be expressed in the following format:

@[Package:]type:name

When the resource is in the same package as the application, the package name in the previous sentence can be omitted. Type refers to the types of resources, such as "string" or "drawable"-name, which can identify the specified resource, for example:

<android:icon= "@drawable/smallpic">

The values in the topic are expressed in a similar way, but with a "?" Start instead of "@":

? [Package:] type:name

value of String type
When the value of a property is a string, you must use a double backslash ("\ \") to start the escape character. For example, "\\n" is used for line breaks, "\\uxxxx" represents a Unicode character.

Featured Features

The following section describes how some of the features of the Android feature are reflected in the manifest.

Intent Filter
The core components of the application (activity, service, broadcast receiver) are called through intent. Intent is a bundle that carries information about "what to do" (bundle? )-includes the data to be processed, the classification of the components that will perform the action, and other related directives. Android will assign an appropriate component to respond to this intent, and if needed, launch an instance of this component and send the intent object to it.

The component broadcasts its scope by intent filter, that is, which intent it responds to. Since the Android system has to know which intent it can handle before a component is started, it needs to be applied to manifest's <intent-filters> element to specify a good intent filter. A component can have any number of intent filter, each of which describes a different scope of action.

A intent that explicitly specifies the component class name can start the corresponding component; The filter does not work in it. But a intent that does not execute the target class name can only start a component by intent filter.

If you want to know how Intent filter Filters Intent objects, visit a separate document, Intents and Intent Filters.

Icons and Labels
A significant number of elements have the icon and label properties to display a small icon and a text label to the user. Some elements also have the description attribute, long explanatory text, which can also be displayed on the screen. For example, the,<permission> element has these three attributes, so when the user is asked whether to allow an app to request permission, the user sees an icon that represents the permission, the name of the permission, and a detailed description of the permission.
In any case, the icon and label owned by the element will be the default icon and label for its child elements. In this case, the icons and tags in the,<application> element are the default icons and labels for all its components. Similarly, the icon and label of a component will be the default icon and label for all of its <intent-filter>, such as an activity. If a tag is set in the <application> element, but the activity and its intent filter are not, then the applied label will be used as the tag for the activity and intent filter.
Intent filter's icons and tags are used when the system presents to the user which components can be used to complete a function (the application is intent filter to indicate to the system that it can do something). For example, a filter with "Android.intent.action.MAIN" and "Android.intent.category.LAUNCHER" can indicate to the system that the activity is the startup activity of the application, That is, the activity that should be shown in launcher. In this way, the filter icon and label are displayed in the launcher.

Permissions
Permission permissions are constraints that restrict access to some code or data on the device. This restriction is designed to protect important code and data from misuse and compromise the user experience.

Each permission is identified by a unique label. The general label will indicate the behavior it wants to restrict. For example, here are some Android-defined permissions:

     android.permission.CALL_EMERGENCY_NUMBERS
     android.permission.READ_OWNER_DATA
     android.permission.SET_WALLPAPER
     android.permission.DEVICE_POWER

A specific feature can be protected at most by one permission.

If an app needs access to a rights-protected feature, it must use the <uses-permission> element in manifest to request permissions. Then, when the app is installed on the device, the installer decides whether to allow the requested permission by checking the publisher of the app's signature or, in some cases, asking the user directly. When permission is allowed, the app can use protected features. Conversely, the action that it accesses the protected function fails directly and does not notify the user.

Apps can also use permissions to protect their own components. It can take any Android-defined permissions, or other app-defined. It can even define its own permissions. Declaring a new permission requires the <permissions> element. For example, the following activity is protected as follows:

<Manifest. . . >    <PermissionAndroid:name= "Com.example.project.DEBIT_ACCT" . . . />    <uses-permissionAndroid:name= "Com.example.project.DEBIT_ACCT" />    . . .    <Application. . .>        <ActivityAndroid:name= "Com.example.project.FreneticActivity"android:permission= "Com.example.project.DEBIT_ACCT"                  . . . >            . . .        </Activity>    </Application></Manifest>

Note that in this example, the permissions of DEBIT_ACCT are not only declared with the <permission> element, but also applied with the <uses-permission> element. Other components in the app must have this application to activate the protected activity, even if the protection was initiated by the application itself.

Also in this example, if the permission attribute is filled with a permission that has been declared elsewhere, such as android.permissioncall_emergency_numbers, there is no need to use <permission> element is declared, but it is still used for <uses-permission> applications.

The <permission-tree> element declares a namespace defined in the code by a permission group. <permission-group> defines a uniform label for a collection of permissions, including the rights to use <permission> claims in manifest, and to define permissions elsewhere. It only affects the results of permissions that are presented to users in groups. The <permission-group> element does not specify which permission belongs to this group; it simply gives the permission Group a label. Permissions can be categorized into specific groups by assigning values to the Permission-group property of the <permission> element.

Library
Each app is linked to the default Android library, which includes basic packages for building apps (such as some common class Activity, Service, View, Button, application, ContentProvider, etc.).

However, some packages depend on their own libraries. When your app uses this package, it must explicitly request a link to the dependent library. A separate <uses-library> element must be included in the manifest to make each library a named one. (The library name can be found in the package's documentation.) ）

Translate Android API Guides:app Manifest