Androidmanifest.xml of Android (i)

Before Android launches an application component, it must know which components are present, so the developer must "declare" the components that appear in the application in the Androidmanifest.xml file as part of the development process. Eventually the Androidmanifest.xml file will be packaged together into the. apk file.

The four components of Android are:Activity,broadcast receiver,service,Content Provider, So if these components are used in the program, be sure to "declare" them in the Androidmanifest.xml file, or the Android application will be running with an error when it needs to jump to, or need to use the component: not found.

This manifest file is in XML as a structural format, and for all applications, it is called Androidmanifest.xml. To declare an application component, it also does a lot of extra work, such as specifying the name of the library that the application needs to link to (in addition to the default Android library) and declaring the various permissions that the application expects to get.

         But the main function of the manifest file is still to declare the application's components to Android. The following is a standard example of a androidmanifest.xml file:

<?xml version= "1.0" encoding= "Utf-8"?><manifest> <!--basic configuration--<uses-permission/> <pe Rmission/> <permission-tree/> <permission-group/> <instrumentation/> <uses-sdk/&G    T <uses-configuration/> <uses-feature/> <supports-screens/> <compatible-screens/> &L        T;supports-gl-texture/> <!--app configuration-<application> <!--Activity configuration-                <activity> <intent-filter> <action/> <category/>                <data/> </intent-filter> <meta-data/> </activity> <activity-alias> <intent-filter> ... </intent-filter> <meta-data /> </activity-alias> <!--Service configuration--<service> <intent -filter> ...</intent-filter> <meta-data/> </service> <!--Receiver configuration- <receiver> <intent-filter> </intent-filter> <meta-data/> & lt;/receiver> <!--Provider configuration-<provider> <grant-uri-permission/&G            T <meta-data/> </provider> <!--required class library configuration-<uses-library/> </ap Plication></manifest>

From the sample code above, you can see that the Android configuration file takes XML as the description language, each XML tag has a different meaning, and most of the configuration parameters are placed in the attributes of the tag.

Use of each label:

[1]<manifest>...</manifest>: is the root element of the Androidmanifest.xml configuration file and must contain a <application> element and specify the Xlmns:android and package properties.

(1) Xlmns:android: Specifies the Android namespace, which by default is "Http://schemas.android.com/apk/res/android";

(2) Package: is the standard application pack name, is also the default name of an application process;

(3) Android:versioncode: is for the device program to identify the version used, must be an integer value on behalf of the app updated how many times;

(4) Android:versionname: It is for users to view the version used, need to have a certain readability, such as "1.0.0" such.

[2]<uses-permission/>

       to ensure the security of Android applications, the application framework has developed a more restrictive system of permissions, An app must declare the correct permissions to use the appropriate functionality. <uses-permission> is our most frequently used permission setting tag, we declare the corresponding permission name related code by setting the Android:name property as follows.

 <!--network-related functions-<uses-permission android:name= "Android.permission.IN Ternet "/>//Allow network access 
 <uses-permission android:name=" Android.permission.ACCESS_NETWORK_STATE "/>//Allow network data Get <uses-permission android:name= "Android.permission.ACCESS_COARSE_LOCATION"/> <uses-permission android:n Ame= "Android.permission.ACCESS_FINE_LOCATION"/> <!--read phone status--<uses-permission android:name= "Android. Permission. Read_phone_state "/> <!--notifications Related features-<uses-permission android:name=" Android.permission.VIBRATE "/> 
     <!--read/write SD card file--> 
     <uses-permission android:name= " Android.permission.WRITE_EXTERNAL_STORAGE "/> 
 <!--allow the use of camera--> 
     < Uses-permission android:name= "Android.permission.CAMERA"/> 

[3]<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. It can also be used in conjunction with <permission-group> and <permission-tree> to construct a more hierarchical, more targeted permission system. <

(1) Android:name: Permission name label;

(2) Android:icon: Permission icon;

(3) Android:description: attributes such as permission descriptions.

Examples of <permission> tag syntax are:

<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"]/>

[4]<instrumentation/>

used to declare the instrumentation test class to monitor the behavior of Android apps and apply them to related functional tests. 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.

(1) Android:functionaltest: test function switch;

(2) android:handleProfiling:profiling debugging function switch;

(3) Android:targetpackage: Test Case target object.

<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"/>

[5]<uses-sdk>

To specify the version of the SDK that you want to use in your Android app, here are the syntax examples.

    android:minsdkversion= "integer"    //Minimum version number    android:targetsdkversion= "integer"    //target version number    Android: maxsdkversion= "Integer"    
    />

[6]<uses-configuration> and <uses-feature>

&NBSP;        Both tags are used to describe the hardware and software features required by the application, To prevent applications 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.

    Android:reqfivewaynav=["true" | "false"]     android:reqhardkeyboard=["true" | "false"]    android:reqkeyboardtype=["undefined" | "Nokeys" | "QWERTY" | "Twelvekey"]    android:reqnavigation=["undefined" | "Nonav" | "Dpad" | "Trackball" | "Wheel"]    
    Android:name= "string"    android:required=["true" | "false"]    android:glesversion= "integer"/>

