Android Apps with Eclipse.pdf

DownLoad Book

Published: 2018-03-17 Author:Bieber 24 Browses

Tags: android eclipse


书名: Android Apps with Eclipse

作者: Onur Cinar

出版日期: Jun 2012

页数: 368

ISBN: 978-1-4302-4435-6

Extracting password :93e47ffd0c3df9c1

For your convenience Apress has placed some of the front
matter material after the index. Please use the Bookmarks
and Contents at a Glance links to access them.
Android Apps
with Eclipse
■ ■ ■
Onur Cinar
Contents at a Glance
About the Author................................................................................................ x
About the Technical Reviewer .......................................................................... xi
Introduction ..................................................................................................... xii
Chapter 1: Android Primer ............................................................................... 1
Chapter 2: Application Architecture .............................................................. 27
Chapter 3: Eclipse Primer .............................................................................. 45
Chapter 4: Mastering Eclipse......................................................................... 73
Chapter 5: Android Development Tools for Eclipse...................................... 111
Chapter 6: Project: Movie Player ................................................................. 151
Chapter 7: Android Native Development Using Eclipse................................ 185
Chapter 8: Project: Extending Movie Player for AVI Movies ........................ 239
Chapter 9: Android Scripting Using Eclipse ................................................ 271
Chapter 10: Project: Movie Player Using HTML and JavaScript .................. 307
Appendix A: Testing Android Applications................................................... 333
Index ............................................................................................................ 349
Android is one of the major players in the mobile phone market, and its market share is
continuously growing. Android is the first complete, open, and free mobile platform, and it offers
endless opportunities for mobile application developers. As with all other platforms, having a
robust and flexible development environment is the key for the platform's success.
Eclipse is the most adopted integrated development environment (IDE) for Java
programmers. And now Eclipse is the preferred IDE for Android app developers.
Android Apps with Eclipse provides a detailed overview of Eclipse, including the steps
and illustrations to help Android developers quickly get up to speed on Eclipse and to streamline
their day-to-day software development.
Who This Book Is For
This book is for both beginners and intermediate developers who would like to quickly come up
to speed on Android development using the Eclipse IDE.
What You Will Learn
This book covers the following topics:
How the Android platform works and the basics of Android application development
How to use the most popular Java IDE, Eclipse, to develop Android applications
How to install and configure Eclipse for Android development
How to leverage Eclipse with the Android Native Development Kit (NDK) for C/C++
How to leverage Eclipse for scripting using Android's Scripting Layer for Android (SL4A)
How to debug and troubleshoot Android applications using Eclipse
Downloading the Code
The source code for this book is available to readers from
Contacting the Author
Readers can contact the author through his Android Apps with Eclipse site at
Android Primer
In this chapter, we will briefly cover the Android platform from various angles.
We will start with Android’s history, to better understand the motivations behind
its formation. Then we will explore the Android platform architecture’s fine
combination of technologies that empower the platform to deliver a superior
mobile experience. We will emphasis the multilayer Android security framework,
which employs both software and hardware to keep the platform secure. We will
briefly review the service application programming interfaces (APIs) that are
provided through the Android framework for user-level applications to interact
with the platform. Finally, we will discuss Android application deployment and
Android History
Android Inc. was founded in Silicon Valley, California, in October 2003, with the
idea of providing a mobile platform that is more aware of the user’s location and
Google acquired Android Inc. in August 2005 as a wholly owned subsidiary of
Google Inc. Google’s main intention was to provide a fully open platform,
backed by Google technologies, for both the users and the application
In November 2007, the Open Handset Alliance was founded as a consortium to
develop an open standard for mobile devices. Open Handset Alliance began its
journey by announcing the Android platform. In less than a year, new members
started joining this consortium.
CHAPTER 1: Android Primer
Android became an open source initiative that is led by Google under Open
Handset Alliance’s umbrella. The goal of the Android open source project is to
provide an open platform to improve the mobile experience of users.
Android is the first complete, open, and free mobile platform.
The Android platform is a robust, secure, easily
upgradable, mobile platform with a comprehensive framework
and well-defined interfaces. It allows application developers to
develop and fully blend their applications into the platform. It
also provides compatibility and certification programs, so
device manufacturers can design highly compliant devices.
The entire Android platform has been developed and
provided under open source Apache licensing terms. Android
does not distinguish between preloaded applications and
third-party applications. Developers have full access to device
features and services while developing applications.
The Android platform does not charge any licensing,
royalty, membership, or certification fees to develop
applications on the platform. Android platform source code
and software development kits are provided free of charge to
application developers. The software development platform is
widely available on many desktop operating systems, allowing
application developers to develop applications using the
operating system of their choice.
Today, Android is one of the major players in mobile phone market. Based on
the recent market analysis, on average, 700 thousand Android devices are
activated daily, and more than 200 million devices are already activated. Android
currently has 48% of the mobile phone market share, and it’s growing rapidly.
Android Versions
The first beta of the Android platform was released on November 5, 2007. Since
then, it has been through a number of updates and bug fixes. Although bug fixes
are usually transparent from the application developer’s perspective, updates
usually mean changes and additions to the framework API. For that reason,
besides the Android platform version numbers, a second version number, called
API level
, is used to identify the framework API that is supported.
Since April 2009, each Android version has been released under a codename
based on desserts, such as Éclair, Froyo, and Gingerbread. This introduced a
third versioning scheme to the Android platform, making things even more
CHAPTER 1: Android Primer
cryptic for first-time Android application developers. When speaking of Android
application development, you will often hear people say things like ‘‘my
application requires Éclair and above,’’ ‘this method requires at least API level
9,’’ and ‘‘my phone got the Android 2.1 update.’’ Understanding which version
and which API level they are referring to, as well as which new APIs are part of
which Android platform version, can easily become a cumbersome memory
exercise. You can use Table 1-1 as a reference to map between these three
version schemes.
NOTE: Since the Android platform is continuing to evolve, Table 1-1 may not cover
the latest platform revisions. For an up-to-date listing, refer to the API Levels section
of the Android Developer Pages, at
Table 1-1. Android Release Dates, Revisions, API Levels, and Codenames
Release Date Platform Version API Level Codename
November 5, 2007 Beta
September 23, 2008 Android 1.0 1
February 9, 2009 Android 1.1 2
April 30, 2009 Android 1.5 3 Cupcake
September 15, 2009 Android 1.6 4 Donut
October 26, 2009 Android 2.0 5 Éclair
December 3, 2009 Android 2.0.1 6 Éclair
January 12, 2009 Android 2.1 7 Éclair
May 20, 2010 Android 2.2 8 Froyo
January 18, 2011 Android 2.2.1 8 Froyo
January 22, 2011 Android 2.2.2 8 Froyo
CHAPTER 1: Android Primer
Release Date Platform Version API Level Codename
November 21, 2011 Android 2.2.3 8 Froyo
December 6, 2010 Android 2.3 9 Gingerbread
February 9, 2011 Android 2.3.3 10 Gingerbread
July 25, 2011 Android 2.3.5 10 Gingerbread
September 2, 2011 Android 2.3.6 10 Gingerbread
February 22, 2011 Android 3.0 11 Honeycomb
May 10, 2011 Android 3.1 12 Honeycomb
July 15, 2011 Android 3.2 13 Honeycomb
September 20, 2011 Android 3.2.1 13 Honeycomb
August 30, 2011 Android 3.2.2 13 Honeycomb
October 19, 2011 Android 4.0.1 14 Ice Cream Sandwich
November 28, 2011 Android 4.0.2 14 Ice Cream Sandwich
December 16, 2011 Android 4.0.3 15 Ice Cream Sandwich
February 4, 2012 Android 4.0.4 15 Ice Cream Sandwich
As shown in Table 1-1, there are 15 API levels that you should consider while
developing your applications. The API level determines the size of your audience
as well, so picking this number wisely is very important while developing a new
Android application.
The Android mobile phone market is highly fragmented. By simply looking at the
release dates, you might think that most of the Android user base is running at
least Android 3.0, since it has already been around for a year; however, this is
not true. Due to the fragmentation, the release dates are far from giving a clear
view of Android versions in use. Figure 1-1 is the latest version distribution chart
from Android Platform Versions Dashboard
CHAPTER 1: Android Primer
Figure 1-1. Distribution of Android versions based on market data
As you can see in Figure 1-1, most of the Android user base is currently running
Android 2.3.3, Gingerbread. This means that your application needs to support
API level 10 as a minimum in order to reach the majority of the Android users. It
also means that you won’t be able to use the latest API features introduced in
the newer versions of the Android platform in your application. In this book, we
will be developing our examples using Android 2.3.3.
The variety of versions is a common problem for Android developers. Most
application developers develop packages for different API levels. This resolves
the problem, but it means that different code branches need to be maintained.
In March 2011, Google introduced the Support Package as a solution to the
versions problem. The Support Package is a set of static libraries that allows
application developers to develop Android applications that support multiple
Android platform versions. The main goal of the Support Package is to simplify
the process of supporting multiple Android versions from a single code base.
You can find more information about the Support Package at
CHAPTER 1: Android Primer
Android Platform Architecture
Android is more of a complete software stack for mobile devices than an
operating system. It is a combination of tools and technologies that are carefully
optimized for mobile needs.
Android relies on the well-proven Linux kernel in order to provide its operating
system functions. For the user-space application, Android relies on the Java
Virtual Machine technology by employing the Dalvik virtual machine. The
Android Zygote application process, through service preloading and resource
sharing, boosts the application startup times and allows efficient use of scarce
memory resources on mobile platforms. All these successful technologies play
an important role in the success of the Android platform, as illustrated in Figure
1-2. In addition to these tools and technologies, the Android runtime provides a
unique computing environment that is tailored for providing a smooth mobile
experience to end users, while streamlining mobile application development for
CHAPTER 1: Android Primer
Figure 1-2. Android platform architecture
CHAPTER 1: Android Primer
Hardware Abstraction Layer
Android relies on the Linux kernel as its hardware abstraction layer (HAL), and
also to provide its operating system functionality. During the course of Android
development, multiple improvements have been made to the Linux kernel code
in order to tune it for mobile needs. The following are the most notable features:
Alarm timer
Paranoid network security
Android shared memory (Ashmem)
Process shared memory (Pmem)
Low memory killer (Viking Killer)
Although application developers are not expected to interact with these low-
level components directly, knowing their roles in the overall Android platform is
Alarm Timer
Android is designed to run on mobile platforms, where the only power to the
device is provided through batteries. Android goes into a variety of sleep modes
in order to efficiently use the limited battery resources. While the device is in
sleep mode, the applications need a way to wake up the system in order to
perform certain periodic tasks. On Android, this is achieved through the alarm
timer kernel module. It allows a user-space application to schedule itself to run
at some point in the future, regardless to the state of the device.
The class in Android runtime allows the user-level
application to interact with the alarm timer through API calls. The Alarm
Manager allows the applications to schedule an intent using the alarm timer
(intents are discussed in the next chapter). When the alarm goes off, the
scheduled intent is broadcast by the system to start the application. The Alarm
Manager holds a CPU wakelock (described a little later in this chapter) as long
as the application is busy executing code in its broadcast receiver’s onReceive
method. This guarantees that the device will not go into sleep mode again until
the application is finished performing its task.
CHAPTER 1: Android Primer
The alarm timer retains the scheduled alarms while the device is asleep;
however, this list is cleared if the device is turned off and rebooted.
Paranoid Network Security
Network security is one of the most important requirements of any mobile
platform. In order to provide an extensive level of security, Android handles this
requirement at the lowest possible layer as a kernel modification. Through this
implementation, Android restricts access by the group of the calling process.
Applications should request the necessary permissions in advance, in order to
be part of these network groups. Otherwise, the network access of these
applications will be blocked within the kernel.
The Android platform architecture makes heavy use of interprocess
communication (IPC). Applications communicate with the system, phone
services, and each other by using IPC.
NOTE: Interprocess communication (IPC) is a mechanism to allow applications to
exchange data with each other and also with the operating system itself.
Although Android relies on the Linux kernel for its operating system-related
functionality, it does not use the System V IPC mechanism that is provided
through the Linux kernel. Instead, it relies on an Android-specific IPC system,
which known as Binder.
Binder technology originated with the engineers at Be Inc. as a part of the Be
Operating System (BeOS). The development of Binder continued at PalmSource
as a key foundation of the Cobalt system, and later was open sourced as a
Linux kernel module under the name OpenBinder project. Android’s Binder
implementation is a complete rewrite of the OpenBinder project in order to
comply with the Apache License. Binder communicates between processes
using a kernel module, as shown in Figure 1-3.
CHAPTER 1: Android Primer
Figure 1-3. Binder kernel module allowing two applications to communicate
Binder’s user-space code maintains a pool of threads in each process, and
these threads are used to process incoming Binder requests as local events.
Binder is also responsible for tracking the object references across processes.
Additionally, Binder provides an extra level of security, by transmitting the user
and group ID of the calling process with each Binder request.
Binder is a key construct in the Android platform. It is the central messaging
channel across the entire Android platform. Android applications communicate
with the system, services, and each other through the Binder interface.
Although Binder is implemented as a low-level service, application developers
are not expected to directly interact with it. The Android runtime provides the
android.os.IBinder interface as the API to communicate with other processes
through Binder. Android provides the Android Interface Definition Language
(AIDL), which is tuned for Binder.
AIDL allows you to define the programming interface that the client and server
will use to communicate with each other. As with many other operating systems,
on Android, the processes are not allowed to access the memory of another
process directly. AIDL provides the functionality to decompose the objects into
primitives that Binder can understand and use across project boundaries.
CHAPTER 1: Android Primer
Threading is one of the most important parts of interacting with Binder:
Calls made from the local process are executed in the calling
thread. Binder calls are synchronous and will block the current
thread until the request is processed. If the request is
expected to take a long time to complete, the request should
not be made from the application’s main thread. This would
make the application hang, and may result in the application
being terminated by the Android platform. Binder also
supports nonblocking requests through the oneway attribute.
Calls from a remote process are dispatched from the thread
pool provided by the local process. The service code is
expected to be thread-safe, since the requests can be
executed by any of these threads.
Android SDK provides the necessary code generators to translate programming
interfaces that are defined in AIDL into actual Java classes. Application
developers are only expected to provide the implementation for the generated
interface and the Android service that will provide the interface to the clients.
Android is designed to operate on mobile platforms with scarce resources.
Because of this, Android devices go into sleep mode very frequently. Although
this allows the system to use the available resources efficiently, it is not
preferable for the device to go into sleep mode while the kernel or an application
is in the middle of an important process. Wakelocks were introduced as a kernel
patch in order to allow an application to prevent the system from going into
sleep mode while it is performing a task.
Two types of wakelocks are supported by the Android platform:
An idle wakelock prevents the system from entering a low-
power idle state.
A suspend wakelock prevents the system from entering a full-
system suspend state.
Application developers interact with wakelocks through the
android.os.PowerManager.WakeLock interface. To use this interface, the
application should request android.permission.WAKE_LOCK in advance.
Wakelocks should be used with caution. Preventing the device from going into
sleep mode will increase the power consumption, which will eventually cause it
to run out of battery power. An application should hold the wakelock during
CHAPTER 1: Android Primer
important operations, and immediately release it as soon as the operation is
Android Shared Memory
Android shared memory (Ashmem) )is a POSIX-like shared memory subsystem
on the Android platform that is implemented as kernel module. Ashmem is
highly tuned for mobile needs, and it provides better support for low-memory
devices. Ashmem supports reference-counted objects that can be shared
among multiple processes.
Process Shared Memory
In addition to Ashmem, Android provides a second type of shared memory
subsystem, known as process shared memory (Pmem). Pmem is used for
sharing large amounts of physically contiguous memory among processes.
Pmem is mostly used by the Android media engine to deliver large media frames
between the media engine and the application processes.
Low Memory Killer
Low memory killer, also known as the Viking Killer, is one of the other Android-
specific enhancements in the Linux kernel. This feature allows the system to
reclaim memory before it runs out of memory.
In order to start an application, the device must first read the application code
from the persistent storage to random-access memory (RAM). Since this is a
time-consuming and costly process, Android attempts to keep the application
processes around as long as possible. But eventually, it will need to remove
them from RAM when the memory runs low.
The order in which applications are removed to prevent running out of memory
depends on the importance of an application, which is gauged by the current
state of the user’s interaction with that application:
An application with a foreground activity, which the user is
currently interacting with, is considered the most important
An application with a visible activity, which is not currently
interacting with the user but still visible, is also considered
CHAPTER 1: Android Primer
An application with a background activity, which is no longer
visible to the user, is not considered important, since its
current state can be saved and later restored when the user
navigates back to the activity.
Android starts with the least important application when removing processes
from memory. An empty process is one that has no activities, services, or
broadcast receivers. These types of applications are considered as the least
important, and Android starts removing them first.
The threshold values for each of these application states are configured using
the /etc/init.rc system configuration file. Table 1-2 lists these thresholds.
Table 1-2. Memory Threshold Values for Removing Applications from Memory
Application State Memory Threshold
Foreground application 6MB
Visible application 8MB
Hidden application 20MB
Content provider 22MB
Empty application 24MB
The low memory killer service gets this information through
Logging is the most important part of troubleshooting, but it is tricky to achieve,
especially on mobile platforms, where the development and the execution of the
application happen on two different machines. Android has an extensive logging
system that allows system-wide centralized logging of information from both the
Android system itself and the applications.
The Android logging system is implemented as a kernel module known as the
logger. A set of API calls and user-level applications are also provided to
interact with the logger module.
The amount of information being logged on the platform at any given time
makes the viewing and analysis of these log messages very difficult. In order to
CHAPTER 1: Android Primer
simplify this procedure, the Android logging system groups the log messages
into four separate log buffers:
Main application log messages
System events
Radio-related log messages
Low-level system debug messages for debugging
These four buffers are kept as pseudo-devices under the /dev/log system
directory. Since input and output (I/O) operations on mobile platforms are very
costly, the log messages are not saved in persistent storage; instead, they are
kept in memory. In order to keep the memory utilization of the log messages
under control, the logger module puts them in fixed-sized buffers. Main, radio,
and system logs are kept as free-form text messages in 64KB log buffers. The
event log messages carry additional information in binary format, and they are
kept in a 256KB log buffer.
A set of user-level applications is also provided to view and filter these logs,
such as the logcat and the Dalvik Debug Monitor Server
(DDMS) tools, which we
will examine in chapter 5.
The Android runtime provides a set of API calls to allow applications to easily
send their log messages to the logger. Application log messages are sent
through the following classes:
android.util.Log: This class is used to send application log
messages. It provides a set of methods to specify the priority
of the message, as well as a tag to indicate which application
is generating this log message.
android.util.EventLog: This class is used to send event log
messages in binary format.
android.util.Slog: This class is used by the Android runtime
components to send system log messages. It is not part of the
Android API, and it is not accessible from the applications.
On most UNIX-like operating systems, the application that is known as Init is
considered as the parent of all processes. Init gets started after the kernel
successfully boots. Its primary role is to start a set of other processes based on
the system configuration.
CHAPTER 1: Android Primer
Zygote, also known as the "app process," is one of those core processes
started by Init when the system boots. Zygote’s role within the Android platform
is very similar to that of Init. Its first task is to start a new Dalvik virtual machine
instance and initialize the core Android services, such as the following:
Power service
Activity service
Package service
Content service
Alarm service
Window service
Content providers
Telephony service
Battery service
After starting these services, Zygote starts working on its second task, which is
where its name comes from.
NOTE: Based on its dictionary definition, zygote is the initial cell formed. In single-
celled organisms, the zygote divides to produce offspring.
As noted earlier, on Android, every application runs within its dedicated virtual
machine instance. In addition, Android applications rely on a set of class and
data objects that needs to be loaded into memory first for the application to
perform its task. This introduces a large overhead when starting a new
application. Despite this overhead, Android needs to keep the startup time as
small as possible in order to provide a highly responsive user experience. By the
use of
, Zygote resolves this problem in a fast and efficient way.
In computing, forking is the operation to clone an existing process. The new
process has an exact copy of all memory segments of the parent process,
although both processes execute independently, as shown in Figure 1-4. Copy-
on-write is an optimization strategy used in forking that delays copying the
memory by allowing both processes to share the same memory segment until
one of them tries to modify it.
CHAPTER 1: Android Primer
Figure 1-4. Zygote and other applications sharing read-only components of the Android framework
Since the Android runtime classes and data objects are immutable by the
applications, this makes them ideal candidates for copy-on-write optimization
during forking.
Zygote preloads the Android runtime objects and waits for requests to start new
applications. When a new request arrives, instead of starting a new virtual
machine instance, it simply forks. This allows the new application to start very
quickly while keeping its memory footprint low.
Dalvik Virtual Machine
Java is a general-purpose, object-oriented programming language that is
specifically designed for platform-independent application development with the
goal of ‘‘write once, run anywhere.’’ Java achieves this by compiling the
application code into an intermediate platform-independent interpreted
language called
. During runtime, this bytecode is executed through
another Java entity known as the Java Virtual Machine.
Virtual machines are native applications that run on the host computer and
interpret the bytecode. In order to optimize the runtime of complex applications,
most virtual machine implementations also support the just-in-time (JIT) feature,
which allows on-the-fly translation from bytecode to native machine code. This
allows long-running applications to execute much faster, since the interpretation
of the bytecode is needed only at the beginning of the application execution.
One of the biggest challenges most mobile platforms face is the lack of
applications. In order to resolve that problem from the very beginning, Android
relies on the well-proven Java programming language, which already has a very
large developer community, as well as applications, tools, and components that
will facilitate application development.
CHAPTER 1: Android Primer
Android also relies on a highly customized virtual machine implementation that
is tuned for mobile needs. Dalvik virtual machine is Android’s customized Java
Virtual Machine for mobile platforms.
Dalvik virtual machine is very different from other Java Virtual Machine
implementations. Most virtual machine implementations on the desktop platform
are developed based on the stack-based virtual machine model. Dalvik virtual
machine is based on the register-based virtual machine model due to the mobile
needs. Register-based virtual machines require longer instructions to interpret;
however, the actual number of instructions executed is very low compared to
stack-based virtual machines. This makes register-based virtual machines a
much better choice for mobile environments, where the computing power is a
scarce resource.
Since Dalvik virtual machine requires a different type of bytecode to interpret, it
does not support the standard Java class files, and it relies on its own format,
which is known as Dalvik Executable (DEX). The Android software development
platform comes with a set of tools to postprocess the compiled Java class files
into DEX format.
DEX format is also a much more compact way to store compiled Java
application code on the mobile platform. Standard Java applications are formed
by multiple class files that are stored separately. DEX merges all class files into
one big DEX file, as shown in Figure 1-5. This minimizes the footprint of the
application code.
CHAPTER 1: Android Primer
Figure 1-5. The conversion from standard Java class files in a JAR file to a single DEX file
The constant pools in the DEX format allow string, type, field, and method
constants, and everything else in the code, to be stored in a single place, using
indexes to those lists instead of the full names. This reduces the size of the
class files almost 50%.
The Android platform runs each application in its own dedicated virtual machine
instance as a sandbox. This puts high requirements on the platform, since
multiple virtual machines are expected to run simultaneously within a limited
CPU resource environment. Dalvik virtual machine is specifically tuned to work
in this type of environment.
File System
The file system is a very crucial piece of the operating system. Especially on
mobile platforms, file system plays an important role in satisfying the
expectations of the operating system.
CHAPTER 1: Android Primer
Mobile devices rely on flash-based storage chips. Android relies on Yet Another
Flash File System (YAFFS2) as its primary file system. YAFFS2 is an open
source file system implementation designed and written by Charles Manning for
the Linux operating system. YAFFS2 is a high-performance file system
specifically designed to work on NAND-based flash chips. It is a log-structured
file system that takes data integrity as a high priority.
In addition to the file system, the structure of how the operating system files and
components are organized plays an important role in Android as well. Mobile
platforms are expected to be easily upgradable and also highly secure in order
to protect user’s confidential information. Android addresses this requirement by
relying on organizing itself using multiple partitions. By keeping different parts of
the operating system in different partitions, Android provides a high level of
security and also makes the platform easily upgradable.
The partitions used depend on the device manufacturers. Here is a list of the
most common ones:
/boot: This partition includes the boot loader and the Linux
kernel that is needed to boot the device. This partition is not
writable by the user applications, since modifying the content
of this partition may cause the device not to boot anymore.
/system: This partition contains all the Android system files
and applications that are preloaded on the device. During an
upgrade, this partition is replaced by the latest version of the
Android platform. This partition is not writable by user
applications, although the Android Market application can
make this partition writable temporarily in order to update the
preloaded applications.
/recovery: This partition keeps a recovery image, which is an
alternative boot partition. It provides maintenance functionality
in order to recover the system or to do other tasks, such as
making system backups. This partition is also not writable
from user applications.
/data: This partition keeps the user's applications and also the
user’s data, such as the contacts, messages, and settings.
When the device is factory reset, this partition is erased.
/cache: This partition is used to store frequently accessed
files. On most Android devices, cache is not a partition on the
flash media, but rather a virtual partition stored in RAM. The
content of this partition does not persist when the device
CHAPTER 1: Android Primer
/sdcard: This is a mount point, rather than a partition, on the
internal storage. The SD card that is attached to the device is
mounted under this name. This mount point is not always
accessible to the applications, since it may be directly
mounted on a host PC when the device is connected through
the USB connection.
Although Android does not expect application developers to use these partitions
directly, knowing their purpose can be very useful during Android application
As with many other mobile platforms, the biggest requirement for Android, from
the users’ perspective, is the security and integrity of users’ applications and
data. Android is designed with security in mind.
The Android architecture provides security at multiple layers of the platform.
This extensive security framework is also exposed to the developers through the
Android runtime. Security-savvy developers can easily rely on these APIs in
order to provide a high level of security for their application and the data it uses.
Developers less familiar with the security are already protected by the default
security settings.
Android provides a high level of security by using multiple security features from
both the hardware and the software. Although it is designed to work on a variety
of hardware platforms, Android still takes advantage of hardware-specific
security capabilities such as the ARMv6 eXecute-Never feature.
The Android platform is built on the top of the Linux kernel. The Linux kernel
itself has been used in many security-sensitive environments for many years.
The Linux kernel provides Android several key security features, such as the
A user-based permission model
Process isolation
Secure IPC mechanism
Ability to remove unnecessary functionality from the kernel
The Linux kernel is designed for multiuser platforms. Although Android is a
single-user environment, it still takes advantage of the user-based permission
model. Android runs the applications within a virtual machine sandbox, and
CHAPTER 1: Android Primer
treats them as different users on the system. By simply relying on the user-
based permission model, Android easily secures the system by preventing the
applications from accessing other applications’ data and memory.
On Android, services and hardware resources are also protected through the
user-based permission model. Each of these resources has its own protection
group. During application deployment, the application requests access to those
resources. If the request is granted by the user, the application becomes a
member of these resource groups. The application won’t be allowed to access
any additional resources if it is not a member of that resource’s group.
In addition to the security features provided by the operating system, Android
also enhances the Android platform binaries using ProPolice to protect them
from stack buffer overflow attacks.
File system protection is also one of the new Android features available since
Android 3.0. It allows Android to encrypt the entire storage media using the
AES-128 algorithm. This prevents other people from accessing the user’s data
without knowing the key used.
Device administration is one of the other security features available since
Android 2.2. It allows administrators to remotely enforce security policies and to
erase the device remotely when the device is lost or stolen.
The Android platform is not limited to only the features provided from the Linux
kernel. The Android runtime comes with a lot of services for application
developers. The following are the major services provided.
Accessibility service: This service is provided through the
android.view.accessibility.AccessibilityManager class. It
is a system-level service that serves as an event dispatcher for
accessibility events and provides a set of APIs to query the
accessibility state of the system.
Account service: This service is provided through the
android.accounts.AccountManager class. It is a centralized
registry of the user’s online accounts. It allows applications to
access online resources using the user’s accounts after user
Activity service: This service is provided through the class. It allows the application
to interact with the activities running in the system.
CHAPTER 1: Android Primer
Alarm service: This service is provided through the class. It allows applications to
register with the Alarm service in order to schedule execution
at some point in the future.
Audio service: This service is provided through the class. It allows applications to
control the volume and the ringer mode.
Clipboard service: This service is provided through the
android.content.ClipboardManager class. It allows
applications to place data in the system clipboard and retrieve
it from the clipboard.
Connectivity service: This service is provided through the class. It allows applications
to query the state of the network connectivity. It also
generates events when the network connectivity changes.
Device Policy service: This service is provided through the class. The device
administration API provides device administration features at
the system level. It allows development of security-aware
applications that are useful in enterprise settings.
Download service: This service is provided through the class. It handles long-running
HTTP downloads. Applications may request a URI to be
downloaded to a particular destination file using this service.
The Download service takes care of the HTTP interactions and
retrying downloads after failures, connectivity changes, and
system reboots.
Drop Box service: This service is provided through the
android.os.DropBoxManager class. It provides system-wide,
data-oriented log storage. It collects data from application
crashes, kernel logs, and other sources. The data does not get
sent anywhere directly, but debugging tools may scan and
upload entries for processing.
Input Method service: This service is provided through the
android.view.inputmethod.InputMethodManager class. It
allows applications to interact with the input method
framework (IMF) through the provided methods.
CHAPTER 1: Android Primer
Notification service: This service is provided through the class. It allows applications
to notify the user regarding events that happen. The services
running in the background communicate with the user only
through this service.
Location service: This service is provided through the
android.location.LocationManager class. It allows
applications to obtain periodic updates of the device’s current
Near Field Communication service: This service is provided
through the android.nfc.NfcManager class. It allows
applications to use the near field communication (NFC)
features of the device.
Package service: This service is provided through the class. It allows
applications to retrieve information related to application
packages that are currently installed on the system.
Power service: This service is provided through the
android.os.PowerManager class. It allows applications to
control the power state of the device. It allows applications to
hold wakelocks to prevent the device from going into sleep
mode while performing a task.
Sensor service: This service is provided through the
android.hardware.SensorManager class. It allows applications
to access the device’s sensors.
Telephony service: This service is provided through the
android.telephony.TelephonyManager class. It allows
applications to interact with the telephony functionality of the
mobile device. It also generates events for applications to
watch telephony state changes.
UI Mode service: This service is provided through the class. It allows applications to
control the user interface (UI) modes of the device such as
disabling the car mode.
USB service: This service is provided through the
android.hardware.usb.UsbManager class. It allows applications
to query the state of the USB and to communicate with
devices through USB devices.
CHAPTER 1: Android Primer
Vibrator service: This service is provided through the
android.os.Vibrator class. It allows applications to control
the vibrator on the device.
Wallpaper service: This service is provided through the
android.service.wallpaper.WallpaperService class. It allows
applications to show live wallpapers in the background.
Wi-Fi Peer-to-Peer service: This service is provided through
the class. It allows
applications to discover available peers and establish peer-to-
peer connections through the Wi-Fi network.
Wi-Fi service: This service is provided through the class. It allows applications to
manage Wi-Fi connectivity. Applications can list and update
the configured networks, access the results of access point
scans, and establish and tear down connections.
Android Deployment and Distribution
Because the Android platform is a free platform, it does not charge any
licensing, royalty, membership, or certification fees to develop and distribute
applications on the platform.
The Android platform lets application developers decide how to distribute and
monetize their applications. Application developers can distribute their
applications as freeware, shareware, advertisement sponsored, or paid.
The Android platform comes with a default marketplace, Google Play, previously
known as the Android Market, which is an online store developed by Google for
Android devices. Unlike the Android platform, the Android Market application is
not open source. It is available only for devices that comply with Google’s
compatibility requirements. The client portion comes preloaded on Android
devices under the name Market. Users can use this application to search and
download Android applications. The Market application also keeps the installed
Android applications up to date by informing the user of software updates.
Application developers use the server part of the Android Market. Through the
web-based interface, application developers can upload their applications for
The Android Market runs a set of tests on the distributed applications, but it
does not take any responsibility for the applications downloaded from the
Android Market. During installation, the Android Market application displays a