Scribd
Upload
90 views5 pages

The Manifest File

The Android manifest file defines the structure and metadata of an Android app including its components, requirements, and how they interact. The manifest includes nodes for activities, services, providers, receivers and their filters and permissions as well as app metadata and requirements.

Uploaded by

nithiyapriya
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
90 views5 pages

The Manifest File

The Android manifest file defines the structure and metadata of an Android app including its components, requirements, and how they interact. The manifest includes nodes for activities, services, providers, receivers and their filters and permissions as well as app metadata and requirements.

Uploaded by

nithiyapriya
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

The Manifest File

 Every project in Android includes a manifest file, which


is AndroidManifest.xml, stored in the root directory of its project hierarchy.
 The manifest file is an important part of our app because it defines the
structure and metadata of our application, its components, and its
requirements.
 This file includes nodes for each of the Activities, Services, Content Providers,
and Broadcast Receiver that make the application and using Intent Filters and
Permissions determines how they co-ordinate with each other and other
applications.
 The manifest file also specifies the application metadata, which includes its
icon, version number, themes, etc., and additional top-level nodes can specify
any required permissions, unit tests, and define hardware, screen, or platform
requirements.
 The manifest comprises a root manifest tag with a package attribute set to the
project’s package.
 It should also include an xmls:android attribute that will supply several
system attributes used within the file.
 We use the versionCode attribute is used to define the current application
version in the form of an integer that increments itself with the iteration of the
version due to update.
 Also, the versionName attribute is used to specify a public version that will be
displayed to the users.
 We can also specify whether our app should install on an SD card of the
internal memory using the installLocation attribute.
 A typical manifest node looks as:

<manifest xmlns:android="http://schemas.android.com/apk/res/android"

package="com.paad.myapp"

android:versionCode="1"

android:versionName="0.9 Beta"
android:installLocation="preferExternal">

[....manifest nodes....]

</manifest>

 A manifest file includes the nodes that define the


1. application components,
2. security settings,
3. test classes, and
4. requirements that make up the application.
 Some of the manifest sub-node tags that are mainly used are:
1. Uses-sdk
2. Uses-configuration
3. Uses-features
4. Supports-screens

1. uses-sdk
It is used to define a minimum and maximum SDK version that must be available on
a device so that our application functions properly, and target SDK for which it has
been designed using a combination of minSdkVersion, maxSdkVersion, and
targetSdkVersion attributes, respectively.

<uses-sdk android:minSdkVersion=”6”

android:targetSdkVersion=”15”/>

2. uses-configuration
The uses-configuration nodes are used to specify the combination of input
mechanisms that are supported by our application. It is useful for games that require
particular input controls.

<uses-configuration android:reqTouchScreen=”finger”
android:reqNavigation=”trackball”

android:reqHardKeyboard=”true”

android:reqKeyboardType=”qwerty”/>

<uses-configuration android:reqTouchScreen=”finger”

android:reqNavigation=”trackball”

android:reqHardKeyboard=”true”

android:reqKeyboardType=”twelvekey”/>

3. uses-features
 It is used to specify which hardware features your application requirement.
 This will prevent our application from being installed on a device that does not
include a required piece of hardware such as NFC hardware, as follows:

<uses-feature android:name=”android.hardware.nfc”/>

4. supports-screens
It is used to describe the screen support for our application:

<supports-screens

android:smallScreens=”false”

android:normalScreens=”true”

android:largeScreens=”true”
android:xlargeScreens=”true”/>

5. permission
 It is used to create permissions to restrict access to shared application
components.
 We can also use the existing platform permissions for this purpose or define
your own permissions in the manifest.

<permission

android: name=”com.paad.DETONATE_DEVICE”

android:protectionLevel=“dangerous”

android:label=”Self Destruct”

android:description=”@string/detonate_description”>

</permission>

6. 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, we should include a debuggable attribute set to true to
enable debugging, then be sure to disable it for your release builds.
 The application node also acts as a container for the Activity, Service, Content
Provider, and Broadcast Receiver nodes that specify the application
components.
 The name of our custom application class can be specified using the
android:name attribute.

<application
android:icon="@drawable/icon"

android:logo-"@drawable/logo"

android:theme="@android:style/Theme.Light"

android:name=".MyApplicationClass"

android:debuggable="true">

[....application nodes.....]

</application>

You might also like