5. Defining the Manifest
Android projects use a special configuration file called the Android manifest file to determine application settings, such as the application name and version, as well as what permissions the application requires to run and what application components it is composed of. In this chapter, you explore the Android manifest file in detail and learn how applications use it to define and describe application behavior.
Configuring Android Applications Using the Android Manifest File
The Android application manifest file is a specially constructed XML file that must accompany each Android application. This file contains important information about the application’s identity. Here, you define the application’s name and version information as well as what application components the application relies on, what permissions the application requires to run, and other application configuration information.
The Android manifest file is named AndroidManifest.xml. The easiest way to find this file is by making the 1: Project tab the Active Tool Window of Android Studio and then selecting the Android tab from the drop down list (see Figure 5.1 left), so that the app folder is shown as the root for navigating your project structure. You should see a manifests folder inside the app folder that includes the AndroidManifest.xml file (see Figure 5.1, right).
Figure 5.1 Selecting the Android tab from the Active Tool Window drop-down list (left) and showing the AndroidManifest.xml file inside the app/manifests directory (right).
The information in this file is used by the Android system to
Install and upgrade the application package
Display the application details to users, such as the application name, description, and icon
Specify application system requirements, including which Android SDKs are supported, what device configurations are required (for example, D-pad navigation), and which platform features the application relies on (for example, multitouch capabilities)
Specify what features are required by the application for app store-filtering purposes
Register application activities and when they should be launched
Manage application permissions
Configure other advanced application component configuration details, including defining services, broadcast receivers, and content providers
Specify intent filters for your activities, services, and broadcast receivers
Enable application settings such as debugging and configuring instrumentation for application testing
Tip
When you create a project using Android Studio, the initial AndroidManifest.xml file is created for you. If you are using the android command-line tool, the Android manifest file is also created for you.
Editing the Android Manifest File
You can edit the Android manifest file, AndroidManifest.xml, by manually editing the XML. The Android manifest file is a specially constructed XML file.
Android manifest files include a single <manifest> tag with a single <application> tag. The following is a sample AndroidManifest.xml file for an application called Simple Hardware:
<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
package="com.introtoandroid.simplehardware" >
<uses-permission android:name="android.permission.BATTERY_STATS" />
<uses-feature android:name="android.hardware.sensor.accelerometer" />
<uses-feature android:name="android.hardware.sensor.barometer" />
<uses-feature android:name="android.hardware.sensor.compass" />
<uses-feature android:name="android.hardware.sensor.gyroscope" />
<uses-feature android:name="android.hardware.sensor.light" />
<uses-feature android:name="android.hardware.sensor.proximity" />
<uses-feature android:name="android.hardware.sensor.stepcounter" />
<uses-feature android:name="android.hardware.sensor.stepdetector" />
<application
android:allowBackup="true"
android:icon="@mipmap/ic_launcher"
android:label="@string/app_name"
android:theme="@style/AppTheme" >
<activity
android:name=".SimpleHardwareActivity"
android:label="@string/app_name" >
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
<activity
android:name=".SensorsActivity"
android:label="@string/title_activity_sensors"
android:parentActivityName=".SimpleHardwareActivity" >
<meta-data
android:name="android.support.PARENT_ACTIVITY"
android:value="com.introtoandroid.simplehardware.
SimpleHardwareActivity" />
</activity>
<activity
android:name=".BatteryActivity"
android:label="@string/title_activity_battery"
android:parentActivityName=".SimpleHardwareActivity" >
<meta-data
android:name="android.support.PARENT_ACTIVITY"
android:value="com.introtoandroid.simplehardware.
SimpleHardwareActivity" />
</activity>
</application>
</manifest>
Note
Within the previous manifest code listing, you may be wondering why there is a dot (.) in front of the <activity> tag name attributes. The dot is used as shorthand to specify that the SimpleHardware, SensorsActivity, and BatteryActivity classes belong to the package name specified in the manifest. We could have specified the entire package name path, but we have used the shorthand to save on typing the extra characters.
Here is a summary of what this file tells us about the SimpleHardware application:
The application uses the package name com.introtoandroid.simplehardware.
The application name and label are stored in the resource string called @string/app_name within the res/values/strings.xml resource file.
The application theme is stored in the resource string called @style/AppTheme within the res/values/styles.xml/styles.xml files (there are two default files created for supporting devices’ themes).
The application supports backup and restore with allowBackup set to true.
The application icon is the PNG file called ic_launcher.png stored within the res/mipmap/ic_launcher.png directory (there are actually multiple versions for different pixel densities).
The application has four activities (MenuActivity, SimpleHardwareActivity, SensorsActivity, and BatteryActivity).
SimpleHardwareActivity is the primary entry point for the application because it handles the action android.intent.action.MAIN. This Activity shows in the application launcher because its category is android.intent.category.LAUNCHER. Each <activity> tag also defines a name and a label attribute.
SensorsActivity and BatteryActivity both have a parentActivityName of SimpleHardwareActivity, defined once with the android:parentActivityName attribute of the <activity> tag to support the Up navigation feature on API 17+, and once in the <meta-data> tag to support this same feature on API versions 4 to 16.
The application requires the BATTERY_STATS permissions to run with the <uses-permission> tag.
Finally, the application requests to use various different hardware sensors with the <uses-feature> tag.
Tip
When using the <uses-feature> tag, you can specify an optional attribute of android:required and set the value to true or false. This is used for configuring Google Play store filtering. If this attribute were set to true, Google Play would show your application listing only to users with devices that have that particular hardware or software feature, in this case, various sensors. To learn more about Google Play store filtering, visit http://d.android.com/google/play/filters.html.
Now let’s talk about some of these important configurations in detail.
Managing Your Application’s Identity
Your application’s Android manifest file defines the application properties. The package name must be defined in the Android manifest file within the <manifest> tag using the package attribute:
<manifest
xmlns:android="http://schemas.android.com/apk/res/android"
package="com.introtoandroid.simplehardware">
Setting the Application Name and Icon
Overall application settings are configured with the <application> tag of the Android manifest file. Here, you 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 an image resource provided with the application package, and the application label to a string resource:
<application android:icon="@mipmap/ic_launcher"
android:label="@string/app_name">
You can also set optional application settings as attributes in the <application> tag, such as the application description (android:description).
Tip
Android Marshmallow introduced an auto backup feature. To leverage this feature in your application, use the <application> attribute android:fullBackupContent and specify an XML file as the value that defines a data backup scheme your application should follow. This will help protect information your user cares about by backing up and restoring the information automatically, in case the user loses a device. To learn more about this feature and how to implement this functionality, see http://d.android.com/preview/backup/index.html.
Enforcing Application System Requirements
In addition to configuring your application’s identity, the Android manifest file is used to specify any system requirements necessary for the application to run properly. For example, an augmented reality application might require that the device have GPS, a compass, and a camera.
These types of system requirements can be defined and enforced in the Android manifest file. When an application is installed on a device, the Android platform checks these requirements and will error out if necessary. Similarly, the Google Play store uses information in the Android manifest file to filter which applications to offer to which devices so that users install applications that should work on their devices.
Some of the application system requirements that developers can configure through the Android manifest file include:
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 included in the application
Enforcing Application Platform Requirements
Android devices have different hardware and software configurations. Some devices have built-in hardware controls and others rely on the software only controls. Similarly, certain Android devices support the latest 3D 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 hardware and software 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, and touchscreen settings.
There is no “OR” support within a given attribute. If an application supports multiple input configurations, there must be multiple <uses-configuration> tags defined in your Android manifest file—one for each configuration supported.
For example, if your application requires a physical keyboard and touchscreen input using a finger or a stylus, you need to define two separate <uses-configuration> tags in your manifest file, as follows:
<uses-configuration android:reqHardKeyboard="true"
android:reqTouchScreen="finger" />
<uses-configuration android:reqHardKeyboard="true"
android:reqTouchScreen="stylus" />
For more information about the <uses-configuration> tag of the Android manifest file, see the Android SDK Reference at http://d.android.com/guide/topics/manifest/uses-configuration-element.html.
Warning
Make sure to test your application with all of the available types of input methods, as not all devices support all types. For example, TVs do not have touchscreens, and if you design your application for touchscreen inputs, your app will not work properly on TV devices.
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 device manufacturers and carriers may optionally include. For example, not all Android devices have multitouch capability or a camera flash.
The <uses-feature> tag is used to specify which Android features your application uses 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 Google Play store use this information to filter the applications available to a given user. Other applications might check this information as well.
If your application requires multiple features, you must create a <uses-feature> tag for each feature. For example, an application that requires both a light and a proximity sensor requires two tags:
<uses-feature android:name="android.hardware.sensor.light" />
<uses-feature android:name="android.hardware.sensor.proximity" />
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 or 3.0, 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, 2.0, and 3.0, specify the lowest version (so that the Google Play store 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 at http://d.android.com/guide/topics/manifest/uses-feature-element.html.
Tip
If a certain feature is not required for your application to function properly, rather than providing filters for the Google Play store to limit access to specific devices, you could check for certain device features at runtime and allow specific application functionality only if those particular features are present on the user’s device. That way, you maximize the number of users who can install and use your application. To check for specific features at runtime, use the hasSystemFeature() method. For example, to see if the device your application is running on has touchscreen capabilities and returns a Boolean value: getPackage Manager().hasSystemFeature("android.hardware.touchscreen");
Specifying Supported Screen Sizes
Android devices come in many shapes and sizes. Screen sizes and pixel densities vary tremendously across the wide range of Android devices available on the market today. The <supports-screens> tag can be used to specify which Android screen types the application supports. The Android platform categorizes screen types in terms of sizes (small, normal, large, and xlarge) and pixel density (LDPI, MDPI, HDPI, XHDPI, XXHDPI, and XXXHDPI, representing low-, medium-, high-, extra-high-, extra-extra-high-, and extra-extra-extra-high-density displays). These characteristics effectively cover the variety of screen types available within the Android platform.
For example, if the application supports small screens and normal screens regardless of pixel density, the application’s <supports-screens> tag is configured as follows:
<supports-screens android:resizable="false"
android:smallScreens="true"
android:normalScreens="true"
android:largeScreens="false"
android:xlargeScreens="false"
android:compatibleWidthLimitDp="320"
android:anyDensity="true"/>
For more information about the <supports-screens> tag of the Android manifest file, see the Android SDK Reference at http://d.android.com/guide/topics/manifest/supports-screens-element.html as well as the Android Developers Guide on screen support at http://d.android.com/guide/practices/screens_support.html#DensityConsiderations.
Other Application-Configuration Settings and Filters
You’ll want to be aware of several other lesser-used manifest file settings because they are also used by the Google Play store for application filtering:
The <supports-gl-texture> tag is used to specify the GL texture compression format supported by the application. This tag is used by applications that use the graphics libraries and are intended to be compatible only with devices that support a specific compression format. For more information about this manifest file tag, see the Android SDK documentation at http://d.android.com/guide/topics/manifest/supports-gl-texture-element.html.
The <compatible-screens> tag is used solely by the Google Play store to restrict installation of your application to devices with specific screen sizes. This tag is not checked by the Android operating system, and usage is discouraged unless you absolutely need to restrict the installation of your application on certain devices. For more information about this manifest file tag, see the Android SDK documentation at http://d.android.com/guide/topics/manifest/compatible-screens-element.html.
Registering Activities in the Android Manifest
Each Activity within the application must be defined within the Android manifest file with an <activity> tag. For example, the following XML excerpt registers an Activity class called SensorActivity:
<activity android:name="SensorsActivity" />
This Activity must be defined as a class within the com.introtoandroid.simplehardware package—that is, the package specified in the <manifest> element of the Android manifest file. You can also enforce the scope of the Activity class by using the dot as a prefix in the Activity class name:
<activity android:name=".SensorsActivity" />
Or, you can specify the complete class name:
<activity android:name="com.introtoandroid.simplehardware.SensorsActivity" />
Warning
You must define the <activity> tag for each Activity or it will not run as part of your application. It is quite common for developers to implement an Activity and then forget to do this. They then spend a lot of time troubleshooting why it isn’t running properly, only to realize they forgot to register it in the Android manifest file.
Designating a Primary Entry-Point Activity for Your Application Using an Intent Filter
You designate an Activity class as the primary entry point by configuring an intent filter using the Android manifest tag <intent-filter> in the Android manifest file with the MAIN action type and the LAUNCHER category.
For example, the following XML configures an Activity called SimpleHardwareActivity as the primary launching point of the application:
<activity android:name=".SimpleHardwareActivity"
android:label="@string/app_name">
<intent-filter>
<action android:name="android.intent.action.MAIN" />
<category android:name="android.intent.category.LAUNCHER" />
</intent-filter>
</activity>
Configuring Other Intent Filters
The Android operating system uses intent filters to resolve implicit intents—that is, intents that do not specify a specific activity or other component type to launch. Intent filters can be applied to activities, services, and broadcast receivers. An intent filter declares that this application component is capable of handling or processing a specific type of intent when it matches the filter’s criteria.
Different applications have the same sorts of intent filters and are able to process the same sorts of requests. In fact, this is how the “share” features and the flexible application launch system of the Android operating system work. For example, you can have several different Web browsers installed on a device, all of which can handle “browse the Web” intents by setting up the appropriate filters.
Intent filters are defined using the <intent-filter> tag and must contain at least one <action> tag, but can also contain other information such as <category> and <data> blocks. Here, we have a sample intent filter block that might be found within an <activity> block:
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.BROWSABLE" />
<category android:name="android.intent.category.DEFAULT" />
<data android:scheme="geoname"/>
</intent-filter>
This intent filter definition uses a predefined action called VIEW, the action for viewing particular content. It also handles Intent objects in the BROWSABLE or DEFAULT category, and uses a scheme of geoname so that when a URI starts with geoname://, the Activity with this intent filter can be launched to view the content.
Tip
You can define custom actions unique to your application. If you do so, be sure to document these actions if you want them to be used by third parties. You can document these however you want: your SDK documentation could be provided on your website, or confidential documents could be given directly to a client.
Registering Other Application Components
All application components must be defined within the Android manifest file. In addition to activities, all services and broadcast receivers must be registered within the Android manifest file.
Services are registered using the <service> tag.
Broadcast receivers are registered using the <receiver> tag.
Content providers are registered using the <provider> tag.
Both services and broadcast receivers use intent filters. If your application acts as a content provider, effectively exposing a shared data service for use by other applications, it must declare this capability within the Android manifest file using the <provider> tag. Configuring a content provider involves determining what subsets of data are shared and what permissions are required to access them, if any. We begin our discussion of content providers in Chapter 17, “Leveraging Content Providers.”
Tip
Many of the code examples provided in this chapter are taken from the SimplePermissions application. The source code for this application is provided for download on the book’s website (http://introductiontoandroid.blogspot.com).
Working with Permissions
The Android operating system has been locked down so that applications have limited capability to adversely affect operations outside their process space. Instead, Android applications run within the bubble of their own virtual machine, with their own Linux user account (and related permissions).
Registering Permissions Your Application Requires
Android applications have no permissions by default. Instead, any permissions for shared resources or privileged access—whether it’s shared data, such as the Contacts database, or access to underlying hardware, such as the built-in camera—must be explicitly registered within the Android manifest file. For devices running versions of Android prior to Marshmallow 6.0 API Level 23, these permissions are granted when the application is installed. For devices running Android Marshmallow 6.0 API Level 23 and newer, permissions with a level of PROTECTION_NORMAL, and some with PROTECTION_SIGNATURE, are granted at installation, while those with a PROTECTION_DANGEROUS must be requested and verified at runtime.
The following XML excerpt for inclusion in the Android manifest file defines a permission using the <uses-permission> tag to read from and write to the contact database, both having a permission level of PROTECTION_DANGEROUS:
<uses-permission android:name="android.permission.READ_CONTACTS" />
<uses-permission android:name="android.permission.WRITE_CONTACTS" />
A complete list of the permissions can be found in the android.Manifest.permission class. Your application manifest should include only the permissions required to run.
Tip
You might find that, in certain cases, permissions are not enforced (you can operate without the permission) by one device or another. In these cases, it is prudent to request the permission anyway for two reasons. First, the user is informed that the application is performing those sensitive actions, and second, that permission could be enforced in a later device update. Also be aware that in early SDK versions, not all permissions were necessarily enforced at the platform level.
If the application description or type of application you are providing does not clearly justify the permissions requested, you may get low ratings simply for requesting unnecessary permissions. We see many applications asking for permissions they do not need or have no reason to request. Many people who realize this will not follow through and install the application. Privacy is a big concern for many users, so be sure to respect it.
Requesting Permissions at Runtime
Android Marshmallow introduced a new permissions model allowing users to install your application and to accept your applications permissions once they interact with the features that require them. This new permissions model is important because it reduces the amount of friction permissions may have caused in the past, such as users abandoning the installation of your application because they are not comfortable accepting a particular permission.
With the Android Marshmallow permissions model, a user does not need to grant permissions prior to installing, allowing him or her to install and start interacting with your application. Once the user comes across a feature that requires a particular permission, he or she is presented with a dialog requesting that the permission be granted. If the permission is granted, the system notifies the application and permission is then granted to the user. If the permission is not granted, the user will not be able to access that particular functional area of your application that requires the denied permission. Permissions are declared as normal with the <uses-permission> tag in the Android manifest file. Your applications code is where you check to see if the permission has been granted. This permissions model allows users to revoke access to particular permissions in the application settings, without having to uninstall your application. Even if a user grants a particular permission, he or she is able to revoke permissions at any time, so your application must always check that a particular permission is granted, and if not, make a request for the permission.
To request permissions at runtime, you must first add the following dependencies to your build.gradle app module file (we talk more about Gradle and dependencies in Appendix E, “Quick-Start: Gradle Build System”):
compile 'com.android.support:support-v4:23.0.0'
compile 'com.android.support:appcompat-v7:23.0.0'
Then your Activity must extend from AppCompatActivity and implement the ActivityCompat.OnRequestPermissionsResultCallback interface as shown here:
public class PermissionsActivity extends AppCompatActivity
implements ActivityCompat.OnRequestPermissionsResultCallback {
// Activity code here
}
Then you must check if the permission has been granted yet, and if not, request the permission. This is performed as shown below:
if (ActivityCompat.checkSelfPermission(this, Manifest.permission.READ_CONTACTS)
!= PackageManager.PERMISSION_GRANTED
|| ActivityCompat.checkSelfPermission(this, Manifest.permission.WRITE_
CONTACTS)
!= PackageManager.PERMISSION_GRANTED) {
Log.i(DEBUG_TAG, "Contact permissions not granted. Requesting permissions.");
ActivityCompat.requestPermissions(GridListMenuActivity.this, {
Manifest.permission.READ_CONTACTS,
Manifest.permission.WRITE_CONTACTS}, 0);
} else {
Log.i(DEBUG_TAG,
"Contact permissions granted. Displaying contacts.");
// Do work here
}
This if statement checks if the READ_CONTACTS and WRITE_CONTACTS permissions have been granted, and if not, calls the requestPermissions() method of ActivityCompat. You then must implement the OnRequestPermissionsResultCallback by overriding the onRequestPermissionsResult() method in your Activity as shown below:
@Override
public void onRequestPermissionsResult(int requestCode,
@NonNull String[] permissions, @NonNull int[] grantResults) {
if (requestCode == REQUEST_CONTACTS) {
Log.d(DEBUG_TAG, "Received response for contact permissions request.");
// All Contact permissions must be checked
if (verifyPermissions(grantResults)) {
// All required permissions granted, proceed as usual
Log.d(DEBUG_TAG, "Contacts permissions were granted.");
Toast.makeText(this, "Contacts Permission Granted",
Toast.LENGTH_SHORT).show();
} else {
Log.d(DEBUG_TAG, "Contacts permissions were denied.");
Toast.makeText(this, "Contacts Permission Denied",
Toast.LENGTH_SHORT).show();
}
} else {
super.onRequestPermissionsResult(requestCode, permissions, grantResults);
}
}
This method handles the result input by the user, and if the user accepted, the permission is now available to your application; if the user denied the request, the permission will not be available. Whatever features you develop that require those denied permissions will not be made available until the user chooses to grant the appropriate permission.
Note
Android Marshmallow introduced a permission for fingerprint authentication. To add this permission to your applications manifest, use the android.permission.USE_FINGERPRINT value. This will allow your application to support fingerprint authentication on devices that have the appropriate hardware support.
Registering Permissions Your Application Enforces
Applications can also define and enforce their own permissions via the <permission> tag to be used by other applications. Permissions must be described and then applied to specific application components, such as activities, using the android:permission attribute.
Tip
Use Java-style scoping for unique naming of application permissions (for example, com.introtoandroid.media.ViewMatureMaterial).
Permissions can be enforced at several points:
When starting an Activity or Service
When accessing data provided by a content provider
At the method call level
When sending or receiving broadcasts by an Intent
Permissions can have three primary protection levels: normal, dangerous, and signature. The normal protection level is a good default for fine-grained permission enforcement within the application. The dangerous protection level is used for higher-risk activities, which might adversely affect the device. Finally, the signature protection level permits any application signed with the same certificate to use that component for controlled application interoperability. You will learn more about application signing in Chapter 22, “Distributing Your Applications.”
Permissions can be broken down into categories, called permission groups, which describe or warn why specific activities require permission. For example, permissions might be applied for activities that expose sensitive user data such as location and personal information (android.permission-group.LOCATION and android.permission-group.PERSONAL_INFO), access underlying hardware (android.permission-group.HARDWARE_CONTROLS), or perform operations that might incur fees to the user (android.permission-group.COST_MONEY). A complete list of permission groups is available within the Manifest.permission_group class.
For more information about applications and how they can enforce their own permissions, check out the <permission> manifest tag SDK documentation at http://d.android.com/guide/topics/manifest/permission-element.html.
Exploring Other Manifest File Settings
We have now covered the basics of the Android manifest file, but many other settings are configurable within the Android manifest file using different tag blocks, not to mention attributes within each tag that we have already discussed.
Some other features you can configure within the Android manifest file include
Setting application-wide themes within the <application> tag attributes
Configuring unit-testing features using the <instrumentation> tag
Aliasing activities using the <activity-alias> tag
Creating broadcast receivers using the <receiver> tag
Creating content providers using the <provider> tag, along with managing content-provider permissions using the <grant-uri-permission> and <path-permission> tags
Including other data within your activity, service, or receiver-component registrations with the <meta-data> tag
For more detailed descriptions of each tag and attribute available in the Android SDK (and there are many), please review the Android SDK Reference on the Android manifest file at http://d.android.com/guide/topics/manifest/manifest-intro.html.
Summary
Each Android application has a specially formatted XML configuration file called AndroidManifest.xml. This file describes the application’s identity in great detail. Some information that you must define within the Android manifest file includes the application’s package and name information, what application components it contains, which device configurations it requires, and what permissions it needs to run. The Android manifest file is used by the Android operating system to install, upgrade, and run the application package. Some details of the Android manifest file are also used by third parties, including the Google Play publication channel. In addition, the new Android Marshmallow permission model allows users to grant access to permissions at runtime and revoke access to particular permissions.
Quiz Questions
1. What is the manifest XML tag for specifying the input methods your application supports?
2. What is the manifest XML tag for specifying the required device features for your application?
3. What is the manifest XML tag for specifying screen sizes supported by your application?
4. What is the manifest XML tag for registering permissions that your application enforces?
5. What is the manifest XML <uses-permission> attribute for supporting fingerprint authentication?
Exercises
1. Define a fictitious <application> manifest XML tag; include the icon, label, allowBackup, enabled, and testOnly attributes; and then include values for each.
2. Using the Android documentation, list all the potential string values available for defining the reqNavigation attribute of the <uses-configuration> tag.
3. Using the Android documentation, create a list of five hardware features of the name attribute of the <uses-feature> tag.
4. Using the Android documentation, name all of the possible attributes and their value types of the <supports-screens> manifest XML tag.
5. Using the Android documentation, create a list of ten different values that could be used for defining the name attribute of the <uses-permission> manifest XML tag.
References and More Information
Android Developers Guide: “The AndroidManifest.xml File”:
http://d.android.com/guide/topics/manifest/manifest-intro.html
Android Developers Guide: “Supporting Multiple Screens”:
http://d.android.com/guide/practices/screens_support.html
Android Developers Guide: “Security Tips: Using Permissions”:
http://developer.android.com/training/articles/security-tips.html#Permissions
Android Google Services: “Filters on Google Play”:
http://d.android.com/google/play/filters.html
Android Preview: “Permissions”:
http://d.android.com/preview/features/runtime-permissions.html