[7]<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.

    Android:name= "string"    //class name    android:required=["true" | "False"]/>

Note: When running a Java program, the JVM (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.

[8]<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.
The syntax examples of <supports-screens> tags are as follows:

    Android:resizeable=["true" | "false"]    //Adaptive screen    android:smallscreens=["true" | "false"]    //small screen    android:normalscreens=["true" | "false"]   //Medium screen    android:largescreens=["true" | "false"]    //Large screen    android:xlargescreens=["true" | "False"    ///Mega screen    android:anydensity=["true" | "False"    //Screen-rendered image    android:requiressmallestwidthdp= "integer"    //min. screen width    android: compatiblewidthlimitdp= "integer"    android:largestwidthlimitdp= "integer"/>

[9]<application>

The root element of the application configuration, located in the <manifest> lower layer, contains all the elements that apply to the configuration, and its properties can be the default properties of the child elements, affecting all components under the app. Many properties set a default value for the component. Some properties set global values and cannot be modified by the component.

The following are syntax examples:

<application android:allowclearuserdata=["true" | "false"] android:allowtaskreparenting=["true" | "false"] android:backupagent= "string" android:debuggable=["true" | "false"] android:description= "string resource" android:enabled=["true" | "false"] android:hascode=["true" | "false"] android:icon= "drawable resource" android:killafterrestore=["true" | "false"] android:label= "string 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" > ... </app Lication> 

(1) Android:allowclearuserdata: Whether to give users permission to delete user data, [True|false].

(2) Android:allowtaskreparenting: Whether the application-defined activities can be transferred from the task initiated to the task that he has the same and will be brought to the foreground, [True|false].

(3) Android:backupagent: The class name of the backup agent that implements the application, the subclass of the backupagent. The name of this property should be the fully qualified class name (for example, "Com.project.MyBackupAgent").

However, if the first letter of the name is set to a point number, it can also be a class name (for example, ". Myandroid "), he will be appended to the package name defined in the <manifest> element. There is no default value.

(4) Android:debuggable: Whether the application can use debug, or even run in user mode, [True|false].

(5) Android:description: User-readable, longer and more application-specific descriptions than application tags. This value must be a reference string. Unlike tags, he cannot be set to hard-coded strings. There is no default value.

(6) Whether the android:enabled:Android system can instantiate the application's components, [True|false]. If true, the Enabled property of each component determines whether the component is available. If False, he overrides the component's specified value, and all components will not be available. The default is true.

(7) Android:hascode: Whether the app contains code, [True|false]. When the value is False, the startup component is any code that the system does not try to load the app. The default is true.

(8) Android:icon: The icon for the entire app, or the default icon for each component. This property value must be set to a reference to the drawable resource. There is no default value.

(9) Android:killafterrestore: In performing a system reset operation, the application should be terminated when his settings are reset. The reset operation of a single package does not cause the app to be closed. The recovery operation of the entire system is representative only once, when the change is set for the first time. This property will not be used frequently by third-party apps. The default value is true, meaning that when the entire system is restored, the application finishes running his data and terminates.

Android:label: An easy-to-read app tag, and is also the default label for each component of the app. This tag should be set to reference string resources, and of course he can be like other strings in the user

specified in the interface. When you apply development, you can set an undefined string.

(one) Android:managespaceactivity: The fully qualified name of an activity subclass that can be initiated by the system to allow the user to manage the storage space that the app occupies. This activity should also be declared with the <activity> element.

Android:name: The fully qualified name of the application subclass that is implemented for this application. When the app starts, the class will be instantiated before other components of the app. This subclass is optional, and most applications do not. By default, Android uses an instance of the base application class.

Android:permission: The name of the license that the user must set in order to interact with the app. This property is a convenient way to set the license for the app's components. He can be overridden by the component's Permission property.

Android:persistent: Whether the app remains running at all times, [True|false]. The default is False. Typically, this identity should not be set. Persistent mode is only specified by several system applications.

(android:process): Set a running process name for the component under application. Each component can define its own process name by setting its own processes property. By default, when the first component of an app needs to run, Android creates a process for the app. All components run under the same process. The name of this process is the same as the Backage property name set in the <manifest> element.

By setting this property to be shared in other apps, you can coordinate the application's components to run in the same process, but only two apps also share the user ID and sign the same certificate.

If the name of this property starts with a colon (":"), a new private process will be created. If the name of a process starts with a lowercase letter, a common process is created. A common process can be shared by other applications to reduce the use of resources.

Android:restoreanyversion: Indicates that the application is ready to attempt to recover all of the backup data sets, even if the backup data is stored with a number higher than the currently installed application. Setting to True will allow the backup manager to try to recover when the version mismatch means that the data conflicts. Use carefully. The default is False.

Android:taskaffinity: Provides a similar name to all components under the application, in addition to the components that set their own taskaffinity properties. By default, all components use the same affinity. The name of the affinity is the same as the package name set in the <manifest> element.

Android:theme: Defines a topic that references a style resource for the component under application. The activity can also set its own theme by setting its own theme property.

Androidmanifest.xml of Android (i)