AndroidManifest.xml

   Every application must have an AndroidManifest.xml file (with precisely that name) in its root directory. The manifest presents essential information about the application to the Android system, information the system must have before it can run any of the application's code. Among other things, the manifest does the following:

• It names the Java package for the application. The package name serves as a unique identifier for the application.
• It describes the components of the application — the activities, services, broadcast receivers, and content providers that the application is composed of. It names the classes that implement each of the components and publishes their capabilities (for example, which Intent messages they can handle). These declarations let the Android system know what the components are and under what conditions they can be launched.
• It determines which processes will host application components.
• It declares which permissions the application must have in order to access protected parts of the API and interact with other applications.
• It also declares the permissions that others are required to have in order to interact with the application's components.
• It lists the Instrumentation classes that provide profiling and other information as the application is running. These declarations are present in the manifest only while the application is being developed and tested; they're removed before the application is published.
• It declares the minimum level of the Android API that the application requires.
• It lists the libraries that the application must be linked against.

 

每个应用程序必须有个AndroidManifest.xml文件在它的根目录（必须是这个名字）。在运行任何这个应用程序的代码之前，必须通过Androidmanifest.xml将这个应用程序的基本信息告诉android系统，简单的说，就是像系统注册一些信息。具体的一些操作如下：

1，为应用程序命名一个java包名，这个包名是对应用程序是唯一的，系统不允许装两个一样包名的应用程序。

2，描述了这个应用程序的组件，包括activities，services，broadcast receivers,和content providers.这里声明这些组件类的名称以及它们能力（比如说，能处理的Intent信息的类别）.这里的声明让android系统知道什么样的组件在什么情况下被调用。

3，它声明了这些应用程序的组件分别在哪个进程中

4，它声明了一些权限permissions，为了让应用程序可以使用受保护的api和其他的应用程序进行交换

5，它还声明了一些权限permissions,为了其他的应用程序使用到了我们受保护的组件应该有的权限。

6，它列举了用来提供研究应用程序运行起来的一些信息的Instrumentation类，这些声明只有在应用程序的开发和测试阶段，不应该出现在应用程序发布后。

7，它声明了最小的api level。

8，它声明了应用程序链接的库。

Structure of the Manifest File

The diagram below shows the general structure of the manifest file and every element that it can contain. Each element, along with all of its attributes, is documented in full in a separate file. To view detailed information about any element, click on the element name in the diagram, in the alphabetical list of elements that follows the diagram, or on any other mention of the element name.

 

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

 

File Conventions

Some conventions and rules apply generally to all elements and attributes in the manifest:

 

Elements

Only the <manifest> and <application> elements are required, they each must be present and can occur only once. Most of the others can occur many times or not at all — although at least some of them must be present for the manifest to accomplish anything meaningful.

If an element contains anything at all, it contains other elements. All values are set through attributes, not as character data within an element.

Elements at the same level are generally not ordered. For example, <activity>, <provider>, and <service> elements can be intermixed in any sequence. (An <activity-alias> element is the exception to this rule: It must follow the <activity> it is an alias for.)

Attributes

In a formal sense, all attributes are optional. However, there are some that must be specified for an element to accomplish its purpose. Use the documentation as a guide. For truly optional attributes, it mentions a default value or states what happens in the absence of a specification.

Except for some attributes of the root <manifest> element, all attribute names begin with an android: prefix — for example, android:alwaysRetainTaskState. Because the prefix is universal, the documentation generally omits it when referring to attributes by name.

Declaring class names

Many elements correspond to Java objects, including elements for the application itself (the <application> element) and its principal components — activities ( <activity>), services ( <service>), broadcast receivers ( <receiver>), and content providers ( <provider>).

If you define a subclass, as you almost always would for the component classes (Activity, Service, BroadcastReceiver, and ContentProvider), the subclass is declared through a name attribute. The name must include the full package designation. For example, an Service subclass might be declared as follows:

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

However, as a shorthand, if the first character of the string is a period, the string is appended to the application's package name (as specified by the <manifest> element's package attribute). The following assignment is the same as the one above:

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

When starting a component, Android creates an instance of the named subclass. If a subclass isn't specified, it creates an instance of the base class.

Multiple values

If more than one value can be specified, the element is almost always repeated, rather than listing multiple values within a single element. For example, an intent filter can list several actions:

element. For example, an intent filter can list several actions: <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>

Resource values

Some attributes have values that can be displayed to users — for example, a label and an icon for an activity. The values of these attributes should be localized and therefore set from a resource or theme. Resource values are expressed in the following format,

 

@[package:]type:name

where the package name can be omitted if the resource is in the same package as the application, type is a type of resource — such as "string" or "drawable" — and name is the name that identifies the specific resource. For example:

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

Values from a theme are expressed in a similar manner, but with an initial '?' rather than '@':

?[package:]type:name

String values

Where an attribute value is a string, double backslashes (' //') must be used to escape characters — for example, ' //n' for a newline or ' //uxxxx' for a Unicode character.

 

文件约定(一个书写习惯)

一些约定和规矩是几乎是针对所有的manifest的元素和属性

 

元素   只有<manifest>和<application>这两个元素是必须的，他们必须出现并且只能出现一次（我亲自试过书写了两个application在里面，前一个好使，好像也没报错啊，不过有一个好使倒是认真的）。其他的大多数会出现很多次或者是不出现---其他的一些元素应该出现，这样manifest才会有意义

 

If an element contains anything at all, it contains other elements. All values are set through attributes, not as character data within an element. 如果这个元素要包含任何东西，它就需要包含其他元素，也就是它想要表达一个东西必须通过子元素来表达。所有要设置的值是通过属性，而不是一个元素的字符值。

 

同一级别的元素排列是乱序的，比如说<activity>,<provider> and<service>等元素可以任意搭配序列（有一个特殊的，<activity-alias>这个元素，它必须在它要起别名的<activity>后面）

 

属性 从某种角度上来讲，所有的属性都是可选的。然而，必须有些属性被指定，这样才能达到要这个元素的目的。可以用文档做一个向导。对于所有可选的属性，可以看到缺省值或者省略代表的意义。

       和一些属性

 

 

 

android:debuggable 模式在发布时改成false