PAPER ON

ANDROID

BY CH.RAGHAVENDRA $. %IVA %AN$AR raghavkumar1988@gmail.c m &iva&a'kar.ci&(@)ah IV,II C%E CHAI-ANYA IN%-I-.-E O/ %CIENCE 0 -ECHNO1OGY $A$INADA .c m 991!"1!#88 98*8+*!1+!

AB%-RACThe unveiling of the Android platform on was announced with the founding of the Open Handset Alliance, a consortium of 48 hardware, software, and telecom companies devoted to advancing open standards for mobile devices. Google has made most of the Android platform available under the Apache free-software and open source license. Android is a freel downloadable open source software stac! for mobile devices that includes an operating s stem, middleware and !e applications based on "inu# and $ava. Google developed Android collaborativel as part of the Open Handset Alliance, a group of more than %& mobile and technolog companies wor!ing to open up the mobile handset environment. Android's development !it supports man of the standard pac!ages used b $ett , and so, due to that fact and $ett 's modularit and lightweight footprint, it was possible to port $ett to it so that it will be able to run on the Android platform. This paper on Android deals with the histor of the Android, the earl protot pes, basic building bloc!s of an android application and the features of the android.

I'(r 2uc(i '

Android is a software platform and operating s stem for mobile devices, based on the "inu# !ernel, and developed b Google and later the Open Handset Alliance. (t allows developers to write managed code in the $ava language, controlling the device via Google-developed $ava libraries. Applications written in ) and other languages can be compiled to A*+ native code and run, but this development path isn't officiall supported b Google. Android is available as open source. Google threw open the entire source code ,including networ! and telephon stac!s- that were not available previousl , under an Apache license. )ertain parts that relate to a specific hardware can't be made open and are not considered part of the Android platform. .ith Apache "icense, vendors are free to add proprietar e#tensions without submitting those bac! to the open source communit . .hile Google's contributions to this platform are e#pected to remain open-sourced, the branches could e#plode using varieties of licenses.

