Each Android project includes a manifest file, AndroidManifest.xml, stored in the root of its project hierarchy. The manifest defines the structure and metadata of your application, its components, and its requirements.
It includes nodes for each of the Activities, Services, Content Providers, and Broadcast Receivers that make up your application and, using Intent Filters and Permissions, determines how they interact with each other and with other applications.
It includes nodes for each of the Activities, Services, Content Providers, and Broadcast Receivers that make up your application and, using Intent Filters and Permissions, determines how they interact with each other and with other applications.
The manifest can also specify application metadata (such as its icon, version number, or theme), and additional top-level nodes can specify any required permissions, unit tests, and define hardware, screen, or platform requirements
The manifest is made up of a root manifest tag with a package attribute set to the project’s package. It should also include an xmlns:android attribute that supplies several system attributes used within the file
Use the versionCode attribute to define the current application version as an integer that increases with each version iteration, and use the versionName attribute to specify a public version that will be displayed to users
You can also specify whether to allow (or prefer) for your application be installed on external storage (usually an SD card) rather than internal storage using the installLocation attribute. To do this specify either preferExternal or auto, where the former installs to external storage whenever possible, and the latter asks the system to decide.
If you don’t specify an install location attribute, your application will be installed in the internal storage and users won’t be able to move it to external storage. The total amount of internal storage is generally limited, so it’s good practice to let your application be installed on external storage whenever possible
There are some applications for which installation to external storage is not appropriate due to the consequences of unmounting or ejecting the external storage, including:
Applications with Widgets, Live Wallpapers, and Live Folders — Your Widgets, Live Wallpapers, and Live Folders will be removed from the home screen and may not be available until the system restarts.
Applications with ongoing Services — Your application and its running Services will be stopped and won’t be restarted automatically
Input Method Engines — Any IME installed on external storage will be disabled and must be reselected by the user after the external storage is once again available.
The following XML snippet shows a typical manifest node:
<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>
The manifest tag can include nodes that define the application components, security settings, test classes, and requirements that make up your application. The following list gives a summary of the available manifest sub-node tags and provides an XML snippet demonstrating how each tag is used:
uses-sdk — This node enables you to define a minimum and maximum SDK version that must be available on a device for your application to function properly, and target SDK for which it has been designed using a combination of minSDKVersion, maxSDKVersion, and targetSDKVersion attributes, respectively.
The minimum SDK version specifies the lowest version of the SDK that includes the APIs you have used in your application. If you fail to specify a minimum version, it defaults to 1, and your application crashes when it attempts to access unavailable APIs.
<uses-sdk android:minSdkVersion=”16”
android:targetSdkVersion=”29”/>
- uses-configuration — The uses-configuration nodes specify each combination of input mechanisms are supported by your application. You shouldn’t normally need to include this node, though it can be useful for games that require particular input controls. You can specify any combination of input devices that include the following:
- reqFiveWayNav — Specify true for this attribute if you require an input device capable of navigating up, down, left, and right and of clicking the current selection. This includes both trackballs and directional pads (D-pads).
- reqHardKeyboard — If your application requires a hardware keyboard, specify true.
- reqKeyboardType — Lets you specify the keyboard type as one of nokeys, qwerty, twelvekey, or undefined.
- reqNavigation — Specify the attribute value as one of nonav, dpad, trackball, wheel, or undefined as a required navigation device
- reqTouchScreen — Select one of notouch, stylus, finger, or undefined to specify the required touchscreen input.
- You can specify multiple supported configurations, for example, a device with a fi-nger touchscreen, a trackball, and either a QUERTY or a twelve-key hardware keyboard, as shown here:
<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”/>
uses-feature — Android is available on a wide variety of hardware platforms. Use multiple uses-feature nodes to specify which hardware features your application requires. This prevents your 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” />
You can require support for any hardware that is optional on a compatible device. Currently, optional hardware features include the following:
Audio — For applications that requires a low-latency audio pipeline. Note that at the time of writing this book, no Android devices satisfied this requirement.
Bluetooth — Where a Bluetooth radio is required
Camera — For applications that require a camera. You can also require (or set as options) autofocus, flash, or a front-facing camera
Location — If you require location-based services. You can also specify either network or GPS support explicitly
Microphone — For applications that require audio input.
NFC — Requires NFC (near-field communications) support
Sensors — Enables you to specify a requirement for any of the potentially available hardware sensors.
Telephony — Specify that either telephony in general, or a specific telephony radio (GSM or CDMA) is required.
Touchscreen — To specify the type of touch-screen your application requires.
USB — For applications that require either USB host or accessory mode support.
Wi-Fi — Where Wi-Fi networking support is required