ANDROID OPERATING SYSTEM

A Seminar Report
submitted in partial fulfillment of
requirements for the award of the degree of
BACHELOR OF TECHNOLOGY
in
INFORMATION TECHNOLOGY
by
Mr. G.SUJIT VARMA
(07331A1216)

Under the esteemed guidance of

Mr. D. Nagendra Kumar ,

Assistant professor ,
Department of IT,
M.V.G.R. College of Engineering,
Vizianagaram

Department of Information Technology

MAHARAJ VIJAYARAM GAJAPATHIRAJ COLLEGE OF ENGINEERING
(Affiliated to Jawaharlal Nehru Technological University, Kakinada)
VIZIANAGARAM

2010-2011

DECLARATION

I hereby declare that the work done on the dissertation entitled ANDROID OPERATING
SYSTEM has been carried by me and submitted in partial fulfillment for the award of
degree of Bachelor of Technology in Information Technology, M.V.G.R. College of Engineering,
Vizianagaram, year 2007-2011.

The various contents incorporated in the dissertation have not been submitted for the award
of any other degree of any other institution or university.

Mr. G. SUJIT VARMA

(07331A1216)

M.V.G.R. COLLEGE OF ENGINEERING,

CHINTALAVALASA
DEPARTMENT OF INFORMATION TECHNOLOGY

CERTIFICATE
This is to certify that this seminar report entitled ANDROID OPERATING SYSTEM is a bonafide
record of work done by
Mr. G.SUJIT VARMA
(07331A1216)
of B-Tech final year in the Department of Information Technology during the acadamic year
11.

Mr. D. Nagendra Kumar ,

Assistant professor ,
Department of IT,
M.V.G.R. College of Engineering,
Vizianagaram

Prof. P.S.Sitharama Raju,

Head of the Department,
Department of IT,
M.V.G.R College of Engineering,

2010-

Vizianagaram.

ACKNOWLEDGEMENT
We are grateful to Mr. D. Nagendra kumar, Assistant Professor , department of
Information Technology who has been our guides, for their unfailing and fostering efforts and
personal involvement, which motivated us to a great extent.
We owe our project to Prof. P.S.Sitharama Raju, Head of the department, Information Technology
for his valuable suggestions and constant motivation that greatly helped the seminar work to get
successfully completed. We sincerely thank him for the lab facilities and other resources he provided
us and the constant support he gave us.
We also thank Dr. K.L.V.Raju, Principal, M.V.G.R College of Engineering, for his generosity and
extending his utmost support and cooperation in providing all the provisions for successful
completion of the seminar work. We sincerely thank all the members of the staff on the Department
of Information Technology for their sustained help in our pursuits. We thank all who has contributed
directly or indirectly in successfully carrying out this work.

Mr. G.SUJIT VARMA

(07331A1216)

ABSTRACT
The 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 freely downloadable open source software stack for mobile devices that
includes an operating system, middleware and key applications based on Linux and Java.
Google developed Android collaboratively as part of the Open Handset Alliance, a
group of more than 30 mobile and technology companies working to open up the mobile handset
environment. Android's development kit supports many of the standard packages used by Jetty, and
so, due to that fact and Jetty's modularity and lightweight footprint, it was possible to port Jetty to it
so that it will be able to run on the Android platform.
This paper on Android deals with the history of the Android, the early prototypes,
basic building blocks of an android application and the features of the android.

CONTENTS

1. INTRODUCTION
2. FETURES OF ANDROID
3. BUILDING BLOCKS
4. HARDWARE AND SOFTWARE RUNNING ANDROID
5. STORING, RETREIVING AND EXPOSING DATA
6. SECURITY AND PERMISSIONS IN ANDROID
7. SYSTEM ARCHITECTURE
8. APPLICATIONS DEVELOPED ON ANDROID PLATFORM
9. CONCLUSION
10. REFERENCES

INTRODUCTION
Android is a software platform and operating system for mobile devices, based on the
Linux kernel, and developed by Google and later the Open Handset Alliance. It allows developers to
write managed code in the Java language, controlling the device via Google-developed Java libraries.
Applications written in C and other languages can be compiled to ARM native code and run, but this
development path isn't officially supported by Google.
Android is available as open source. Google threw open the entire source code (including
network and telephony stacks) that were not available previously, under an Apache license. Certain
parts that relate to a specific hardware can't be made open and are not considered part of the Android
platform. With Apache License, vendors are free to add proprietary extensions without submitting
those back to the open source community. While Google's contributions to this platform are expected
to remain open-sourced, the branches could explode using varieties of licenses.

