Download Android Development - AndroidManenfist.xml document By Shinping R. Wang

Android Development AndroidManenfist.xml document
By Shinping R. Wang
CSIE Dept. of Da‐yeh University
Reference

The following discussion is excerpted from
Dev Guide: Android manifest document
http://developer.android.com/guide/topics/manifest/manifestintro.html
2. Intent action MAIN
http://developer.android.com/reference/android/content/Intent.
html#ACTION_MAIN
1.
The AndroidManifest.xml File


Every application must have an AndroidManifest.xml file
The file



locates at the root directory,
is an xml document,
presents essential information about the application to the
Android system.
The AndroidManifest.xml File

The application manifest document does the following:








names the Java package,
describes the components,
determines which processes will host application components(?),
declares permissions†,
declares the minimum level of the Android API,
lists the required libraries,
lists the Instrumentation classes that provide profiling and other
information as the application is running (only for debug mode)‡,
and more.
†Required permissions to access system resources as well as permission for others to access itself.
‡Should be remove when released.
Structure of the Manifest File
<?xml version="1.0" encoding="utf-8"?>
<manifest>
<uses-permission />
<permission />
<permission-tree />
<permission-group />
<instrumentation />
<uses-sdk />
<uses-configuration />
<uses-feature />
<supports-screens />
<compatible-screens />
<supports-gl-texture />
<application>
<activity>
<intent-filter>
<action />
<category />
<data />
</intent-filter>
<meta-data />
</activity>
<activity-alias>
<intent-filter> . . . </intent-filter>
<meta-data />
</activity-alias>
<service>
<intent-filter> . . . </intent-filter>
<meta-data/>
</service>
<receiver>
<intent-filter> . . . </intent-filter>
<meta-data />
</receiver>
<provider>
<grant-uri-permission />
<meta-data />
</provider>
<uses-library />
</application>
</manifest>
For best viewing effect, the
complete structure is breaking
into two parts from left to right.
The structure starts with the xml
declaration on the left.
Each element is linked to the
android developer website where
detail information about the
element is described.
Defined Elements


All the elements of the manifest file are listed below in
alphabetical order.
These are the only legal elements; you cannot add your
own elements or attributes.
<action>
<activity>
<activity-alias>
<application>
<category>
<data>
<grant-uri-permission>
<instrumentation>
<intent-filter>
<manifest>
<meta-data>
<permission>
<permission-group>
<permission-tree>
<provider>
<receiver>
<service>
<supports-screens>
<uses-configuration>
<uses-feature>
<uses-library>
<uses-permission>
<uses-sdk>
Android Manifest Document Conventions

Elements


Only <manifest> and <application> elements are required, they
each must be presented and can occur only once.
Elements at the same level are generally not ordered.

<activity>, <provider>, and <service> elements can be intermixed in
any sequence.
Android Manifest Document Conventions

Attributes

all attribute names begin with an android: prefix (except for
some attributes of the root <manifest> element)
Android Manifest Document Conventions

Declaring class names


Many elements have counterpart of Java objects, including
elements <application> ,<activity>, <service>, <receiver>, and
<provider>.
To establish the association, use full-qualify name in the
android:name attribute of the element.
<manifest . . . >
<application . . . >
<service android:name="com.example.project.SecretService" . . . >
...
</service>
...
</application>
</manifest>
File Conventions

Declaring class names


However, if ever a “.” is used at the beginning of the name
attribute such as android:name=“.SecretService"
The “.” sign expands to the package name that specified by
the <manifest> element's package attribute.
<manifest package="com.example.project" . . . >
<application . . . >
<service android:name=".SecretService" . . . >
...
</service>
...
</application>
</manifest>
File Conventions


Declaring class names
“When starting a component, Android creates an instance
of the named subclass†. If a subclass isn't specified, it
creates an instance of the base class.”

†Components activity, service, receiver, and content
provider each has its own superclass(base class) and being a
subclass of its corresponding superclass .
When the <service> is invoked, the named class
com.example.project.SecretService is
instantiated and executed. If the class is not
specified, then Service is invoked if applicable.
<manifest . . . >
<application . . . >
<service android:name="com.example.project.SecretService" . . . >
...
</service>
...
</application>
</manifest>
File Conventions


Multiple values (Check on this)
“If more than one value can be specified, the element is
almost always repeated, rather than listing multiple
values within a single element. For example, an intent
filter can list several 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>
File Conventions


Multiple values (Check on this)
However, we do see declaration like this
(com.example.android.notepad),
The usage is also documented in
http://developer.android.com/guide/topics/manifest/activit
y-element.html
File Conventions

Resource values


Attributes having value of multiple contents (e.g. character
encoding) should be set from a resource or theme.
Resource values are expressed in the following format,
@[package:]type:name




