Androidmanifest.xml configuration file Detailed

<manifest>

The root element of the Androidmanifest.xml configuration file must contain a <application> element and specify the Xlmns:android and package properties. xlmns:android Specifies the Android namespace, which by default is "Http://schemas.android.com/apk/res/android", while the package is the standard app bundle name and the default name for an app process , in this book microblogging application example of the package name, that is, "Com.app.demos" is a standard Java application package name, in order to avoid namespace conflicts, the application domain name is generally used as the package name. Of course, there are some other commonly used properties to note, such as Android:versioncode is for the device program to identify the version used, must be an integer value on behalf of the app to update the number of times, while the Android:versionname is for users to view the version, Need to have some readability, such as "1.0.0". <manifest> tag syntax examples are as follows.

<manifest xmlns:android= "Http://schemas.android.com/apk/res/android"
Package= "string"
Android:shareduserid= "string"
Android:shareduserlabel= "String Resource"
Android:versioncode= "Integer"
Android:versionname= "string"
android:installlocation=["Auto" | "Internalonly" | "Preferexternal"] >
... ...
</manifest>

<uses-permission>

In order to ensure the security of Android applications, the application framework has established a more stringent authority system, an application must declare the correct permissions to use the corresponding functions, for example, we need to enable the application to access the network needs to configure "Android.permission.INTERNET", If you want to use the device's camera function, you need to set up "Android.permission.CAMERA" and so on. <uses-permission> is our most frequently used permission to set the label, we set the Android:name property to declare the corresponding permission name, such as in the microblog application example, we are based on the application of the required functions to declare the corresponding permissions, the relevant code is as follows.

<manifest ...>
... ...
<!--network-related features-
<uses-permission android:name= "Android.permission.INTERNET"/>
<uses-permission android:name= "Android.permission.ACCESS_NETWORK_STATE"/>
<uses-permission android:name= "Android.permission.ACCESS_COARSE_LOCATION"/>
<uses-permission android:name= "Android.permission.ACCESS_FINE_LOCATION"/>
<!--read phone status--
<uses-permission android:name= "Android.permission.READ_PHONE_STATE"/>
<!--notifications about features--
<uses-permission android:name= "Android.permission.VIBRATE"/>
... ...
</manifest>

<permission>

The permission Declaration label, which defines the specific permissions of the supply <uses-permission> use, usually we do not need to declare a permission for our own application, unless we need to provide callable code or data to other applications, this time you need to use < permission> tags. This tab provides attributes such as Android:name permission name tags, permission icon android:icon, and permission Description android:description, plus <permission-group> and < Permission-tree> is used to construct a more hierarchical, more targeted permission system. <permission> tag syntax examples are as follows.

<permission android:description= "string resource"
android:icon= "Drawable Resource"
Android:label= "String Resource"
Android:name= "string"
Android:permissiongroup= "string"
android:protectionlevel=["Normal" | "Dangerous" | "Signature" | "Signatureorsystem"]/>

<instrumentation>

Used to declare the instrumentation test class to monitor the behavior of Android apps and apply them to related functional tests where the more important attributes are: Test function switch Android:functionaltest, Profiling debug Function Switch android:handleprofiling, test case target object Android:targetpackage and so on. In addition, it is important to note that the instrumentation object is instantiated before the component of the application, which needs to be considered when organizing the test logic. <instrumentation> tag syntax examples are as follows.

<instrumentation android:functionaltest=["true" | "False"]
Android:handleprofiling=["true" | "False"]
android:icon= "Drawable Resource"
Android:label= "String Resource"
Android:name= "string"
Android:targetpackage= "string"/>

<uses-sdk>

To specify the version of the SDK that you need to use in your Android app, for example, our app must be running on Android version 2.0 or above, then you need to specify that the app supports a minimum SDK version number of 5, and of course, each SDK version will have a specified integer value corresponding to it. For example, our most commonly used Android 2.2.x version number is 8. Of course, in addition to specifying the minimum version, the,<uses-sdk> tag can also specify the highest and target versions, with the following syntax examples.

&LT;USES-SDK android:minsdkversion= "Integer"
android:targetsdkversion= "Integer"
android:maxsdkversion= "integer"/>