FEATURES OF ANDROID

Handset layouts Android can adapt to traditional smart phone layouts, as well other VGA,
2D, and 3D graphics libraries.

Storage Android uses SQLite to store all its junk-- I mean, information.

Connectivity Android supports a wide variety of technologies, including Bluetooth, WiFi,

GSM/EDGE, and EV-DO.

Messaging MMS and SMS are available for Android, as well as threaded text messaging. So
you can send as many texties as you like.

Web Browser Android comes pre-loaded with the Web Kit application. Remember, if you
don't like it, you can always switch it out for something else later on thanks to the open
source nature of the Google Android backend.

Java Virtual Machine Software you write in Java can be compiled in Dalvik Byte codes
(say that five times fast. I keep ending up with "Danish light bulb".) These can then be put
into a Dalvik Virtual Machine. Basically more robust applications are supported than on some
other Mobile Operating Systems.

Media Support Android supports a wide range of audio, video, media, and still formats.
MPEG-4, OGG, and AAC are just a few of these. Unfortunately the Media Player as its
known right now is pretty basic, although more robust offerings on are the horizon from 3rd
Party developers.

Additional Hardware Support Got a touch screen you want to put to its full use? No
problem. Android is capable of utilizing outside hardware like GPS, accelerometers, and all
that other fun stuff.

BUILDING BLOCKS
There are four building blocks to an Android application:

Activity

Broadcast Intent Receiver

Service

Content Provider

Activity
Activities are the most common of the four Android building blocks. An activity is usually a
single screen in your application. Each activity is implemented as a single class that extends the
Activity base class. Your class will display a user interface composed of Views and respond to
events. Most applications consist of multiple screens. For example, a text 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. Each of
these screens would be implemented as an activity. Moving to another screen is accomplished by a
starting a new activity. In some cases and activity may return a value to the previous activity -- for
example an activity that lets the user pick a photo would return the chosen photo to the caller.

Intent and Intent Filters

Android uses a special class called Intent to move from screen to screen. Intent 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. Typical values for action are MAIN (the front door of the
application), VIEW, PICK, EDIT, etc. The data is expressed as a URI. For example, to view contact
information for a person, you would create intent with the VIEW action and the data set to a URI
representing that person.

There is a related class called an Intent Filter. While an intent is effectively a request to do
something, an intent filter is a description of what intents an activity (or Broadcast Receiver, see
below) is capable of handling. An activity that is able to display contact information for a person
would publish an Intent Filter that said that it knows how to handle the action VIEW when applied to
data representing a person. Activities publish their Intent Filters in the AndroidManifest.xml file.
.
The new activity is informed of the intent, which causes it to be launched. The process of resolving
intents happens at run time when start Activity is called, which offers two key benefits:

Activities can reuse functionality from other components simply by making a request in the
form of an Intent

Activities can be replaced at any time by a new Activity with an equivalent Intent Filter

Broadcast Receiver:

You can use a Broadcast Receiver when you want code in your application to execute in
reaction to an external event, for example, when the phone rings, or when the data network is
available, or when it's midnight. Broadcast Receivers do not display a UI, although they may use the
Notification Manager to alert the user if something interesting has happened. Broadcast Receivers
are registered in AndroidManifest.xml, but you can also register them from code using
Context.registerReceiver (). Your application does not have to be running for its
BroadcastReceivers to be called; the system will start your application, if necessary, when a
BroadcastReceiver is triggered. Applications can also send their own intent broadcasts to others with
Context.sendBroadcast ().
Service:
A Service is code that is long-lived and runs without a UI. A good example of this is a media
player playing songs from a play list. In a media player application, there would probably be one or
more activities that allow the user to choose songs and start playing them. However, the music
playback itself should not be handled by an activity because the user will expect the music to keep
playing even after navigating to a new screen. In this case, the media player activity could start a
service using Context.startService () to run in the background to keep the music going. The system
will then keep the music playback service running until it has finished. Note that you can connect to

