Android Application component manifest file manifest file node

components and manifest files for Android applications

Android applications are composed of loosely coupled components and are bound together using application manifest; The application manifest describes how each component interacts with them and also specifies application metadata, its hardware and platform requirements, external libraries, and required permissions.

first, the basic structure of the application module

· Activity: The presentation layer of an application. Each UI is implemented through one or more extensions of the activity class. The activity uses fragment and views to lay out and display information, and to respond to user actions.

· Service: An invisible worker in an application. The runtime has no UI to update data sources and activity, trigger notifications, and broadcast intent. Can be used to perform a long-running task, or a task that does not require interaction with the user.

· Content Provider: Shareable persistent data storage (content provider). Used to manage and persist application data, typically interacting with SQL databases. You can either configure your own content provider to allow other applications to access it, or you can access other applications.

· Intent: Message delivery framework. Android uses a lot of intent, service, or broadcast receiver broadcast messages, and requests to perform operations on a particular piece of data.

· Broadcast Receiver:intent Listener (broadcast receiver). You can listen to intent broadcasts that match the specified filtering criteria. It automatically launches the application to respond to a received intent.

· Widget: Visual application components. It is a special variant of broadcast receiver that can be used to create dynamic, interactive application components that users can add to their home screens.

· Notification: It allows signals to be sent to users, but it does not unduly attract their attention or interrupt their current activity. They are the preferred method of attracting user attention when an application is not visible or inactive.

Ii. Introduction of Manifest Documents

Each Android project contains a Manifest file--android manifest.xml, which is stored at the bottom of the project hierarchy. Manifest can define the structure and metadata for using programs and their components and requirements.

Manifest contains the nodes of each activity, Service, Content provider, and broadcast receiver that make up the application, and uses intent Filter and permissions to determine how these components interact with other applications. This file can also specify the metadata (icon, version number, subject, and so on) of the application as well as additional top-level nodes that specify the required security permissions and unit tests, and define hardware, screen, and platform support requirements.

The manifest file has a root manifest tag that has a package attribute that is set as a package. It typically contains a xmls:android property to provide some of the system properties used within the file.

Use the Versioncode property to say that the current version of the application is defined as an integer, and that the number increases each time the version is updated. You can use Versionname to define a public version number that is displayed to the user.

The InstallLocation property is designed to allow programs to be installed on an SD card with a value of preferexternal (preferred external storage) and auto (System-determined). When unspecified, the default is pressed to internal storage. Due to problems with removing or rejecting external storage, the following programs are not suitable for installing to external storage and their consequences:

· Applications with Widget/live wallpaper and Live folder: Widget/live wallpaper and Live folder will be removed from the main screen and may not be available after the reboot of the system.

· Provides an application that does not interrupt service: The program and the services it runs will be stopped and will not be restarted automatically.

· Input engine: Any IME installed to external storage will be disabled. After the external storage is available again, the user must select the IME again.

· Device Manager: Deviceadminreceiver and its management capabilities will be disabled.


manifest file node detailed

First look at the most basic structure of the manifest file:

<manifest xmlns:android= "http://schemas.android.com/apk/res/android"
package= " Com.codingblock.manifesttest "
android:versioncode=" 1 "
android:versionname=" 1.0 "
Android:installloc ation= "Preferexternal" >
<!--... nodes ...-->
</manifest>

The manifest tag contains nodes that define the application build, security settings, test classes, and requirements that make up the application. Here are some manifest child node tags:

· USES-SDK: To run the program correctly, you need to have Minskdversion (default value: 1), Maxsdkversion, and Targetsdkversion properties.

· Uses-configuration: Use this node to specify a combination of each input mechanism supported by the application. It is generally not necessary to include this node, but it is useful for games that require special input control. Here are a few of its properties:

· Reqfivewaynav: True to require the device to have top, bottom, left, and right navigation, and to click the current option. Includes tracking summation D-pad.

· Reqharkeyboard: True when the device has a hardware keyboard.

· Reqkeyboardtype: Specifies that the keyboard type is Nokeys, qwerty, Twelvekey, undefined.

· Reqnavigation: Navigation equipment (value: Nonav, Dpad, trackball, wheel, or undefined).

· Reqtouchscreen: Specifies the required touch-screen input (Notouch, stylus, finger, or undefined).

· Uses-feature:android can be run on a variety of hardware platforms. You can use multiple uses-feature nodes to specify each hardware feature that your application needs to avoid installing to devices that do not contain hardware features. (such as: NFC, Bluetooth, camera, etc.)

· Supports-screens: Used to specify that the application has awakened the design and testing for those screen sizes. When the application supports a device's screen, it is typically laid out using the scaling properties in the layout file provided by the developer. When running on an unsupported device, the system may apply compatibility mode to display the application.

· Supports-gl-texture: Used to declare that an application can provide a texture resource compressed in a particular GL texture compression format. If your application is capable of multiple texture compression formats, you must use multiple supports-gl-texture elements.

· Uses-permission: Declares the permissions required for an application.

· Permission: Application components can also create permissions to restrict access to shared application components. (You can use the permission tag to create a permission definition)

· The Instrumentation:instrumentation class provides a test framework for testing application components while the application is running.

· Application: A manifest can contain only one application node. Used to specify various metadata (title, icon, and theme) for an application. At development time, it is recommended that debuggable be set to True to enable debugging, and this property can be disabled at publishing time. The application node contains child nodes such as activity, Service, Content provider, and broadcast receiver. And to manage the state of the application by creating and using its own application class extension.

<application
android:allowbackup= "true"
android:icon= "@drawable/ic_launcher"
Androi        D:label= "@string/app_name"
android:theme= "@style/apptheme"
android:debuggable= "true" >
<!--... nodes ...-->
</application>

The following is a brief introduction to the application child nodes:

· Activity: Each activity of an application requires one of this node and uses the Andorid:name property to specify the name of the activity class. Must contain the core initiation activity and all other activity that can be displayed. Starting an undefined activity throws a Run-time exception. Each activity node can use the Intent-filter child tag to define the intent that is used to start the activity. (When you specify a class name, you can use the "." Replace the package name of the application as a shorthand for the following code:

<activity
android:name= "com.codingblock.manifesttest.MainActivity"
android:label= "@string/app_name" >
<intent-filter>
<action android:name= "Android.intent.action.MAIN"/>
< Category android:name= "Android.intent.category.LAUNCHER"/>
</intent-filter>
</activity>

· Service and activity labels, you need to add a label for each service class used in the application. It also supports run-time binding using the Intent-filter child label.

<service android:name= ". MyService ">
</service>

· Provider: This label is used to specify each content provider in the application. (Content provider is used to manage database access and sharing)

<provider android:name= ". Mycontentprovider "
android:authorities=" Com.codingblock.manifesttest.MyContentProvider ">
</ Provider>

· Receiver: By adding receiver tags, you can register a broadcast receiver without having to start the application in advance. Once registered, it executes immediately whenever a matching intent is broadcast by a system or application. By registering a broadcast Receiver in manifest, the process can be fully autonomous. If a matching intent is broadcast, the application will start automatically and your registered broadcast receiver will start executing. Each receiver node allows the use of Intent-filter child tags to define the intent that can be used to trigger the receiver:

<receiver android:name= ". Myintentreceiver ">
<intent-filter>
<action android:name=" Com.codingblock.manifesttest.MyIn Tentreceiver "/>
</intent-filter>
</receiver>

· Uses-library: Lets you specify the shared libraries that the application needs.