<uses-configuration> and <uses-feature>

Both tags are used to describe the hardware and software features required by the application to prevent the application from being installed on devices that do not have these features. <uses-configuration> tags, such as some devices with D-pad or trackball these special hardware, then the Android:reqfivewaynav property needs to be set to True , and if there are some devices with a hardware keyboard, Android:reqhardkeyboard also needs to be set to true. In addition, if the device needs to support Bluetooth, we can use the <uses-feature android:name= "Android.hardware.bluetooth"/> to support this feature. These two tags are mainly used to support the application of some special devices, the syntax examples of two tags are as follows.

<uses-configuration android:reqfivewaynav=["true" | "False"]
Android:reqhardkeyboard=["true" | "False"]
android:reqkeyboardtype=["Undefined" | "Nokeys" | "QWERTY" | "Twelvekey"]
android:reqnavigation=["Undefined" | "Nonav" | "Dpad" | "Trackball" | "Wheel"]
android:reqtouchscreen=["Undefined" | "Notouch" | "Stylus" | "Finger"]/>

<uses-feature android:name= "string"
Android:required=["true" | "False"]
android:glesversion= "integer"/>

<uses-library>

Used to specify the user libraries that Android apps can use, in addition to the system's own Android.app, Android.content, Android.view and Android.widget These default class libraries, some applications may require some other Java class libraries as support, in which case we can use <uses-library> tags let classloader load their class libraries for Android apps to run. The usage of the <uses-library> tag is simple, the following is a syntax example.

<uses-library android:name= "string"
Android:required=["true" | "False"]/>

Tips :
When running a Java program, the JVM (the Java Virtual machine) is run first, and then the Java class is loaded into the JVM, which is called ClassLoader, which is responsible for loading the Java class. Of course, ClassLoader is made up of multiple parts, each of which is responsible for the corresponding loading work. When running a program, the JVM starts, runs Bootstrapclassloader, and the ClassLoader loads the Java Core API (Extclassloader and Appclassloader are also loaded at this time), Then call Extclassloader to load the extension API, and finally Appclassloader load the class defined in the Classpath directory, which is the most basic loading process for a Java program.

<supports-screens>

For some apps or games, a device that supports only certain screen sizes, or if it works better on some devices, we use the <supports-screens> tag to specify the supported screen features. Some of the more important properties include: Screen Adaptive properties android:resizeable, small screen (android:smallscreens), Medium screen (android:normalscreens), large screen (android: Largescreens) and Mega screen (Android:xlargescreens) Support properties, render image properties by screen android:anydensity and minimum screen width properties for Android: REQUIRESSMALLESTWIDTHDP and so on. The syntax examples for <supports-screens> tags are as follows.

<supports-screens android:resizeable=["true" | "False"]
Android:smallscreens=["true" | "False"]
Android:normalscreens=["true" | "False"]
Android:largescreens=["true" | "False"]
Android:xlargescreens=["true" | "False"]
Android:anydensity=["true" | "False"]
android:requiressmallestwidthdp= "Integer"
android:compatiblewidthlimitdp= "Integer"
android:largestwidthlimitdp= "integer"/>

<application>

The root element of the application configuration, located in the <manifest> lower layer, contains all the elements related to the application configuration, whose properties can be used as the default properties for child elements, commonly used properties include: App name Android:label, app icon Android:icon, Apply Theme Android:theme and so on. Of course,<application> tag also provides other rich configuration properties, because of the length of the reason is not listed, you can open the Android SDK documentation to further study, the following is a syntax example.

<application android:allowtaskreparenting=["true" | "False"]
Android:backupagent= "string"
Android:debuggable=["true" | "False"]
Android:description= "String Resource"
Android:enabled=["true" | "False"]
Android:hascode=["true" | "False"]
Android:hardwareaccelerated=["true" | "False"]
android:icon= "Drawable Resource"
Android:killafterrestore=["true" | "False"]
Android:label= "String Resource"
android:logo= "Drawable Resource"
Android:managespaceactivity= "string"
Android:name= "string"
Android:permission= "string"
Android:persistent=["true" | "False"]
Android:process= "string"
Android:restoreanyversion=["true" | "False"]
Android:taskaffinity= "string"
Android:theme= "resource or Theme" >
... ...
</application>

