What is Android?
Android is a software stack for mobile devices that includes
an operating system, middleware and key applications.
It is based on the Linux operating system and developed by
Google and the Open Handset Alliance.
It allows developers to write applications in Java using
Google-developed Android SDK.
It uses the Dalvik virtual machine with just-in-time
compilation to run Dalvik bytecode.
There are currently approximately 300,000 apps available
for Android, from a total of 500,000 apps over the life of
Apps can be downloaded from third-party sites or through
online stores such as Android Market, the app store run by
Android, Inc. was founded in Palo Alto, California,
United States in October, 2003 by Andy Rubin (co-
founder of Danger), Rich Miner (co-founder of
Wildfire Communications, Inc.), Nick Sears (once VP
at T-Mobile), and Chris White (headed design and
interface development at WebTV).
Despite the obvious past accomplishments of the
founders and early employees, Android Inc. operated
secretly, revealing only that it was working on
software for mobile phones.
Acquisition by Google
Google acquired Android Inc. in August 2005, making
Android Inc. a wholly owned subsidiary of Google Inc.
Key employees of Android Inc., including Andy
Rubin, Rich Miner and Chris White, stayed at the
company after the acquisition.
Not much was known about Android Inc. at the time
of the acquisition, but many assumed that Google
was planning to enter the mobile phone market with
At Google, the team led by Rubin developed a mobile
device platform powered by the Linux kernel.
Google marketed the platform to handset makers and
carriers on the premise of providing a flexible,
Google had lined up a series of hardware component
and software partners and signaled to carriers that it
was open to various degrees of cooperation on their
Open Handset Alliance
On November 5, 2007, the Open Handset Alliance, a
consortium of several companies which include Broadcom
Corporation, Google, HTC, Intel, LG, Marvell Technology
Group, Motorola, Nvidia, Qualcomm, Samsung Electronics,
Sprint Nextel, T-Mobile and Texas Instruments unveiled
The goal of the Open Handset Alliance is to develop open
standards for mobile devices. On the same day, the Open
Handset Alliance also unveiled their first product, Android,
a mobile device platform built on the Linux kernel version
On December 9, 2008, 14 new members joined, including
ARM Holdings, Atheros Communications, Asustek
Computer Inc, Garmin Ltd, Huawei Technologies,
PacketVideo, Softbank, Sony Ericsson, Toshiba Corp, and
Vodafone Group Plc.
With the exception of brief update periods, Android has
been available under free and open source software
licenses from October 21, 2008.
Google published the source code for their Linux kernel
changes under the GNU General Public License version 2,
and the rest of the code under the Apache License version
Google also keeps the reviewed issues list publicly open for
anyone to see and comment.
Even though the software is open source, device
manufacturers cannot use Google's Android trademark
unless Google certifies that the device complies with their
Compatibility Definition Document (CDD).
Devices must also meet this definition to be eligible to
license Google's closed-source applications, including the
Android has seen a number of updates since its
original release, each fixing bugs and adding new
features. Each version is named, in alphabetical
order, after a dessert.
2.3 Gingerbread is the latest Android version that is
available to phones.
3.0 Honeycomb was a tablet-orientated release.
4.0 Ice Cream Sandwich, announced on October 19, 2011,
brought Honeycomb features to smart phones and added
new features including facial recognition unlock, network
data usage monitoring and control, unified social
networking contacts, photography enhancements, offline
email searching, and information sharing using NFC.
It is used to write applications for Android.
Unlike other embedded mobile environments,
Android applications are all equal, for instance,
an applications which come with the phone are no
different than those that any developer writes.
The framework is supported by numerous open
source libraries such as openssl, SQLite, etc.
It is also supported by the Android core libraries.
From the point of security, the framework is
based on UNIX file system permissions that assure
applications have only those abilities that mobile
phone owner gave them at install time.
Dalvik Virtual Machine
The Dalvik virtual machine is a register-based virtual
machine, designed and written by Dan Bornstein with
contributions from other Google engineers as part of the
Android mobile phone platform.
It is optimized for low memory requirements, and is
designed to allow multiple VM instances to run at once,
relying on the underlying operating system for process
isolation, memory management and threading support.
Dalvik is often referred to as a Java Virtual Machine, but
this is not strictly accurate, as the bytecode on which it
operates is not Java bytecode.
Instead, a tool named dx, included in the Android SDK,
transforms the Java Class files of Java classes compiled by
a regular Java compiler into another class file format (the
The web browser available in Android is based on the
open-source WebKit layout engine.
They added a two pass layout and frame flattening.
Two pass layout loads a page without waiting for
blocking elements, such as external CSS or
with all resources downloaded to the device.
Frame flattening converts founded frames into
single one and loads into the browser.
These features increase speed and usability
browsing the internet via mobile phone.
As Android supports 2D graphics and 3D graphics,
possibly we will see great applications like
Google Earth and spectacular games like Second
Life, which come on Linux version.
At this moment, the shooting legendary 3D game
Doom was presented using Android on the mobile
SQLite is used for structured data storage.
SQLite is a powerful and lightweight relational
database engine available to all applications
It is integrated in Android.
It is based on function calls and single file, where all
definitions, tables and data are stored.
This simple design is more than suitable for a
platform such as Android.
The platform is adaptable to both larger, VGA, 2D
graphics library, 3D graphics library based on
OpenGL ES 1.0 specifications, traditional smart
Surface Manager manages access to the display
subsystem and seamlessly composites 2D and 3D
graphic layers from multiple applications.
Android supports a wide variety of connectivity
technologies including GSM, CDMA, Bluetooth,
EDGE, EVDO, 3G, 4G and Wi-Fi.
Includes a device emulator, tools for debugging,
memory and performance profiling, a plugin for the
Eclipse IDE. A great work was done for the
developers to start work with Android using
There are a number of hardware dependent
features, for instance, a huge media and
connections support, GPS, improved support for
Camera and simply GSM telephony.
Android will support common audio, video, and still
media formats such as MPEG-4, H.264, MP3, and
AAC, AMR, JPEG, PNG, GIF.
Streaming Media Support
RTP/RTSP streaming (3GPP PSS, ISMA), HTML
progressive download (HTML5 <video> tag).
Adobe Flash Streaming (RTMP) and HTTP Dynamic
Streaming are supported by the Flash plug-in.
Apple HTTP Live Streaming is supported by
RealPlayer for Mobile, and by the operating system
in Android 3.0 (Honeycomb).
Android has native support for multi-touch which was
initially made available in handsets such as the HTC Hero.
The feature was originally disabled at the kernel level
Google has since released an update for the Nexus One and
the Motorola Droid which enables multi-touch natively.
Supports A2DP, AVRCP, sending files (OPP), accessing the
phone book (PBAP), voice dialing and sending contacts
Keyboard, mouse and joystick (HID) support is available in
Android 3.1+, and in earlier versions through
manufacturer customizations and third-party applications.
Multitasking of applications is available.
SMS, MMS, and XMPP are available forms of
messaging including threaded text messaging.
Additional Hardware Support
Android can use video/still cameras, touch screens,
GPS, accelerometers, gyroscopes, barometers,
magnetometers, dedicated gaming controls, proximity
and pressure sensors, thermometers, etc.
The diagram in the next slide shows the major
components of the Android operating system.
Each section is described in more detail below.
At the top of Android Architecture we have all
the applications, which are used by the final user.
By installing different applications, the user can
turn his mobile phone into the unique, optimized
and smart mobile phone.
Android ships with a set of core applications
including an email client, SMS program,
calendar, maps, browser, contacts, and others.
All applications are written using the Java
By providing an open development platform, Android offers
developers the ability to build extremely rich and
Developers are free to take advantage of the device
hardware, access location information, run background
services, set alarms, add notifications to the status bar, and
much, much more.
Developers have full access to the same framework APIs
used by the core applications.
The application architecture is designed to simplify the
reuse of components; any application can publish its
capabilities and any other application may then make use
of those capabilities (subject to security constraints
enforced by the framework).
Underlying all applications is a set of services and
A rich and extensible set of Views that can be used to build
an application, including lists, grids, text boxes, buttons,
and even an embeddable web browser.
Content Providers that enable applications to access data
from other applications (such as Contacts), or to share their
A Resource Manager, providing access to non-code
resources such as localized strings, graphics, and layout
A Notification Manager that enables all applications to
display custom alerts in the status bar.
An Activity Manager that manages the lifecycle of
applications and provides a common navigation back stack.
System C library
a BSD-derived implementation of the standard C system
library (libc), tuned for embedded Linux-based devices.
based on PacketVideo's OpenCORE; the libraries support
playback and recording of many popular audio and video
formats, as well as static image files, including MPEG4,
H.264, MP3, AAC, AMR, JPG, and PNG.
manages access to the display subsystem and seamlessly
composites 2D and 3D graphic layers from multiple
a modern web browser engine which powers both the Android
browser and an embeddable web view.
the underlying 2D graphics engine.
an implementation based on OpenGL ES 1.0 APIs; the
libraries use either hardware 3D acceleration (where
available) or the included, highly optimized 3D software
bitmap and vector font rendering.
a powerful and lightweight relational database engine
available to all applications.
Android includes a set of core libraries that
provides most of the functionality available in the
core libraries of the Java programming language.
Every Android application runs in its own
process, with its own instance of the Dalvik
Dalvik has been written so that a device can run
multiple VMs efficiently.
The Dalvik VM executes files in the Dalvik
Executable (.dex) format which is optimized for
minimal memory footprint.
The VM runs classes compiled by a Java
language compiler that have been transformed
into the .dex format by the included "dx" tool.
The Dalvik VM relies on the Linux kernel for
underlying functionality such as threading and
low-level memory management.
Android relies on Linux version 2.6 for core
system services such as security, memory
management, process management, network
stack, and driver model.
The kernel also acts as an abstraction layer
between the hardware and the rest of the
Android applications are written in the Java
The Android SDK tools compile the code—along
with any data and resource files—into an
Android package, an archive file with an .apk
All the code in a single .apk file is considered to
be one application and is the file that Android-
powered devices use to install the application.
Once installed on a device, each Android application
lives in its own security sandbox:
The Android operating system is a multi-user Linux
system in which each application is a different user.
By default, the system assigns each application a unique
Linux user ID (the ID is used only by the system and is
unknown to the application). The system sets permissions
for all the files in an application so that only the user ID
assigned to that application can access them.
Each process has its own virtual machine (VM), so an
application's code runs in isolation from other applications.
By default, every application runs in its own Linux process.
Android starts the process when any of the application's
components need to be executed, then shuts down the
process when it's no longer needed or when the system
must recover memory for other applications.
In this way, the Android system implements the
principle of least privilege.
That is, each application, by default, has access
only to the components that it requires to do its
work and no more.
This creates a very secure environment in which
an application cannot access parts of the system
for which it is not given permission.
However, there are ways for an application to
share data with other applications and for an
application to access system services:
It's possible to arrange for two applications to share
the same Linux user ID, in which case they are able
to access each other's files. To conserve system
resources, applications with the same user ID can
also arrange to run in the same Linux process and
share the same VM (the applications must also be
signed with the same certificate).
An application can request permission to access
device data such as the user's contacts, SMS
messages, the mountable storage (SD card), camera,
Bluetooth, and more. All application permissions
must be granted by the user at install time.
That covers the basics regarding how an Android
application exists within the system. The rest of
this document introduces to:
The core framework components that define our
The manifest file in which we declare components
and required device features for our application.
Resources that are separate from the application code
and allow our application to gracefully optimize its
behavior for a variety of device configurations.
Application components are the essential
building blocks of an Android application.
Each component is a different point through
which the system can enter your application.
Not all components are actual entry points for
the user and some depend on each other, but
each one exists as its own entity and plays a
specific role—each one is a unique building block
that helps define your application's overall
There are four different types of application
Each type serves a distinct purpose and has a
distinct lifecycle that defines how the component
is created and destroyed.
Here are the four types of application
An activity represents a single screen with a user
interface. For example, an email application might
have one activity that shows a list of new emails,
another activity to compose an email, and another
activity for reading emails.
Although the activities work together to form a
cohesive user experience in the email application,
each one is independent of the others.
As such, a different application can start any one of
these activities (if the email application allows it).
For example, a camera application can start the
activity in the email application that composes new
mail, in order for the user to share a picture.
A service is a component that runs in the background
to perform long-running operations or to perform
work for remote processes.
A service does not provide a user interface. For
example, a service might play music in the
background while the user is in a different
application, or it might fetch data over the network
without blocking user interaction with an activity.
Another component, such as an activity, can start the
service and let it run or bind to it in order to interact
A content provider manages a shared set of application
data. You can store the data in the file system, an SQLite
database, on the web, or any other persistent storage
location your application can access.
Through the content provider, other applications can query
or even modify the data (if the content provider allows it).
For example, the Android system provides a content
provider that manages the user's contact information.
As such, any application with the proper permissions can
query part of the content provider to read and write
information about a particular person.
Content providers are also useful for reading and writing
data that is private to your application and not shared.
A broadcast receiver is a component that responds to
system-wide broadcast announcements.
Many broadcasts originate from the system—for example,
a broadcast announcing that the screen has turned off, the
battery is low, or a picture was captured.
Applications can also initiate broadcasts—for example, to
let other applications know that some data has been
downloaded to the device and is available for them to use.
Although broadcast receivers don't display a user interface,
they may create a status bar notification to alert the user
when a broadcast event occurs.
More commonly, though, a broadcast receiver is just a
"gateway" to other components and is intended to do a very
minimal amount of work. For instance, it might initiate a
service to perform some work based on the event.
A unique aspect of the Android system design is that
any application can start another application’s
component. For example, if we want the user to
capture a photo with the device camera, there's
probably another application that does that and our
application can use it, instead of developing an
activity to capture a photo ourselves. We don't need to
incorporate or even link to the code from the camera
application. Instead, we can simply start the activity
in the camera application that captures a photo.
When complete, the photo is even returned to our
application so we can use it. To the user, it seems as if
the camera is actually a part of our application.
When the system starts a component, it starts
the process for that application (if it's not already
running) and instantiates the classes needed for
the component. For example, if our application
starts the activity in the camera application that
captures a photo, that activity runs in the process
that belongs to the camera application, not in our
application's process. Therefore, unlike
applications on most other systems, Android
applications don't have a single entry point
(there's no main() function, for example).
Because the system runs each application in a
separate process with file permissions that
restrict access to other applications, our
application cannot directly activate a component
from another application. The Android system,
however, can. So, to activate a component in
another application, you must deliver a message
to the system that specifies your intent to start a
particular component. The system then activates
the component for you.
The AndroidManifest.xml file is the control file that tells the
system what to do with all the top-level components
(specifically activities, services, intent receivers, and content
providers described below) you've created. For instance, this is
the "glue" that actually specifies which Intents your Activities
A developer should predefine and list all components, which
he wants to use in the specific AndroidManifest.xml file.
It is a required file for all the applications and is located in
the root folder.
It is possible to specify all global values for the package, all
the components and its classes used, intent filters, which
describe where and when the certain activity should start,
permissions and instrumentation like security control and
Here is an example of AndroidManifest.xml file:
<?xml version="1.0" encoding="utf-8"?>
<activity class=".HelloAndroid" android:label="@string/app_name">
<action android:value="android.intent.action.MAIN" />
The line 2 is a namespace declaration, which
makes a standard Android attributes available
for that application. In the line 4 there is a single
<application> element, where the developer
specifies all application level components and
its properties used by the package. Activity
class in the line 5 represents the initial screen
the user sees and it may have one or more
<intent-filter> elements to describe the actions
that activity supports.
In Android, every application runs in its own process,
which gives better performance in security, protected
memory and other benefits.
Therefore, Android is responsible to run and shut
down correctly these processes when it is needed.
It is important that application developers
understand how different application components (in
particular Activity, Service, and Broadcast Receiver)
impact the lifetime of the application's process.
Not using these components correctly can result in
the system killing the application's process while it is
doing important work.
To determine which processes should be killed when low on
memory, Android places each process into an "importance
hierarchy" based on the components running in them and the
state of those components. These process types are (in order of
A foreground process is one that is required for what the user
is currently doing. Various application components can cause
its containing process to be considered foreground in different
ways. A process is considered to be in the foreground if any of
the following conditions hold:
It is running an Activity at the top of the screen that the user is interacting
with (its onResume() method has been called).
It has a BroadcastReceiver that is currently running (its
BroadcastReceiver.onReceive() method is executing).
It has a Service that is currently executing code in one of its callbacks
(Service.onCreate(), Service.onStart(), or Service.onDestroy()).
A visible process is one holding an Activity that is visible to
the user on-screen but not in the foreground (its onPause()
method has been called). This may occur, for example, if
the foreground Activity is displayed as a dialog that allows
the previous Activity to be seen behind it. Such a process is
considered extremely important and will not be killed
unless doing so is required to keep all foreground processes
A service process is one holding a Service that has been
started with the startService() method. Though these
processes are not directly visible to the user, they are
generally doing things that the user cares about (such as
background mp3 playback or background network data
upload or download), so the system will always keep such
processes running unless there is not enough memory to
retain all foreground and visible process.
A background process is one holding an Activity that is not
currently visible to the user (its onStop() method has been
called). These processes have no direct impact on the user
experience. Provided they implement their Activity life-cycle
correctly (see Activity for more details), the system can kill
such processes at any time to reclaim memory for one of the
three previous processes types. Usually there are many of
these processes running, so they are kept in an LRU list to
ensure the process that was most recently seen by the user is
the last to be killed when running low on memory.
An empty process is one that doesn't hold any active
application components. The only reason to keep such a
process around is as a cache to improve startup time the next
time a component of its application needs to run. As such, the
system will often kill these processes in order to balance
overall system resources between these empty cached
processes and the underlying kernel caches.
Android Development Tools Plugin for Eclipse
IDE and Tools
Emulator and System Images
Documentation and Sample Code
Eclipse IDE + ADT (Android Development Tools)
Reduces Development and Testing Time
Makes User Interface-Creation easier
Makes Application Description Easier
Android mobile phone platform is going to be more secure
than Apple’s iPhone or any other device in the long run. There
are several solutions nowadays to protect Google phone from
various attacks. One of them is security vendor McAfee, a
member of Linux Mobile (LiMo) Foundation. This foundation
joins particular companies to develop an open mobile-device
software platform. Many of the companies listed in the LiMo
Foundation have also become members of the Open Handset
As a result, Linux secure coding practice should successfully
be built into the Android development process. However, open
platform has its own disadvantages, such as source code
vulnerability for black-hat hackers. In parallel with great
opportunities for mobile application developers, there is an
expectation for exploitation and harm. Stealthy Trojans
hidden in animated images, particular viruses passed from
friend to friend, used for spying and identity theft, all these
threats will be active for a long run.
Another solution for such attacks is SMobile Systems
mobile package. SecurityShield –an integrated
application that includes anti-virus, anti-spam,
firewall and other mobile protection is up and ready
to run on the Android operating system. Currently,
the main problem is availability for viruses to pose as
an application and do things like dial phone numbers,
send text messages or multi-media messages or make
connections to the Internet during normal device use.
It is possible for somebody to use the GPS feature to
track a person’s location without their knowledge.
Hence SMobile Systems is ready to notify and block
these secure alerts. But the truth is that it is not
possible to secure your mobile device or personal
computer completely, as it connects to the internet.
And neither the Android phone nor other devices will
prove to be the exception.
There are a host of advantages that Google’s Android will derive
from being an open source software. Some of the advantages
Open - Android allows you to access core mobile device
functionality through standard API calls.
All applications are equal - Android does not differentiate
between the phone's basic and third-party applications --
even the dialer or home screen can be replaced.
Breaking down boundaries - Combine information from the
web with data on the phone -- such as contacts or
geographic location -- to create new user experiences.
Fast and easy development - The SDK contains what you
need to build and run Android applications, including a
true device emulator and advanced debugging tools.
Android doesn't support
Bluetooth stereo (before 2.3)
Contacts exchange (before 2.3)
Screen capture natively (before 4.0)
But it'll work with Bluetooth headsets, but that's about it
Firefox Mobile isn't coming to Android
Apps in Android Market need to be programmed with a
custom form of Java
→ Mozilla won't have that
With all upcoming applications and mobile
services Google Android is stepping into the next
level of Mobile Internet.