In addition to configuring your application’s identity, the 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).These types of system requirements can be defined and enforced in the Android manifest file.Then, 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
Targeting Specific SDK Versions
Android devices run different versions of the Android platform. Often, you see old, less powerful, or even less expensive devices running older versions of the Android platform, whereas newer, more powerful devices that show up on the market often run the latest Android software.
There are now dozens of different Android devices in users’ hands. 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? Or are they developing a bleeding-edge game that requires the latest device hardware?
Developers can specify which versions of the Android platform an application supports within its Android manifest file using the <uses-sdk> tag. This tag has three important attributes:
Each attribute of the <uses-sdk> tag is an integer that represents the API level associated with a given Android SDK. This value does not directly correspond to the SDK version. Instead, it is the revision of the API level associated with that SDK. The API level is set by the developers of the Android SDK. You need to check the SDK documentation to determine the API level value for each version.
This shows the Android SDK versions available for shipping applications.
Android SDK Versions and Their API Levels
Specifying the Minimum SDK Version
You should always specify the minSdkVersion attribute for your application. This value represents the lowest Android SDK version your application supports.
For example, if your application requires APIs introduced in Android SDK 1.6, you would check that SDK’s documentation and find that this release is defined as API Level 4. Therefore, add the following to your Android Manifest file within the
It’s that simple. You should use the lowest API level possible if you want your application to be compatible with the largest number of Android handsets. However, you must ensure that your application is tested sufficiently on any non-target platforms (any API level supported below your target SDK, as described in the next section).
Specifying the Target SDK Version
You should always specify the targetSdkVersion attribute for your application. 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:
Why should you specify the target SDK version you used? Well, the Android platform has built-in functionality for backward-compatibility (to a point).Think of it like this: A specific method of a given API might have been around since API Level 1. However, the internals of that method—its behavior—might have changed slightly from SDK to SDK. By specifying the target SDK version for your application, the Android operating system attempts to match your application with the exact version of the SDK (and the behavior as you tested it within the application), even when running a different (newer) version of the platform. This means that 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
You will rarely want to specify the maxSdkVersion attribute for your application. This value represents the highest Android SDK version your application supports, in terms of API level. It restricts forward-compatibility of your application.
One reason you might want to set this attribute is 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. The downside of this idea? If your users have phones that receive over-the-air SDK updates, your application would cease to work (and appear) on phones where it had functioned perfectly, which might “upset” your users and result in bad ratings on your market of choice.
The short answer: Use maxSdkVersion only when absolutely necessary and when you understand the risks associated with its use.
Enforcing Application Platform Requirements
Android devices have different hardware and software configurations. Some devices have built-in keyboards and others rely upon the software keyboard. Similarly, certain Android devices support the latest 3-D graphics libraries and others provide little or no graphics support. The Android manifest file has several informational tags for flagging the system features and hardware configurations supported or required by an Android application.
Specifying Supported Input Methods
The <uses-configuration> tag can be used to specify which input methods the application supports. There are different configuration attributes for five-way navigation, the hardware keyboard and keyboard types; navigation devices such as the directional pad, trackball, and wheel; and touch screen settings.
There is no “OR” support within a given attribute. If an application supports multiple input configurations, there must be multiple <uses-configuration> tags—one for each complete configuration supported.
For example, if your application requires a physical keyboard and touch screen input using a finger or a stylus, you need to define two separate <uses- configuration> tags in your manifest file, as follows:
Specifying Required Device Features
Not all Android devices support every Android feature. Put another way: There are a number of APIs (and related hardware) that Android devices may optionally include. For example, not all Android devices have multi-touch ability or a camera flash.
The <uses-feature> tag can be used to specify which Android features the application requires to run properly. These settings are for informational purposes only—the Android operating system does not enforce these settings, but publication channels such as the Android Market use this information to filter the applications available to a given user.
If your application requires multiple features, you must create a <uses-feature> tag for each. For example, an application that requires both a light and proximity sensor requires two tags:
One common reason to use the <uses-feature> tag is for specifying the OpenGL ES versions supported by your application. By default, all applications function with OpenGL ES 1.0 (which is a required feature of all Android devices). However, if your application requires features available only in later versions of OpenGL ES, such as 2.0, then you must specify this feature in the Android manifest file. This is done using the android:glEsVersion attribute of the <uses-feature> tag. Specify the lowest version of OpenGL ES that the application requires. If the application works with 1.0 and 2.0, specify the lowest version (so that the Android Market allows more users to install your application).
For more information about the <uses-feature> tag of the Android manifest file, see the Android SDK reference.
Specifying Supported Screen Sizes
Android devices come in many shapes and sizes. Screen sizes and pixel densities vary widely across the range of Android devices available on the market today. The Android platform categorizes screen types in terms of sizes (small, normal, and large) and pixel density (low, medium, and high).These characteristics effectively cover the variety of screen types available within the Android platform.
An application can provide custom resources for specific screen sizes and pixel densities (we cover this in Chapter “Managing Application Resources”).The <supportsscreen> tag can be used to specify which Android types of screens the application supports.
For example, if the application supports QVGA screens (small) and HVGA screens (normal) regardless of pixel density, the <supports-screen> tag is configured as follows:
For more information about the <supports-screen> tag of the Android manifest file, see the Android SDK reference as well as the Android Dev Guide documentation on Screen Support.
Working with External Libraries
You can register any shared libraries your application links to within the Android manifest file. By default, every application is linked to the standard Android packages (such as android.app) and is aware of its own package.However, if your application links to additional packages, they must be registered within the <application> tag of the Android manifest file using the <uses-library> tag. For example
This feature is often used for linking to optional Google APIs. For more information about the <uses-library> tag of the Android manifest file, see the Android SDK reference.
Setting Up Your Android Development Environment
Writing Your First Android Application
Understanding The Anatomy Of An Android Application
Defining Your Application Using The Android Manifest File
Managing Application Resources
Exploring User Interface Screen Elements
Designing User Interfaces With Layouts
Drawing And Working With Animation
Using Android Data And Storage Apis
Sharing Data Between Applications With Content Providers
Using Android Networking Apis
Using Android Web Apis
Using Location-based Services (lbs) Apis
Using Android Multimedia Apis
Using Android Telephony Apis
Using Android 3d Graphics With Opengl Es
Using The Android Ndk
Using Android’s Optional Hardware Apis
Working With Notifications
Working With Services
Extending Android Application Reach
Managing User Accounts And Synchronizing User Data
Handling Advanced User Input
Targeting Different Device Configurations And Languages
The Mobile Software Development Process
Designing And Developing Bulletproof Android Applications
Testing Android Applications
Selling Your Android Application
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.