Introducing the 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.
- 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.
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.
The <application> node also acts as a container that includes the Activity, Service, Content Provider, and Broadcast Receiver tags used to specify the application components. You can also define your own implementation of the Application class.
[ ... application nodes ... ]
- activity An <activity> tag is required for every Activity displayed by your application. Using the android:name attribute to specify the Activity class name.
You must include the main launch Activity and any other screen or dialog that can be displayed. Trying to start an Activity that‘s not defined in the manifest will throw a runtime exception. Each Activity node supports <intent-filter> child tags that specify which Intents launch the Activity.
<activity android:name=".MyActivity" android:label="@string/app_name"> <intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" /> </intent-filter>
- Service As with the activity tag, create a new service tag for each Service class used in your application. Service tags also support <intent-filter> child tags to allow late runtime binding.
<service android:enabled="true" android:name=".MyService"></service>
- Provider Provider tags specify each of your application‘s Content Providers. Content Providers are used to manage database access and sharing within and between applications.
- 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.
android:label="My Intent Receiver"
- 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).
- 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 a 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.
<permission android:name="com.paad.DETONATE_DEVICE" android:protectionLevel="dangerous"
android:label="Self Destruct" android:description="@string/detonate_description"> </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.
To use the Manifest Editor in Eclipse, right-click the AndroidManifest.xml file in your project folder and select Open With . . . ➪ Android Manifest Editor. This presents the Android Manifest Overview screen. This screen gives you a high-level view of your application structure, enabling you to set your application version information and root level manifest nodes, including <uses-sdk> and <uses-features>. It also provides shortcut inks to the Application, Permissions, Instrumentation, and raw XML screens. Each of the next three tabs contains a visual interface for managing the application, security, and instrumentation (testing) settings, while the last tag (using the manifest‘s file name) gives access to the raw XML.
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.