<activity>

The declaration label of the activity component (that is, the interface controller component), each activity in the Android app must be declared in the Androidmanifest.xml configuration file, or the activity will not be recognized or executed by the system. The properties commonly used in <activity> tags are: activity corresponding class name android:name, corresponding theme Android:theme, loading mode android: Launchmode (see section 2.1.3.4), keyboard interaction mode Android:windowsoftinputmode, and other property usage you can refer to the Android SDK documentation learning. In addition, the,<activity> tag can contain <intent-filter> elements for message filtering, as well as the <meta-data> elements that can be used to store predefined data, as follows <activity Syntax examples for > tags.

<activity android:allowtaskreparenting=["true" | "False"]
Android:alwaysretaintaskstate=["true" | "False"]
Android:cleartaskonlaunch=["true" | "False"]
android:configchanges=["MCC", "MNC", "locale",
"Touchscreen", "keyboard", "Keyboardhidden",
"Navigation", "orientation", "screenlayout",
"Fontscale", "Uimode"]
Android:enabled=["true" | "False"]
Android:excludefromrecents=["true" | "False"]
Android:exported=["true" | "False"]
Android:finishontasklaunch=["true" | "False"]
Android:hardwareaccelerated=["true" | "False"]
android:icon= "Drawable Resource"
Android:label= "String Resource"
android:launchmode=["multiple" | "Singletop" | "Singletask" | "SingleInstance"]
Android:multiprocess=["true" | "False"]
Android:name= "string"
Android:nohistory=["true" | "False"]
Android:permission= "string"
Android:process= "string"
android:screenorientation=["Unspecified" | "User" | "Behind" |
"Landscape" | "Portrait" |
"Sensor" | "Nosensor"]
Android:statenotneeded=["true" | "False"]
Android:taskaffinity= "string"
Android:theme= "Resource or theme"
android:windowsoftinputmode=["Stateunspecified",
"Stateunchanged", "Statehidden",
"Statealwayshidden", "statevisible",
"Statealwaysvisible", "adjustunspecified",
"Adjustresize", "Adjustpan"] >
... ...
</activity>

<activity-alias>

The declaration label of the activity component alias is simply a shortcut to the activity, and the attribute android:targetactivity represents its associated activity name, which must, of course, be a previously declared activity. In addition, other more common attributes are: Activity alias name Android:name, alias switch android:enabled, permission control android:permission, etc. In addition, we also need to note that the activity alias is also a separate activity, you can have their own <intent-filter> and <meta-data> elements, the syntax of the following examples.

<activity-alias android:enabled=["true" | "False"]
Android:exported=["true" | "False"]
android:icon= "Drawable Resource"
Android:label= "String Resource"
Android:name= "string"
Android:permission= "string"
Android:targetactivity= "string" >
... ...
</activity-alias>

<intent-filter> <action>, <category>, <data>

<intent-filter> declarations for Intent message filters, In the previous section 2.1.3.2 We have described in more detail the intent messages in the Android application framework, and we have learned that intent messages are a very important "binder" for Android applications <intent-filter > elements can be placed in <activity>, <activity-alias>, <service>, and <receiver> element tags to differentiate between activity controllers that can be used to process messages , service services, and broadcast receivers broadcast receiver. In addition, we know that the intent message also contains several important attributes, such as name, action, data, category, and so on. This is also related to the notation of the label, such as <intent-filter> must contain a <action> element, that is, the name used to describe the specific message;<category> tag is used to represent the class that can handle the message component, The category that the action conforms to, while the <data> element is used to describe the data format that the message needs to process, and we can even use regular expressions to qualify the data source. Of course, we need to learn more about the specifics of these elements and tags, and here are the syntax examples for standard <intent-filter> element tags.

<intent-filter android:icon= "drawable resource"
Android:label= "String Resource"
android:priority= "integer" >
<action android:name= "string"/>
<category android:name= "string"/>
<data android:host= "string"
Android:mimetype= "string"
Android:path= "string"
Android:pathpattern= "string"
android:pathprefix= "string"
Android:port= "string"
Android:scheme= "string"/>
</intent-filter>