a service (and start it if it's not already running) with the Context.bindService () method. When
connected to a service, you can communicate with it through an interface exposed by the service. For
the music service, this might allow you to pause, rewind, etc.
Content Provider:
Applications can store their data in files, an SQLite database, or any other mechanism that
makes sense. A content provider, however, is useful if you want your 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 type of data that is handled by that content provider.
Not every application needs to have all four, but your application will be written with some
combination of these.
All the components needed for android application should listed in an xml file called
AndroidManifest.xml. This is an XML file where you declare the components of your application
and what their capabilities and requirements are.

HARDWARE AND SOFTWARE RUNNING ANDROID

Hardware running Android
The Android OS can be used as an operating system for cell phones, net books and tablet
PCs, including the Dell Streak, Samsung Galaxy Tab and other devices.
The world's first TV running Android, called Scandinavia, has also been launched by the
company People of Lava.
The first commercially available phone to run the Android operating system was the HTC
Dream, released on 22 October 2008.
Google's flagship smart phones
Android phones that are sold and marketed by Google.

Nexus One manufactured by HTC

Nexus S manufactured by Samsung

Software development:

Early Android device.

The early feedback on developing applications for the Android platform was mixed. [78] Issues
cited include bugs, lack of documentation, inadequate QA infrastructure, and no public issuetracking system. (Google announced an issue tracker on 18 January 2008.) [79] In December 2007,
MergeLab mobile startup founder Adam MacBeth stated, "Functionality is not there, is poorly
documented or just doesn't work... It's clearly not ready for prime time." Despite this, Androidtargeted applications began to appear the week after the platform was announced. The first publicly
available application was the Snake game.[81][82] The Android Dev Phone is a SIM-unlocked and
hardware-unlocked device that is designed for advanced developers. While developers can use
regular consumer devices purchased at retail to test and use their applications, some developers may
choose not to use a retail device, preferring an unlocked or no-contract device.
Software development kit
The Android software development kit (SDK) includes a comprehensive set of development
tools.[83] These include a debugger, libraries, a handset emulator (based on QEMU), documentation,
sample code, and tutorials. Currently supported development platforms include computers running
Linux (any modern desktop Linux distribution), Mac OS X 10.4.9 or later, Windows XP or later. The
officially supported integrated development environment (IDE) is Eclipse (currently 3.4 or 3.5) using
the Android Development Tools (ADT) Plug-in, though developers may use any text editor to edit
Java and XML files then use command line tools (Java Development Kit and Apache Ant are
required) to create, build and debug Android applications as well as control attached Android devices
(e.g., triggering a reboot, installing software package(s) remotely).
A preview release of the Android SDK was released on 12 November 2007. On 15 July 2008,
the Android Developer Challenge Team accidentally sent an email to all entrants in the Android
Developer Challenge announcing that a new release of the SDK was available in a "private"
download area. The email was intended for winners of the first round of the Android Developer
Challenge. The revelation that Google was supplying new SDK releases to some developers and not
others (and keeping this arrangement private) led to widely reported frustration within the Android
developer community at the time.
On 18 August 2008 the Android 0.9 SDK beta was released. This release provided an updated
and extended API, improved development tools and an updated design for the home screen. Detailed

instructions for upgrading are available to those already working with an earlier release. On 23
September 2008 the Android 1.0 SDK (Release 1) was released. Enhancements to Android's SDK go
hand in hand with the overall Android platform development. The SDK also supports older versions
of the Android platform in case developers wish to target their applications at older devices.
Development tools are downloadable components, so after one has downloaded the latest version and
platform, older platforms and tools can also be downloaded for compatibility testing.
Android applications are packaged in .apk format and stored under /data/app folder on the
Android OS (the folder is accessible to root user only for security reasons). APK package contains
.dex files (compiled byte code files called Dalvik executable), resource files, etc.

STORING,RETREIVING AND EXPOSING DATA

A typical desktop operating system provides a common file system that any application can
use to store and read files that can be read by other applications. Android uses a different system on
Android, all application data are private to that application. However, Android also provides a
standard way for an application to expose its private data to other applications. This section describes
the many ways that an application can store and retrieve data, expose its data to other applications,
and also how you can request data from other applications that expose their data.
Android provides the following mechanisms for storing and retrieving data:
Preferences :
A lightweight mechanism to store and retrieve key/value pairs of primitive data types.
This is typically used to store application preferences.
Files :
You can store your files on the device or on a removable storage medium. By default,
other applications cannot access these files.
Databases :
The Android APIs contain support for SQLite. Your application can create and use a
private SQLite database. Each database is private to the package that creates it.
Content Providers :
A content provider is a optional component of an application that exposes read/write
access to an application's private data, subject to whatever restrictions it wants to impose.
Content providers implement a standard request syntax for data, and a standard access
mechanism for the returned data. Android supplies a number of content providers for
standard data types, such as personal contacts.
Network :
Don't forget that you can also use the network to store and retrieve data.

SECURITY AND PERMISSIONS IN ANDROID

Android is a multi-process system, where each application (and parts of the system) runs in
its own process. Most security between applications and the system is enforced at the process level
through standard Linux facilities, such as user and group IDs that are assigned to applications.
Additional finer-grained security features are provided through a "permission" mechanism that
enforces restrictions on the specific operations that a particular process can perform, and per-URI
permissions for granting ad-hoc access to specific pieces of data.

SYSTEM ARCHITECTURE
A central design point of the Android security architecture is that no application, by default,
has permission to perform any operations that would adversely impact other applications, the
operating system, 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 network access, keeping the
device awake, etc.
An application's process is a secure sandbox. It can't disrupt other applications, except by
explicitly declaring the permissions it needs for additional capabilities not provided by the basic
sandbox. These permissions it requests can be handled by the operating in various ways, typically by
automatically allowing or disallowing based on certificates or by prompting the user. The
permissions required by an application are declared statically in that application, so they can be
known up-front at install time and will not change after that.
Application Signing:
All Android applications (.apk files) must be signed with a certificate whose private key is held
by their developer. This certificate identifies the author of the application. The certificate does not
need to be signed by a certificate authority: it is perfectly allowable, and typical, for Android
applications to use self-signed certificates. The certificate is used only to establish trust relationships
between applications, not for wholesale control over whether an application can be installed. The
most significant ways that signatures impact security is by determining who can access signaturebased permissions and who can share user IDs.
User IDs and File Access:
Each Android package (.apk) file installed on the device is given its own unique Linux user
ID, creating a sandbox for it and preventing it from touching other applications (or other applications
from touching it). This user ID is assigned to it when the application is installed on the device, and
remains constant for the duration of its life on that device.

Using Permissions:
A basic Android application has no permissions associated with it, meaning it can not do
anything that would adversely impact the user experience or any data on the device. To make use of
protected features of the device, you must include in your AndroidManifest.xml one or more <usespermission> tags declaring the permissions that your application needs.
The permissions provided by the Android system can be found at Manifest. permission. Any
application may also define and enforce its own permissions, so this is not a comprehensive list of all
possible permissions.
A particular permission may be enforced at a number of places during your program's operation:

At the time of a call into the system, to prevent an application from executing certain
functions.

When starting an activity, to prevent applications from launching activities of other

applications.

Both sending and receiving broadcasts, to control who can receive your broadcast or
who can send a broadcast to you.

When accessing and operating on a content provider.

Binding or starting a service

Declaring and Enforcing Permissions:

To enforce your own permissions, you must first declare them in your AndroidManifest.xml
using one or more <permission> tags.
The <protection Level> attribute is required, telling the system how the user is to be
informed of applications requiring the permission, or who is allowed to hold that permission, as
described in the linked documentation.
The <permission Group> attribute is optional, and only used to help the system display
permissions to the user. You will usually want to set this to either a standard system group (listed in
android.Manifest.permission_group) or in more rare cases to one defined by yourself. It is preferred
to use an existing group, as this simplifies the permission UI shown to the user.

Note that both a label and description should be supplied for the permission. These are string
resources that can be displayed to the user when they 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 key piece of functionality 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.

APPLICATIONS DEVELOPED ON ANDROID PLATFORM

In September 2008, Motorola confirmed that it was working on hardware products that would
run Android.

Huawei Technologies is planning to launch smart phones that would run Android in Q1 2009.

Lenovo is working on an Android-based mobile phone that supports the Chinese 3G TDSCDMA standard.

HTC is planning a "portfolio" of Android based phones to be released summer of 2009.

Sony Ericsson is planning to release an Android based handset in the summer of 2009.

Samsung plans to offer a phone based on Googles Android operating system in the second
quarter of 2009.

GiiNii Movit Mini is a Internet device based on Google's Android operating system

CONCLUSION
Finally we concluded that the Androids platform which has developed by Google is going to
play major role in Mobile applications because as it is an open source and it is also easy to develop
mobile applications using Android as because in order to develop these applications all the APIs are
available and these APIs are as same as java APIs which are easy to understand.

REFERENCES
Licenses Android Open Source Project. Open Handset Alliance.
http://source.android.com/license. Retrieved on 22 October 2008.
Open Handset Alliance (5 November 2007). Industry Leaders Announce Open Platform
for Mobile Devices. Press release.
http://www.openhandsetalliance.com/press_110507.html. Retrieved on 5 November 2007.

Google's Android parts ways with Java industry group. http://www.news.com/830113580_3-9815495-39.html.

General Android http://code.google.com/android/kb/general.html#c. Retrieved on 29

August 2008.

Native C application for Android http://benno.id.au/blog/2007/11/13/android-native-apps.