Introducing the Android Application Manifest

Every application must have an AndroidManifest.xml file (with precisely that name) in its root directory. The manifest file presents essential information about your app to the Android system, information the system must have before it can run any of the app’s code. 

Application Manifest Introduction

You can specify multiple supported configurations, for example, a device with a finger touchscreen, a trackball, and either a QUERTY or twelve-key hardware keyboard, as shown here:

When specifying required configurations be aware that your application won’t be installed on any device that does not have one of the combinations specified. Ideally, you should develop your application to ensure it works with any input configuration, in which case no uses-configuration node is required.

Checkout:-Absolute Layout in Android

- Uses-feature One of the advantages of Android is the wide variety of hardware platforms it runs on. Use multiple uses-feature nodes to specify each of the hardware features your application requires. This will prevent your application from being installed on a device that does not include a required hardware feature. You can require support for any hardware that is optional on a compatible device. Currently, optional hardware features include:
- android.hardware.camera For applications that require camera hardware.
- android.hardware.camera.autofocus If you require an autofocus camera
- Exact dimensions will vary depending on hardware, but in general the supported screen sizes match resolutions as follows:
- smallScreens Screens with a resolution smaller than traditional HVGA—typically QVGA screens.
- normalScreens Used to specify typical mobile phone screens of at least HVGA, including WVGA and WQVGA.
- largeScreens Screens larger than normal. In this instance, a large screen is considered to be significantly larger than a mobile phone display.
- anyDensity Set to true if your application can be scaled to accommodate any screen resolution.

If you would like to Enrich your career with an Android certified professional, then visit Mindmajix - A Global online training platform:  “Android training”  Course.  This course will help you to achieve excellence in this domain.

Where possible you should optimize your application for different screen resolutions and densities using the resources folder. If you specify a supports-screen node that excludes certain screen sizes, your application will not be available to be installed on devices with unsupported screens.

application A manifest can contain only one application node. It uses attributes to specify the metadata for your application (including its title, icon, and theme). During development, you should include a debuggable attribute set to true to enable debugging—though you may wish to disable this on your release builds.

- Receiver By adding a receiver tag, you can register a Broadcast Receiver without having to launch your application first. Broadcast Receivers are like global event listeners that, once registered, will execute whenever a matching Intent is broadcast by the system or an application. By registering a Broadcast Receiver in the manifest, you can make this process entirely autonomous. If a matching Intent is broadcast, your application will be started automatically and the registered Broadcast Receiver will be run.

- Uses-permission As part of the security model, uses-permission tags declare the permissions you‘ve determined. Your application needs to operate properly. The permissions you include will be presented to the user before installation commences. Permissions are required for many of the native Android services, particularly those with a cost or security implication (such as dialing, receiving SMS, or using the location-based services).

                                                     Checkout Android Interview Questions

- Permission Third-party applications can also specify permissions before providing access to shared application components. Before you can restrict access to an application component, you need to define permission in the manifest. Use the permission tag to create a permission definition.

Application components can then require permissions by adding the android: permission attribute. Other applications will then need to include a uses-permission tag in their manifests to use these protected components.

Within the permission tag, you can specify the level of access the permission will permit (normal, dangerous, signature, signatureOrSystem), a label, and an external resource containing the description that explains the risks of granting the specified permission.
 
The ADT New Project Wizard automatically creates a new manifest file when it creates a new project.

Using the Manifest Editor

The ADT plug-in includes a visual Manifest Editor so you don‘t have to manipulate the underlying XML directly.

Android Application Lifecycle

Android applications have limited control over their own life cycles. Instead, application components must listen for changes in the application state and react accordingly, taking particular care to be prepared for untimely termination.
By default, each Android application runs in its own process, each of which is running a separate instance of DALVIK. Memory and process management is handled exclusively by the run time.
While it’s uncommon, it’s possible to force application components within the same application to run in different processes or to have multiple applications share the same process using the android:process attribute on the affected component nodes within the manifest.