Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
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.