Manifest. xml for Android Development

Each Android project contains a Manifest file, AndroidManifest. xml, which is stored at the bottom of the project level. A list can define the structure and metadata of an application and its components. It contains nodes that comprise every component of an application (activity, service, content provider, and broadcast receiver, use Intent filters and permissions to determine how these components interact with other applications. It also provides various attributes to describe the metadata of an application (such as its icons or themes) and additional availability for security settings and unit testing of top-level nodes, as described below. A list consists of a root manifest label with a package attribute for setting the project package. It usually contains an xmlns: android attribute to provide certain system attributes used in the file. The following XML code snippet shows a typical declaration node: Java code: 1 <manifest xmlns: android = http://schemas.android.com/apk/res/android package = "com. my_domain.my_app "> [... manifest nodes...] </manifest> the manifest tag contains nodes that define application components, security settings, and test classes that comprise applications. Some common manifest node labels are listed below, and some XML code segments are used to illustrate how they are used. An application List can contain only one application node. It uses various attributes to specify various metadata (including titles, icons, and themes) of the application ). It can also be used as a container that contains activities, services, content providers, and broadcast receiver tags to specify application components. Java code: 1 <application android: icon = "@ drawable/icon" 2 android: theme = "@ style/my_theme"> [... application nodes...] </application> each activity displayed by the Activity application requires an activity tag and uses the android: name attribute to specify the class name. This must contain the core startup Activity and all other screens or dialogs that can be displayed. When you start any Activity that is not defined in the list, a runtime exception is thrown. Each Activity node allows the intent-filter sub-tag to specify which Intent to start the Activity. Java code: 1 <activity android: name = ". myActivity "2 android: label =" @ string/app_name "> 3 <intent-filter> 4 <action5android: name =" android. intent. action. MAIN "/> 6 <category7android: name =" android. intent. category. LAUNCHER "/> 8 </intent-filter> 9 </activity> provider label is used to describe every content provider in the application. The content provider is used to manage database access and share data within and between programs. Chapter 1 will detail it. Java code: 1 <service androidandroid: enabled = "true" android: name = ". MyService"> </service> the provider tag describes each content provider in the application. The content provider is used to manage database access and share data within and between programs. Chapter 1 will detail it. Java code: 1 <provider2android: permission = "com. paad. MY_PERMISSION "3 android: name = ". myContentProvider "4 android: enabled =" true "5 android: authorities =" com. paad. myapp. myContentProvider "> 6 </provider> by adding the receiver tag, the receiver can register a Broadcast Receiver without starting the application beforehand. The broadcast receiver is like a global event listener. Once registered, it is immediately executed whenever the intent that matches it is broadcast by the application. By registering a broadcast receiver in the Declaration, this process can be fully automated. If a matched Intent is broadcast, the application starts automatically and the broadcast receiver you register starts to run. Java code: 1 <receiver2android: enabled = "true" android: label = "My Broadcast guest Er" android: name = ". myBroadcastReceiver "> 3 </javaser> uses-permission is part of the security model. The uses-permission label declares the permissions defined by you, these permissions are required for normal application execution. When installing the program, all the permissions you set will be told to the user, and they will decide whether to agree or not. Permissions are required for many local Android services, especially those services that require payment or security issues (such as dialing, receiving SMS, or using location-based services ). As shown below, third-party applications, including your own applications, can also specify permissions before providing access to shared program components. Java code: 1 <uses-permission android: name = "android. permission. ACCESS_LOCATION "> </uses-permission> before you can restrict access to an application component, you must define a permission in the list. You can use the permission label to create these permission definitions. Then, the application component can require these permissions by adding the android: permission attribute. Then, other applications need to include the uses-permission tag (and be authorized) in their lists before using these protected components. In the permission label, you can specify the permitted access permission levels (normal, dangerous, signature, signatureOrSystem), a label attribute, and an external resource in detail, this external resource should contain a description of the risk of granting this permission. Java code: 1 <permission2android: name = "com. paad. DETONATE_DEVICE "3 android: protectionLevel =" dangerous "4 android: label =" Self Destruct "5 android: description = "@ string/detonate_description"> 6 </permission> the instrumentation class provides a framework for running a test on an activity or service when an application is running. They provide methods to monitor applications and their interaction with system resources. A new node is required for each test class created for your application. Java code: 1 <instrumentation2android: label = "My Test" 3 android: name = ". MyTestClass" 4 android: targetPackage = "com. paad. aPackage"> 5 </instrumentation>