Package can be omitted if same to the current application,
type is a type of resource ( such as "string" or "drawable“),
name is the name that identifies the specific resource.
For example:
<activity android:icon="@drawable/smallPic" . . . >
File Conventions

Theme values

start with an initial '?' rather than ‘@':
?[package:]type:name
File Conventions

String values

When an attribute value is a string, double backslashes ('\\')
must be used to escape characters — for example, '\\n' for a
newline or '\\uxxxx' for a Unicode character.
File Features

The core components of an application (its activities,
services, and broadcast receivers) are activated by intents.
File Features

Intent Filters versus Intent Object



The component that requesting helps sends and intent Object
through different methods that pending one different types of
requesting helps (activity, service, content provider)
The component that delivering helps registers its capability in
the intent filter of it’s manifest document.
The Android system plays as the help agent.
File Features

An intent is a bundle of information (an Intent object)
describing




desired action,
the data to be acted upon,
the category of component that should perform the action,
and
others.
File Features

Android system locates an appropriate component to
respond to the intent, launches a new instance of the
component if one is needed, and passes it the Intent
object.
File Features

Components advertise their capabilities — the kinds of intents
they can respond to — through intent filters.
<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>
Explicitly and implicitly

An intent object may either be Explicit Intents or Implicit
Intents



explicitly intent names the intended target component.
implicitly intent sends out generic action, data, and category
information without mentioning the name of the intended
target component,
For the implicit intent , the android system will filtering out the
candidate component(s) for the task using the intent filter
declared in the manifest document of all the installed
components.
File Features

Each Worker submitting his resume
File Features

One of the worker request for help
I need help with this “Intent.”
File Features

The foreman looks for proper worker
File Features

The foreman assigns the work to specific worker(s)
Icons and Labels

A number of elements have icon and label attributes for
displaying.
Icons and Labels


the icon and label set in a container element become the
default icon and label for all of the containing
subelements.
icon and label set in a subelement overwrite its container
Foo.AndroidManifest.xml
default.
:
<application
<application>
android:name=“foo”
android:icon=“@drawable/icon_0”
android:label=“@staring/title_1”
<activity>
:
<activity
android:name=“bar”
android:icon”@drawable/icon_1”
android:label=“@string/tltle_1”
<other components>
:
<\activity>
:
[other components..]
:
<\application>
:
Icons and Labels

For example
Foo.AndroidManifest.xml
:
<application
android:name=“foo”
android:icon=“@drawable/icon_0”
android:label=“@staring/title_1”
:
<activity
android:name=“bar”
android:icon”@drawable/icon_1”
android:label=“@string/tltle_1”
:
<\activity>
:
[other elements..]
:
<\application>
:
The icon and label (icon_0, title_0) attributes of the application foo
is default for all containing subelements.
However, if there is a new setting in a subelement of foo, such as
the ones in activity bar (icon_1, title_1), then they will supersedes
those given by foo.
Icons and Labels

A real AndroidManifest.xml doc. From notepad.
App_notes
Live_folder_notes
This is the notepad sample of the Android
SDK. We see several android:icon attributes
in different part of the Manifest document.
Icons and Labels

A real AndroidManifest.xml doc. From notepad.
This is the part of android:label. We see
several occurrences of the attribute in
different part of the document.
The attribute in the intent-filter at line 85
overwrite the one in activity at line 78 and
the one in application at line 26.
Icons and Labels
Again, the attribute label in line 103
supersedes the default one given in element
application at line 26.
Permissions

The permission element limits application to access
protected API or data on the device.
Permission : Why permission is important?
Open & $
Permissions


The scheme
When developing


During installation


an application must requests protected APIs in its manifest
with a <uses-permission> element. It may also protects itself
by setting <permission> elements.
the system displays a dialog to the user and requests device
owner’s permissions for accessing these protected APIs .
The owner

can either grants all of the requested permissions, or denies
them .
Permissions
Permissions at Application Install - Google Maps
Permissions of an Installed
Application -- gMail
Permissions

An application can also protect its own components
(activities, services, broadcast receivers, and content
providers) with permissions.
Permissions



It can employ any of the permissions defined by Android
(listed in android.Manifest.permission) or declared by
other applications. Or it can define its own.
A new permission is declared with the <permission>
element.
See the following example.
Permissions

For Example
<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>
“Note that, in this example, the DEBIT_ACCT permission is not only declared with the <permission> element, its use is
also requested with the <uses-permission> element. Its use must be requested in order for other components of the
application to launch the protected activity, even though the protection is imposed by the application itself.”
This says, the app locks the lock(permission). The very same app has to unlock the lock itself so that all components
of the app can use the locked resource.
Permissions

For Example
<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>
“If, in the same example, the permission attribute was set to a permission declared elsewhere (such as
android.permission.CALL_EMERGENCY_NUMBERS, it would not have been necessary to declare it again with a
<permission> element. However, it would still have been necessary to request its use with <uses-permission>. ”
Permissions



The <permission> works like a lock.
To unlock the protected APIs, uses <use_permission>.
The is a premature analogy, watch for exceptions!!
Permissions

<permission-tree> element


declares a namespace for a group of permissions that will be
defined in code.
<permission-group> element


defines a label for a set of permissions (both those declared in
the manifest with <permission> elements and those declared
elsewhere)
A permission is placed in the group by assigning the group
name to the <permission> element's permissionGroup
attribute.
Libraries

The default/core Android library,


is linked by default
includes the basic packages for building applications (with
common classes such as Activity, Service, Intent, View, Button,
Application, ContentProvider, and so on).
Libraries

There exists third party/customary libraries.


When application use code from any of these packages, the
application must explicitly asked to be linked against them.
This is done by adding a separate <uses-library> element to
name each of the libraries. (The library name can be found in
the documentation for the package.)
Libraries

Example, from com.example.android.notepad.tests
An complete example
com.example.android.notepad
An complete example
com.example.android.notepad
An complete example
com.example.android.notepad
An complete example
com.example.android.notepad
An complete example
com.example.android.notepad

The first activity, com.android.notepad.NotesList, serves
as our main entry into the app.