It is used to determine applications settings such as
–Application name and version
–what permissions the application requires to run
–what application components it is comprised of
Important information about the application’ identity.
Manifest file is named AndroidManifest.xml
Must be included at the top level of any Android project
The information in this file is used by the Android system to
Install and upgrade the application package.
Display the application details such as the application name, description, and icon to users.
Specify application system requirements, including
–which Android SDKs are supported,
–what hardware configurations are required (for example, d-pad navigation), and
–which platform features the application relies upon (for example, uses multitouch capabilities).
Launch application activities.
Manage application permissions.
Configure other advanced application configuration details, including acting as a service, broadcast receiver, or content provider.
Enable application settings such as debugging and configuring instrumentation for application testing.
Eclipse Manifest File resource editor organizes the manifest information into categories:
–The Manifest tab
–The Application tab
–The Permissions tab
–The Instrumentation tab
–The AndroidManifest.xml tab
Manifest Tab
contains package-wide settings including
–Package name
–Version information
–Supported android SDK
Min SDK version
Target SDK version
Max SDK version.
–Hardware or feature requirement
Application Tab
Contains application-wide settings including
–Application Toggle
–Application Attributes
–Information about application component
Ccontains any permission rules required by application.
–Used to enforce custom permissions for application.
Instrumentation Tab
To declare any instrumentation classes for monitoring the application .
Editing the Manifest File Manually
Generally include a single <manifest> tag with a single <application> tag.
Sample android multimedia application code.
Managing Your Application’s Identity
Android manifest file defines the application properties.
The package name must be defined within the Android manifest file within the <manifest> tag using the package attribute:
<manifest xmlns:android=”http://schemas.android.com/apk/res/android”
package=”com.androidbook.multimedia”
android:versionCode=”1″
android:versionName=”1.0″>
Versioning the application
It is vital to maintaining your application in the field.
Versioning can help reduce confusion and make product support and upgrades simpler
There are two different version attributes defined within the
<manifest> tag:
– The version name and
– The version code.
The version name (android:versionName) is a user-friendly, developer-defined version attribute.
This information is displayed to users when they manage applications on their devices and when they download the application from marketplaces.
Developers use this version information to keep track of their application versions in the field.
The Android operating system uses the version code (android:versionCode) that is a numeric attribute to manage application upgrades.
Setting the Application Name and Icon
Set information such as
–the application icon (android:icon) and
–friendly name (android:label).
These settings are attributes of the <application> tag.
For example, here we set the application icon to a drawable resource provided with the application package and the application label to a string resource:
<application android:icon=”@drawable/icon”
android:label=”@string/app_name“>
set optional application settings as attributes in the <application> tag, such as
–the application description (android:description) and
–the setting to enable the application for debugging on the device (android:debuggable=”true”).
Enforcing Application System Requirements
Android manifest file is also used to specify any system requirements necessary for the application to run properly.
For example, an augmented reality application might require that the handset have GPS, a compass, and a camera.
Similarly, an application that relies upon the Bluetooth APIs available within the Android SDK requires a handset with an SDK version of API Level 5 or higher (Android 2.0).
Types of system requirements can be defined and enforced in the Android manifest file.
When an application is listed on the Android Market, applications can be filtered by these types of information.
The Android platform also checks these requirements when installing the application package on the system and errors out if necessary.
Some of the application system requirements that developers can configure through the android manifest file include.
–The Android SDK versions supported by the application.
–The Android platform features used by the application.
–The Android hardware configurations required by the application.
–The screen sizes and pixel densities supported by the application.
–Any external libraries that the application links to.
Targeting Specific SDK Versions
Android devices run different versions of the Android platform.
Developers must decide
–who their target audience is for a given application?
–Are they trying to support the largest population of users and therefore want to support as many different versions of the platform as possible?
–Are they developing advanced-edge game that requires the latest
device hardware?
Specify which versions of the Android platform an application supports within its Android manifest file using the <uses-sdk> tag
<uses-sdk> tag within an application’s manifest file and is a required tag for applications
that want to be published on the Android Market.
This tag has three important attributes:
–The minSdkVersion attribute:
This attribute specifies the lowest API level that the application supports.
–The targetSdkVersion attribute:
–The maxSdkVersion attribute:
This attribute specifies the highest API level that the application supports.
Each attribute of the <uses-sdk> tag is an integer that represents the API level associated with a given Android SDK.
it is the revision of the API level associated with that SDK.
The API level is set by the developers of the Android SDK.
Specifying the Minimum SDK Version
This value represents the lowest Android SDK version your application supports.
For example, if your application requires APIs introduced in Android SDK 1.6, add the following to your Android Manifest file within the <manifest> tag block:
<uses-sdk android:minSdkVersion=”4″ />
Use the lowest API level possible if you want your application to be compatible with the largest number of Android handsets.
Specifying the Target SDK Version
This value represents the Android SDK version your application was built for and tested against.
For example, if your application was built using the APIs that are backward-compatible to Android 1.6 (API Level 4), but targeted and tested using Android 2.2 SDK (API Level 8), then you would want to specify the targetSdkVersion attribute as 8.
Therefore, add the following to your Android manifest file within the <manifest> tag block:
<uses-sdk android:minSdkVersion=”4″ android:targetSdkVersion=”8″ />
The internals of that method—its behavior—might have changed slightly from SDK to SDK.
The application should continue to behave in “the old way”
despite any new changes or “improvements” to the SDK that might cause unintended consequences in your application.
Specifying the Maximum SDK Version
This value represents the highest Android SDK version your application supports, in terms of API level.
It restricts forward-compatibility of your application.
if you want to limit who can install the application to exclude devices with the newest SDKs.
For example, you might develop a free beta version of your application with plans for a paid version for the newest SDK.
By setting the maxSdkVersion attribute of the manifest file for your free application, you disallow anyone with the newest SDK to install the free version of the application.
Use maxSdkVersion only when absolutely necessary and when you understand the risks associated with its use.
–Application name and version
–what permissions the application requires to run
–what application components it is comprised of
How to Configuring the Android Manifest File
Specially formatted XML file with every android application.Important information about the application’ identity.
Manifest file is named AndroidManifest.xml
Must be included at the top level of any Android project
The information in this file is used by the Android system to
Install and upgrade the application package.
Display the application details such as the application name, description, and icon to users.
Specify application system requirements, including
–which Android SDKs are supported,
–what hardware configurations are required (for example, d-pad navigation), and
–which platform features the application relies upon (for example, uses multitouch capabilities).
Launch application activities.
Manage application permissions.
Configure other advanced application configuration details, including acting as a service, broadcast receiver, or content provider.
Enable application settings such as debugging and configuring instrumentation for application testing.
Editing the Manifest File Using Eclipse
Eclipse Manifest File resource editor organizes the manifest information into categories:
–The Manifest tab
–The Application tab
–The Permissions tab
–The Instrumentation tab
–The AndroidManifest.xml tab
Manifest Tab
contains package-wide settings including
–Package name
–Version information
–Supported android SDK
Min SDK version
Target SDK version
Max SDK version.
–Hardware or feature requirement
Application Tab
Contains application-wide settings including
–Application Toggle
–Application Attributes
- Theme
- Label
- Icon
- Description
–Information about application component
- Activities
- Metadata
- Provider
- Services
Ccontains any permission rules required by application.
–Used to enforce custom permissions for application.
Instrumentation Tab
To declare any instrumentation classes for monitoring the application .
Editing the Manifest File Manually
Generally include a single <manifest> tag with a single <application> tag.
Sample android multimedia application code.
Managing Your Application’s Identity
Android manifest file defines the application properties.
The package name must be defined within the Android manifest file within the <manifest> tag using the package attribute:
<manifest xmlns:android=”http://schemas.android.com/apk/res/android”
package=”com.androidbook.multimedia”
android:versionCode=”1″
android:versionName=”1.0″>
Versioning the application
It is vital to maintaining your application in the field.
Versioning can help reduce confusion and make product support and upgrades simpler
There are two different version attributes defined within the
<manifest> tag:
– The version name and
– The version code.
The version name (android:versionName) is a user-friendly, developer-defined version attribute.
This information is displayed to users when they manage applications on their devices and when they download the application from marketplaces.
Developers use this version information to keep track of their application versions in the field.
The Android operating system uses the version code (android:versionCode) that is a numeric attribute to manage application upgrades.
Setting the Application Name and Icon
Set information such as
–the application icon (android:icon) and
–friendly name (android:label).
These settings are attributes of the <application> tag.
For example, here we set the application icon to a drawable resource provided with the application package and the application label to a string resource:
<application android:icon=”@drawable/icon”
android:label=”@string/app_name“>
set optional application settings as attributes in the <application> tag, such as
–the application description (android:description) and
–the setting to enable the application for debugging on the device (android:debuggable=”true”).
Enforcing Application System Requirements
Android manifest file is also used to specify any system requirements necessary for the application to run properly.
For example, an augmented reality application might require that the handset have GPS, a compass, and a camera.
Similarly, an application that relies upon the Bluetooth APIs available within the Android SDK requires a handset with an SDK version of API Level 5 or higher (Android 2.0).
Types of system requirements can be defined and enforced in the Android manifest file.
When an application is listed on the Android Market, applications can be filtered by these types of information.
The Android platform also checks these requirements when installing the application package on the system and errors out if necessary.
Some of the application system requirements that developers can configure through the android manifest file include.
–The Android SDK versions supported by the application.
–The Android platform features used by the application.
–The Android hardware configurations required by the application.
–The screen sizes and pixel densities supported by the application.
–Any external libraries that the application links to.
Targeting Specific SDK Versions
Android devices run different versions of the Android platform.
Developers must decide
–who their target audience is for a given application?
–Are they trying to support the largest population of users and therefore want to support as many different versions of the platform as possible?
–Are they developing advanced-edge game that requires the latest
device hardware?
Specify which versions of the Android platform an application supports within its Android manifest file using the <uses-sdk> tag
<uses-sdk> tag within an application’s manifest file and is a required tag for applications
that want to be published on the Android Market.
This tag has three important attributes:
–The minSdkVersion attribute:
This attribute specifies the lowest API level that the application supports.
–The targetSdkVersion attribute:
–The maxSdkVersion attribute:
This attribute specifies the highest API level that the application supports.
Each attribute of the <uses-sdk> tag is an integer that represents the API level associated with a given Android SDK.
it is the revision of the API level associated with that SDK.
The API level is set by the developers of the Android SDK.
Specifying the Minimum SDK Version
This value represents the lowest Android SDK version your application supports.
For example, if your application requires APIs introduced in Android SDK 1.6, add the following to your Android Manifest file within the <manifest> tag block:
<uses-sdk android:minSdkVersion=”4″ />
Use the lowest API level possible if you want your application to be compatible with the largest number of Android handsets.
Specifying the Target SDK Version
This value represents the Android SDK version your application was built for and tested against.
For example, if your application was built using the APIs that are backward-compatible to Android 1.6 (API Level 4), but targeted and tested using Android 2.2 SDK (API Level 8), then you would want to specify the targetSdkVersion attribute as 8.
Therefore, add the following to your Android manifest file within the <manifest> tag block:
<uses-sdk android:minSdkVersion=”4″ android:targetSdkVersion=”8″ />
The internals of that method—its behavior—might have changed slightly from SDK to SDK.
The application should continue to behave in “the old way”
despite any new changes or “improvements” to the SDK that might cause unintended consequences in your application.
Specifying the Maximum SDK Version
This value represents the highest Android SDK version your application supports, in terms of API level.
It restricts forward-compatibility of your application.
if you want to limit who can install the application to exclude devices with the newest SDKs.
For example, you might develop a free beta version of your application with plans for a paid version for the newest SDK.
By setting the maxSdkVersion attribute of the manifest file for your free application, you disallow anyone with the newest SDK to install the free version of the application.
Use maxSdkVersion only when absolutely necessary and when you understand the risks associated with its use.
Posted in: Android Theory
0 comments:
Post a Comment