/3a(ur3& 4 A'2r i2

Ha'2&3( la) u(& Android can adapt to traditional smart phone la outs, as well other /GA, 01, and %1 graphics libraries.

%( rag3 Android uses 23"ite to store all its 4un!-- ( mean, information. C ''3c(ivi() Android supports a wide variet of technologies, including 5luetooth, .i6i, G2+781G8, and 8/-1O.

53&&agi'g ++2 and 2+2 are available for Android, as well as threaded te#t messaging. 2o ou can send as man te#ties as ou li!e.

637 Br 8&3r Android comes pre-loaded with the .eb 9it application. *emember, if ou don't li!e it, ou can alwa s switch it out for something else later on than!s to the open source nature of the Google Android bac!end.

9ava Vir(ual 5achi'3 2oftware ou write in $ava can be compiled in 1alvi! 5 te codes ,sa that five times fast. ( !eep ending up with :1anish light bulb:.- These can then be put into a 1alvi! /irtual +achine. 5asicall more robust applications are supported than on some other +obile Operating 2 stems.

532ia %u:: r( Android supports a wide range of audio, video, media, and still formats. +;8G-4, OGG, and AA) are 4ust a few of these. <nfortunatel the +edia ;la er as its !nown right now is prett basic, although more robust offerings on are the hori=on from %rd ;art developers.

A22i(i 'al Har28ar3 %u:: r( Got a touch screen ou want to put to its full use> ?o problem. Android is capable of utili=ing outside hardware li!e G;2, accelerometers, and all that other fun stuff.

Buil2i'g 7l ck& ( a' A'2r i2 a::lica(i '

There are four building bloc!s to an Android application@

Ac(ivi() Br a2ca&( I'(3'( R3c3iv3r %3rvic3 C '(3'( Pr vi23r

Ac(ivi() Activities are the most common of the four Android building bloc!s. An activit is usuall a single screen in our application. 8ach activit is implemented as a single class that e#tends the Ac(ivi() 7a&3 cla&&. Aour class will displa a user interface composed of /iews and respond to events. +ost applications consist of multiple screens. 6or e#ample, a te#t messaging application might have one screen that shows a list of contacts to send messages to, a second screen to write the message to the chosen contact, and other screens to review old messages or change settings. 8ach of these screens would be implemented as an activit . +oving to another screen is accomplished b a starting a new activit . (n some cases and activit ma return a value to the previous activit -- for e#ample an activit that lets the user pic! a photo would return the chosen photo to the caller. I'(3'( a'2 I'(3'( /il(3r& Android uses a special class called (ntent to move from screen to screen. (ntent describes what an application wants done. The two most important parts of the intent data structure are the action and the data to act upon. T pical values for action are +A(? ,the front door of the

application-, /(8., ;()9, 81(T, etc. The data is e#pressed as a <*(. 6or e#ample, to view contact information for a person, ou would create intent with the /(8. action and the data set to a <*( representing that person. There is a related class called an (ntent 6ilter. .hile an intent is effectivel a reBuest to do something, an intent filter is a description of what intents an activit ,or 5roadcast *eceiver, see below- is capable of handling. An activit that is able to displa contact information for a person would publish an (ntent 6ilter that said that it !nows how to handle the action /(8. when applied to data representing a person. Activities publish their (ntent 6ilters in the A'2r i25a'i43&(.;ml file. . The new activit is informed of the intent, which causes it to be launched. The process of resolving intents happens at run time when start Activit is called, which offers two !e benefits@

Activities can reuse functionalit from other components simpl b ma!ing a reBuest in the form of an (ntent

Activities can be replaced at an time b a new Activit with an eBuivalent (ntent 6ilter

BROADCA%- INE- RECEIVER

Aou can use a 5roadcast *eceiver when ou want code in our application to e#ecute in reaction to an e#ternal event, for e#ample, when the phone rings, or when the data networ! is available, or when it's midnight. 5roadcast *eceivers do not displa a <(, although the ma use the ?otification +anager to alert the user if something interesting has happened. 5roadcast *eceivers are registered in Android+anifest.#ml, but ou can also register them from code using C '(3;(.r3gi&(3rR3c3iv3r <=. Aour application does not have to be running for its 5roadcast*eceivers to be calledC the s stem will start our application, if necessar , when a 5roadcast*eceiver is triggered. Applications can also send their own intent broadcasts to others with C '(3;(.&3'2Br a2ca&( <=. %ERVICE A %3rvic3 is code that is long-lived and runs without a <(. A good e#ample of this is a media pla er pla ing songs from a pla list. (n a media pla er application, there would probabl be one or more activities that allow the user to choose songs and start pla ing them. However,

the music pla bac! itself should not be handled b an activit because the user will e#pect the music to !eep pla ing even after navigating to a new screen. (n this case, the media pla er activit could start a service using C '(3;(.&(ar(%3rvic3 <= to run in the bac!ground to !eep the music going. The s stem will then !eep the music pla bac! service running until it has finished. ?ote that ou can connect to a service ,and start it if it's not alread running- with the C '(3;(.7i'2%3rvic3 <= method. .hen connected to a service, ou can communicate with it through an interface e#posed b the service. 6or the music service, this might allow ou to pause, rewind, etc. CON-EN- PROVIDER Applications can store their data in files, an 23"ite database, or an other mechanism that ma!es sense. A content provider, however, is useful if ou want our application's data to be shared with other applications. A content provider is a class that implements a standard set of methods to let other applications store and retrieve the t pe of data that is handled b that content provider. ?ot ever application needs to have all four, but our application will be written with some combination of these. All the components needed for android application should listed in an #ml file called Android+anifest.#ml. This is an D+" file where ou declare the components of our application and what their capabilities and reBuirements are.

%( ri'g> R3(ri3vi'g a'2 E;: &i'g Da(a

A t pical des!top operating s stem provides a common file s stem that an application can use to store and read files that can be read b other applications. Android uses a different s stem on Android, all application data are private to that application. However, Android also provides a standard wa for an application to e#pose its private data to other applications. This section describes the man wa s that an application can store and retrieve data, e#pose its data to other applications, and also how ou can reBuest data from other applications that e#pose their data. Android provides the following mechanisms for storing and retrieving data@

Pr343r3'c3& A lightweight mechanism to store and retrieve !e 7value pairs of primitive data t pes. This is t picall used to store application preferences. /il3& Aou can store our files on the device or on a removable storage medium. 5 default, other applications cannot access these files. Da(a7a&3& The Android A;(s contain support for 23"ite. Aour application can create and use a private 23"ite database. 8ach database is private to the pac!age that creates it. C '(3'( Pr vi23r& A content provider is a optional component of an application that e#poses read7write access to an application's private data, sub4ect to whatever restrictions it wants to impose. )ontent providers implement a standard reBuest s nta# for data, and a standard access mechanism for the returned data. Android supplies a number of content providers for standard data t pes, such as personal contacts. N3(8 rk 1on't forget that ou can also use the networ! to store and retrieve data.

%3curi() a'2 P3rmi&&i '& i' A'2r i2

Android is a multi-process s stem, where each application ,and parts of the s stem- runs in its own process. +ost securit between applications and the s stem is enforced at the process level through standard "inu# facilities, such as user and group (1s that are assigned to applications. Additional finer-grained securit features are provided through a :permission: mechanism that enforces restrictions on the specific operations that a particular process can perform, and per-<*( permissions for granting ad-hoc access to specific pieces of data. %)&(3m Archi(3c(ur3 A central design point of the Android securit architecture is that no application, b default, has permission to perform an operations that would adversel impact other applications, the operating s stem, or the user. This includes reading or writing the user's private data such as

contacts or e-mails, reading or writing another application's files, performing networ! access, !eeping the device awa!e, etc. An application's process is a secure sandbo#. (t can't disrupt other applications, e#cept b e#plicitl declaring the permissions it needs for additional capabilities not provided b the basic sandbo#. These permissions it reBuests can be handled b the operating in various wa s, t picall b automaticall allowing or disallowing based on certificates or b prompting the user. The permissions reBuired b an application are declared staticall in that application, so the can be !nown up-front at install time and will not change after that. A::lica(i ' %ig'i'g All Android applications ,.ap! files- must be signed with a certificate whose private !e is held b their developer. This certificate identifies the author of the application. The certificate does not need to be signed b a certificate authorit @ it is perfectl allowable, and t pical, for Android applications to use self-signed certificates. The certificate is used onl to establish trust relationships between applications, not for wholesale control over whether an application can be installed. The most significant wa s that signatures impact securit is b determining who can access signature-based permissions and who can share user (1s. .&3r ID& a'2 /il3 Acc3&& 8ach Android pac!age ,.ap!- file installed on the device is given its own uniBue "inu# user (1, creating a sandbo# for it and preventing it from touching other applications ,or other applications from touching it-. This user (1 is assigned to it when the application is installed on the device, and remains constant for the duration of its life on that device. .&i'g P3rmi&&i '& A basic Android application has no permissions associated with it, meaning it can not do an thing that would adversel impact the user e#perience or an data on the device. To ma!e use of protected features of the device, ou must include in our Android+anifest.#ml one or more ?u&3&@:3rmi&&i 'A tags declaring the permissions that our application needs. The permissions provided b the Android s stem can be found at 5a'i43&(. :3rmi&&i '. An application ma also define and enforce its own permissions, so this is not a comprehensive list of all possible permissions.

A particular permission ma operation@

be enforced at a number of places during our program's

At the time of a call into the s stem, to prevent an application from e#ecuting certain functions.

.hen starting an activit , to prevent applications from launching activities of other applications.

5oth sending and receiving broadcasts, to control who can receive broadcast or who can send a broadcast to ou.

our

.hen accessing and operating on a content provider. 5inding or starting a service

D3clari'g a'2 E'4 rci'g P3rmi&&i '&

To enforce our own permissions, ou must first declare them in our Android+anifest.#ml using one or more ?:3rmi&&i 'A tags. The ?:r (3c(i ' 13v3lA attribute is reBuired, telling the s stem how the user is to be informed of applications reBuiring the permission, or who is allowed to hold that permission, as described in the lin!ed documentation. The ?:3rmi&&i ' Gr u:A attribute is optional, and onl used to help the s stem displa permissions to the user. Aou will usuall want to set this to either a standard s stem group ,listed in android.+anifest.permissionEgroup- or in more rare cases to one defined b ourself. (t is preferred to use an e#isting group, as this simplifies the permission <( shown to the user. ?ote that both a label and description should be supplied for the permission. These are string resources that can be displa ed to the user when the are viewing a list of permissions ,android@label- or details on a single permission , android@description-. The label should be short, a few words describing the !e piece of functionalit the permission is protecting. The description should be a couple sentences describing what the permission allows a holder to do. Our convention for the description is two sentences, the first describing the permission, the second warning the user of what bad things can happen if an application is granted the permission.

A::lica(i '& D3v3l :32 ' A'2r i2 Pla(4 rm&

(n 2eptember 0&&8, +otorola confirmed that it was wor!ing on hardware products that would run Android.

Huawei Technologies is planning to launch smart phones that would run Android in 3F 0&&G.

"enovo is wor!ing on an Android-based mobile phone that supports the )hinese %G T1-2)1+A standard.

HT) is planning a :portfolio: of Android based phones to be released summer of 0&&G.

2on 8ricsson is planning to release an Android based handset in the summer of 0&&G.

2amsung plans to offer a phone based on GoogleHs Android operating s stem in the second Buarter of 0&&G.

Gii?ii +ovit +ini is a (nternet device based on Google's Android operating s stem

C 'clu&i '
6inall we concluded that the Androids platform which has developed b Google is going to pla ma4or role in +obile applications because as it is an open source and it is also eas to develop mobile applications using Android as because in order to develop these applications all the A;(s are available and these A;(s are as same as 4ava A;(s which are eas to understand.

R343r3'c3&
"icenses Android Open Source Project. Open Handset Alliance.

http@77source.android.com7license. *etrieved on 00 October 0&&8. Open Handset Alliance ,I ?ovember 0&&J-. (ndustr http@77www.openhandsetalliance.com7pressEFF&I&J.html. *etrieved on I ?ovember 0&&J. Google's Android parts wa s with $ava industr group. http@77www.news.com78%&F-F%I8&E%-G8FI4GI-%G.html. "eaders

Announce Open ;latform for +obile 1evices. ;ress release.

General Android http@77code.google.com7android7!b7general.htmlKc. *etrieved on 0G August 0&&8. ?ative ) application for Android http@77benno.id.au7blog70&&J7FF7F%7android-native-apps.