Understanding Android Manifest
This is a detail tutorial that focuses on understanding android manifest. Every application ought to possess an AndroidManifest.xml file in its root directory. The manifest file offers crucial information about your app to the Android system. It is information the system cannot do without prior to its running of any of the app’s code. The android manifest does a lot of things which includes:
- Naming the Java package for the application. The package name functions as a single identifier for the application.
- Description of the constituents of the application — the activities, services, broadcast receivers, and content providers that the application is made up of. It names the classes that implement every one of the components and publishes their capacities for instance which Intentmessages they can take care of. These announcements make the Android system to be aware of what the constituents are and under what conditions they can be launched.
- The determination of which processes will host application constituents.
- Stating which permissions the application ought to possess in order to access sheltered parts of the API and communicate with other applications.
- The declaration of the permissions that others are needed to possess in order to communicate with the application’s constituents.
- Enumeration of the Instrumentation classes that make available profiling and other information while the application is running. These declarations are present in the manifest only at the time the application is being developed and tested; they’re eliminated prior to the launch of the application. It declares the minimum level of the Android API that the application requires.
- Listing the libraries that the application ought to be linked against.
A few conventions and rules are generally applicable to all elements and attributes in the manifest:
Only the <manifest> and <application> elements are needed. Every one of them ought to be present and can only be present once. The majority of the others can exist a lot of times or not at all – even though at least a few of them ought to be present for the manifest to fulfill anything meaningful.
If an element is made up of anything at all, it bears other elements. All values are set via attributes, not as character data inside an element.
Elements at the same level are in general not ordered. For instance, <activity>, <provider>, and <service>elements can be intermixed in any succession. (An <activity-alias> element is the exception to this rule: It ought to follow the <activity> it is an alias for.)
In a formal sense, every attributes are optional. Nevertheless, there are a few that ought to be specified for an element to fulfill its purpose. Make use of the documentation as a guide. For real optional attributes, it states a default value or states what occurs in the absence of a specification.
Except for a few attributes of the root <manifest> element, every attribute names start with an android: prefix — for instance, android:alwaysRetainTaskState. Due to the fact that the prefix is universal, the documentation in general passes it when referring to attributes by name.
Declaring class names
A lot of elements correspond to Java objects, which are made up of elements for the application itself (the <application>element) and its major constituents — activities (<activity>), services (<service>), broadcast receivers (<receiver>), and content providers (<provider>).
If you define a subcategory, as you would nearly do for all constituent categories (Activity, Service, BroadcastReceiver, and ContentProvider), the subcategory is specified via a name attribute. The name ought to include the full package designation. For instance, a Service subcategory may be declared as follows:
<manifest . . . > <application . . . > <service android:name="com.example.project.SecretService" . . . > </service> </application> </manifest>
Nevertheless, as shorthand, if the first character of the thread is a period, the thread is attached to the application’s package name (as shown by the <manifest> element’s package feature). The designation below is same with the example above:
<manifest package="com.example.project" . . .> <application . . . > <service android:name=".SecretService" . . . > </service> </application> </manifest>
When initiating a constituent, Android produces an example of the named subcategory. If a subclass is not specified, it produces an example of the base category.
If the values that can be specified are more than, the element is nearly at all times repeated, instead of cataloging a lot of values inside one element. For instance, an intent filter can catalog many actions:
<intent-filter . . . > <action android:name="android.intent.action.EDIT" /> <action android:name="android.intent.action.INSERT" /> <action android:name="android.intent.action.DELETE" /> . . . </intent-filter>
Values of Resource
A few attributes possess values that can be shown to users — for instance, a label and an icon for an activity. The values of these attributes ought to be localized and thus set from a resource or theme. Resource values are declared in the format below,
where the package name can be left out if the resource is in the same package as the application, type is a type of resource — like “string” or “drawable” — and name is the name that discover s the particular resource. For instance:
<activity android:icon="@drawable/smallPic" . . . >
Values from a theme are expressed in a related form, but with an initial ‘?’ instead of ‘@’:
Where an attribute value is a thread, double backslashes (‘\’) ought to be made use of to break out characters — for instance, ‘\n’ for a newline or ‘\uxxxx’ for a Unicode character.
The following sections describe how some Android features are reflected in the manifest file.
The major constituents of an application (its activities, services, and broadcast receivers) are activated by intents. An intent is a bunch of information known as an Intent object) explaining a desired action which include the data to be acted upon, the class of constituents that ought to carry out the action, and other relevant instructions. Android finds suitable constituents to react to the intent, starts a new example of the constituent if one is required and transfers it to the Intent object.
Constituents advertise their capacities — the kinds of intents they can react to — via intent filters. Since the Android system ought to study which intents a constituent can take care of before it launches the constituent, intent filters are specified in the manifest as <intent-filter> elements. A constituent may possess any number of filters, with every one of them describing a different capacity.
An intent that explicitly names a target constituent will activate that constituent; the filter doesn’t play a role. But an intent that doesn’t spell out a target by name can trigger a constituent only if it can pass through one of the constituent’s filters.
Icons and Labels
A few elements possesses icon and label attributes for a small icon and a text label that can be displayed to users. A few of them as well possess an explanation characteristic for longer explanatory text that can as well be illustrated on-screen. For example, the <permission> element has all three of these characteristics, in order that when the user is asked whether to offer the permission to an application that has requested it, an icon standing for the permission, the name of the permission, and a description of what it is all about can all be put forward to the user.
In every situation, the icon and label set in a bearing element turn into the default icon and label settings for every one of the container’s subelements. Therefore, the icon and label set in the <application> element is the default icon and label for every one of the application’s constituents. In a like manner , the icon and label set for a constituent — for instance, an <activity> element — are the default settings for every one of the constituents <intent-filter> elements. If an<application> element sets a label, but an activity and its intent filter do not, the application label is taken as the label for both the activity and the intent filter.
The icon and label set for an intent filter are used to represent a constituent whenever the constituent offered to the user as fulfilling the function advertised by the filter. For instance, a filter with “android.intent.action.MAIN” and “android.intent.category.LAUNCHER” settings launches an activity as one that sets off an application — that is, as one that ought to be displayed in the application launcher. The icon and label set in the filter are thus the ones displayed in the launcher.
A permission is a restriction that limits access to a portion of the code or to data on the device. The limitation is imposed to guard against critical data and code that may be misused to disorientate or spoil the user experience.
Every one of the permission is identified by a specific tag. Frequently, the tag shows the action that’s restricted. For instance, see below a few permissions defined by Android:
android.permission.CALL_EMERGENCY_NUMBERS android.permission.READ_OWNER_DATA android.permission.SET_WALLPAPER android.permission.DEVICE_POWER
A feature can be protected by not more than one permission.
If an application requires access to a feature shielded by a permission, it ought to specify that it needs that permission with a <uses-permission> element in the manifest. Then, when the application is installed on the device, the installer determines whether or not to grant the requested permission by examining the authorities that signed the application’s certificates and, in a few cases, asking the user. If the permission is granted, the application is capable of using the protected features. If not, its trials to access those features will merely out-rightly fail without notifying the user.
An application can as well shield its own constituents (activities, services, broadcast receivers, and content providers) with permissions. It can make use of any of the permissions defined by Android (listed in android.Manifest.permission) or specified by other applications. Or it can define its own. A new permission is granted with the <permission> element. For instance, an activity could be shielded as shown below:
<manifest . . . > <permission android:name="com.example.project.DEBIT_ACCT" . . . /> <uses-permission android:name="com.example.project.DEBIT_ACCT" /> . . . <application . . .> <activity android:name="com.example.project.FreneticActivity" android:permission="com.example.project.DEBIT_ACCT" . . . > . . . </activity> </application> </manifest>
Observe that, in this instance, the DEBIT_ACCT permission is not only specified with the <permission> element, its use is as well requested with the <uses-permission> element. Its use ought to be requested in order for other constituents of the application to launch the shielded protected activity, even though the protection is forced by the application itself.
If, in the same instance, the permission attribute was set to a permission announce at any other place like android.permission.CALL_EMERGENCY_NUMBERS, it would not have been necessary to announce it again with a<permission> element. Nevertheless, it would still have been essential to request its use with <uses-permission>.
The <permission-tree> element states a namespace for a collection of permissions that will be specified in code. And <permission-group> defines a label for a set of permissions (both those declared in the manifest with<permission> elements and those declared elsewhere). It affects only the way the permissions are classified when offered to the user. The <permission-group> element does not spell out which permissions go with the group; it merely provides the group with a name. A permission is put in the group by designating the group name to the<permission> element’s permission Group characteristic.