<meta-data>

Used to store predefined data, and <intent-filter> similar,<meta-data> can also be placed in <activity>, <activity-alias>, <service > and <receiver> in these four element tags. Meta data is typically in the form of a key-value pair, with no limit on the number of data that will be placed in a bundle object, and we can use Activityinfo, ServiceInfo even read from the metadata property of the ApplicationInfo object. Let's say we define an <meta-data> element in an activity, and the example usage is as follows.

<activity...>
<meta-data android:name= "TestData" android:value= "Test meta data" ></meta-data>
</activity>

Activityinfo info = This.getpackagemanager ()
. Getactivityinfo (Getcomponentname (), packagemanager.get_meta_data);
String testData = info.metaData.getString ("TestData");
System.out.println ("TestData:" + testData);

<service>

The Service service component's claim label, used to define and describe a specific Android service, the main attributes are: Service class name Android:name, service icon Android:icon, Services description Android: Label and service Switch android:enabled, etc. For the concept and usage of service component, please refer to section 2.1.4.2, below is a syntax example of the <service> tag.

<service android:enabled=["true" | "False"]
Android:exported=["true" | "False"]
android:icon= "Drawable Resource"
Android:label= "String Resource"
Android:name= "string"
Android:permission= "string"
Android:process= "string" >
... ...
</service>

<receiver>

The Boardcast receiver broadcast receiver component's declaration label, used to define and describe a specific Android broadcast receiver, whose main properties and <service> tags are somewhat similar: boardcast Receiver Receiver class name Android:name, receiver icon Android:icon, receiver description Android:label and receiver switch android:enabled, etc. For the concept and usage of the Boardcast receiver broadcast receiver component, please refer to the contents of section 2.1.4.3, below is a syntax example of the <receiver> tag.

<receiver android:enabled=["true" | "False"]
Android:exported=["true" | "False"]
android:icon= "Drawable Resource"
Android:label= "String Resource"
Android:name= "string"
Android:permission= "string"
Android:process= "string" >
... ...
</receiver>

<provider> and <grant-uri-permission>

Another "Four components" other than activity, service, and Boardcast receiver, which is the claims label of the content provider of the provider. For the concept and usage of the content provider component, please refer to section 2.1.4.4 For more details. <provider> tags, in addition to the same basic properties as Android:name, Android:icon, and Android:label for other components, provide special properties to support their functionality, such as: Content provider identity name Android : Authorities, granting permissions to the specified URI identity android:granturipermission and specific read, write permissions, namely Android:readpermission and android:writepermission, and so on. Of course, we need to learn more about the specifics of these properties, and here are the syntax examples for <provider> tags.

<provider android:authorities= "List"
Android:enabled=["true" | "False"]
Android:exported=["true" | "False"]
Android:granturipermissions=["true" | "False"]
android:icon= "Drawable Resource"
Android:initorder= "Integer"
Android:label= "String Resource"
Android:multiprocess=["true" | "False"]
Android:name= "string"
Android:permission= "string"
Android:process= "string"
Android:readpermission= "string"
Android:syncable=["true" | "False"]
android:writepermission= "string" >
... ...
</provider>

<?xml version="1.0"encoding="Utf-8"?> <manifest> <!--basic configuration-<uses-permission/> <permission/> <per Mission-tree/> <permission-group/> <instrumentation/> <uses-sdk/> <uses-co Nfiguration/> <uses-feature/> <supports-screens/> <compatible-screens/> <s Upports-gl-texture/> <!--application Configuration-<application> <!--Activity configuration-- > <activity> <intent-filter> <action/> <c          ategory/> <data/> </intent-filter> <meta-data/> </activity> <activity-alias> <intent-filter> </intent-filter&              Gt        <meta-data/> </activity-alias> <!--Service configuration-<service>       <intent-filter> ... </intent-filter> <meta-data/> </service> <!--Receiver configuration-<receiver> <intent-filter> ... </intent-fil          ter> <meta-data/> </receiver> <!--Provider configuration--                    <provider> <grant-uri-permission/> <meta-data/> </provider>  <!--required class library configuration-<uses-library/> </application> </manifest>

Androidmanifest.xml configuration file Detailed