COMPANION eBOOK
US $44.99
Shelve in
Mobile Computing
User level:
Intermediate
www.apress.com
BOOKS FOR PROFESSIONALS BY PROFESSIONALS
®
A
ndroid Recipes teaches you how to develop top-notch apps using a proven
problem-solution approach. First, a problem is identified. Then a clear expla-
nation of the solution is given, supported by a fully worked code sample. Best of
all, you can apply all the code examples found in the book directly to your own
projects—saving you time and a great deal of work!
This new edition offers more than 100 down-to-earth recipes that will teach
you how to:
•
Use external libraries to save time and effort
•
Boost app performance by using the Android NDK and Renderscript
•
Design apps for performance, responsiveness, and seamlessness
•
Send data between devices and other external hardware
•
Persist application data and share it between applications
•
Capture and play back various device media items
•
Communicate with web services

and Contents at a Glance links to access them.
www.it-ebooks.info
iii

Contents at a Glance
 Foreword xviii
 About the Authors xix
 About the Technical Reviewer xx
 Acknowledgments xxi
 Preface xxii
 Chapter 1: Getting Started with Android 1
 Chapter 2: User Interface Recipes 99
 Chapter 3: Communications and Networking 323
 Chapter 4: Interacting with Device Hardware and Media 421
 Chapter 5: Persisting Data 501
 Chapter 6: Interacting with the System 581
 Chapter 7: Working with Libraries 689
 Chapter 8: Working with Android NDK and Renderscript 743
 Appendix A: Scripting Layer for Android 805
 Appendix B: Android Tools Overview 821
 Appendix C: App Design Guidelines 855
 Appendix D: Univerter Architecture 867
 Index 911
www.it-ebooks.info

1
1
Chapter
Getting Started with
Android

www.it-ebooks.info
CHAPTER 1: Getting Started with Android
2
 Bluetooth, EDGE, 3G, and WiFi support (hardware dependent)
 Camera, GPS, compass, and accelerometer support
(hardware dependent)
 Dalvik virtual machine optimized for mobile devices
 GSM Telephony support (hardware dependent)
 Integrated browser based on the open source WebKit engine
 Media support for common audio, video, and still image
formats (MPEG4, H.264, MP3, AAC, AMR, JPG, PNG, GIF)
 Optimized graphics powered by a custom 2D graphics library;
3D graphics based on the OpenGL ES 1.0, 1.1, or 2.0
specification (hardware acceleration optional)
 SQLite for structured data storage
Although not part of an Android device’s software stack, Android’s rich
development environment (including a device emulator and a plug-in for the
Eclipse integrated development environment [IDE]) could also be considered an
Android feature.
History of Android
Contrary to what you might expect, Android did not originate with Google.
Instead, Android was initially developed by Android, Inc., a small Palo Alto,
California-based startup company. Google bought this company in the summer
of 2005 and released a beta version of the Android SDK in November 2007.
On September 23, 2008, Google released Android 1.0, whose core features
included a web browser, camera support, Google Search, and more. Table 1-1
outlines subsequent releases. (Starting with version 1.5, each major release
comes under a code name that’s based on a dessert item.)
Table 1-1. Android Releases
Version Release Date and Changes

Google subsequently released SDK update 2.0.1 on December 3, 2009,
and SDK update 2.1 on January 12, 2010. Version 2.0.1 focused on
minor API changes, bug fixes, and framework behavioral changes.
Version 2.1 presented minor amendments to the API and bug fixes.
2.2 (Froyo)
Based on Linux
Kernel 2.6.32
Google released SDK 2.2 on May 20, 2009. Changes included the
integration of Chrome’s V8 JavaScript engine into the Browser app,
voice dialing and contact sharing over Bluetooth, Adobe Flash support,
additional app speed improvements through JIT compilation, and USB
tethering and WiFi hotspot functionality.
Google subsequently released SDK update 2.2.1 on January 18, 2011,
to offer bug fixes, security updates, and performance improvements. It
then released SDK update 2.2.2 on January 22, 2011, to provide minor
bug fixes, including SMS routing issues that affected the Nexus One.
Finally, Google released SDK update 2.2.3 on November 21, 2011, and
this contained two security patches.
2.3
(Gingerbread)
Based on Linux
Kernel 2.6.35
Google released SDK 2.3 on December 6, 2010. Changes included a
new concurrent garbage collector that improves an app’s
responsiveness, support for gyroscope and barometer sensing, support
for WebM/VP8 video playback and AAC audio encoding, support for
near field communication, and enhanced copy/paste functionality that
lets users select a word by press-hold, copy, and paste.
Google subsequently released SDK update 2.3.3 on February 9, 2011,
offering improvements and API fixes. SDK update 2.3.4 on April 28,

4.1 (Jelly Bean) Google released SDK 4.1 on June 27, 2012. Features include vsync
timing, triple buffering, automatically resizable app widgets, improved
voice search, multichannel audio, and expandable notifications. An
over-the-air update (version 4.1.1) was released later in July.

In early October, Google released SDK 4.1.2, which offers lock/home
screen rotation support for the Nexus 7, one-finger gestures to
expand/collapse notifications, and bug fixes/performance
enhancements. Then, in late October, Google released SDK 4.2, which
offers Photo Sphere panorama photos, multiple user accounts (tablets
only), a “Daydream” screensaver that activates when the device is idle
or docked, notification power controls, support for a wireless display
(Miracast), and more.
Android Architecture
The Android software stack consists of apps at the top, middleware (consisting
of an application framework, libraries, and the Android runtime) in the middle,
and a Linux kernel with various drivers at the bottom. Figure 1-1 shows this
layered architecture.
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
5

Figure 1-1. Android’s layered architecture consists of several major parts.
Users care about apps, and Android ships with a variety of useful core apps,
which include Browser, Contacts, and Phone. All apps are written in the Java
programming language. Apps form the top layer of Android’s architecture.
NOTE: Apps are written in a nonstandard Java implementation that combines
Android-specific APIs with Java 5 APIs and a small amount of Java 6 (such as the
java.io.File class’s boolean setExecutable(boolean executable,
boolean ownerOnly) method). Because Android does not support most Java 6

Content Providers
: These components encapsulate data (such
as the Browser app’s bookmarks) that can be shared among
apps.

Location Manager
: This component makes it possible for an
Android device to be aware of its physical location.

Notification Manager
: This component lets an app notify the
user of a significant event (such as a message’s arrival)
without interrupting what the user is currently doing.

Package Manager
: This component lets an app learn about
other app packages that are currently installed on the device.
(App packages are discussed later in this chapter.)

Resource Manager
: This component lets an app access its
resources, a topic that’s discussed later in this chapter.

Telephony Manager
: This component lets an app learn about a
device’s telephony services. It also handles making and
receiving phone calls.
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
7

Media Framework
: These libraries, which are based on
PacketVideo’s OpenCORE, support the playback and
recording of many popular audio and video formats, as well as
working with static image files. Supported formats include
MPEG4, H.264, MP3, AAC, AMR, JPEG, and PNG.

OpenGL | ES
: These 3D graphics libraries provide an OpenGL
implementation based on OpenGL ES 1.0/1.1/2.0 APIs. They
use hardware 3D acceleration (where available) or the included
(and highly optimized) 3D software rasterizer.

SGL
: This library provides the underlying 2D graphics engine.

SQLite
: This library provides a powerful and lightweight
relational database engine that’s available to all apps and
that’s also used by Mozilla Firefox and Apple’s iPhone for
persistent storage.

SSL
: This library provides secure sockets layer‒based security
for network communication.
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
8

Surface Manager

considered harmful to other apps, Linux, or users. This security model, which is mostly based on
process level enforcement via standard Linux features (such as user and group IDs), places
processes in a security sandbox.
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
9
By default, the sandbox prevents apps from reading or writing the user’s private data (such as
contacts or e-mails), reading or writing another app’s files, performing network access, keeping
the device awake, accessing the camera, and so on. Apps that need to access the network or
perform other sensitive operations must first obtain permission to do so.
Android handles permission requests in various ways, typically by automatically allowing or
disallowing the request based upon a certificate or by prompting the user to grant or revoke the
permission. Permissions required by an app are declared in the app’s manifest file (discussed
later in this chapter) so that they are known to Android when the app is installed. These
permissions won’t subsequently change.
App Architecture
Android app architecture differs from desktop application architecture. App
architecture is largely based upon components that communicate via intents,
resources that are often used in user interface contexts, a manifest that
describes the app’s components (and more), and an app package that stores
components, resources, and the manifest.
Components
An app consists of
components
(activities, services, broadcast receivers, and
content providers) that run in a Linux process and that are managed by Android:
 Activities present user interface screens.
 Services perform lengthy jobs (such as playing music) in the
background and don’t provide user interfaces.
 Broadcast receivers receive and react to broadcasts from

Action
: A string naming the action to be performed or, in the
case of broadcast intents, the action that took place and is
being reported. Actions are described by Intent constants
such as ACTION_CALL (initiate a phone call), ACTION_EDIT
(display data for the user to edit), and ACTION_MAIN (start up as
the initial activity). You can also define your own action strings
for activating the components in your app. These strings
should include the app package as a prefix
("com.example.project.GET_NEWSFEEDS", for example).

Category
: A string that provides additional information about
the kind of component that should handle the intent. For
example, CATEGORY_LAUNCHER means that the calling activity
should appear in the device’s app launcher as a top-level app.
(The app launcher is briefly discussed in Recipe 1-4.)

Component name
: A string that specifies the fully qualified
name (package plus name) of a component class to use for
the intent. The component name is optional. If set, the Intent
object is delivered to an instance of the designated class. If
not set, Android uses other information in the Intent object to
locate a suitable target.

Data
: The uniform resource identifier of the data on which to
operate (such as a person record in a contacts database).
www.it-ebooks.info

developers of other apps, explicit intents are typically used for app-internal
messages (such as an activity that launches another activity located within the
same app). Android delivers an explicit intent to an instance of the designated
target class. Only the Intent object’s component name matters for determining
which component should get the intent.
An
implicit intent
doesn’t name a target (the component name is not assigned a
value). Implicit intents are often used to start components in other apps. Android
searches for the best component (a single activity or service to perform the
requested action) or components (a set of broadcast receivers to respond to the
broadcast announcement) to handle the implicit intent. During the search,
Android compares the contents of the Intent object to
intent filters
, manifest
information associated with components that can potentially receive intents.
Filters advertise a component’s capabilities and identify only those intents that
the component can handle. They open up the component to the possibility of
receiving implicit intents of the advertised type. If a component has no intent
filters, it can receive only explicit intents. In contrast, a component with filters
can receive explicit and implicit intents. Android consults an Intent object’s
action, category, data, and type when comparing the intent against an intent
filter. It doesn’t take extras and flags into consideration.
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
12
NOTE: Android widely uses intents, which offers many opportunities to replace
existing components with your own components. For example, Android provides the
intent for sending an e-mail. Your app can send this intent to activate the standard
mail app, or it can register an activity that responds to the intent, replacing the

Although an app can include a single activity, it’s more typical for apps to
include multiple activities. For example, the Calculator app also includes an
‘‘advanced panel’’ activity that lets the user calculate square roots, perform
trigonometry, and carry out other advanced mathematical operations.
Activities are described by subclasses of the android.app.Activity class, which
is an indirect subclass of the android.content.Context class.
NOTE: Context is an abstract class whose methods let apps access global
information about their environments (such as their resources and filesystems), and
let apps perform contextual operations, such as launching activities and services,
broadcasting intents, and opening private files.
Activity subclasses override various Activity
life cycle callback methods
that
Android calls during the life of an activity. For example, the SimpleActivity
class in Listing 1-1 extends Activity and also overrides the void
onCreate(Bundle bundle) and void onDestroy() life cycle callback methods.
Listing 1-1. A Skeletal Activity
import android.app.Activity;
import android.os.Bundle;

public class SimpleActivity extends Activity
{
@Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState); // Always call superclass method
first.
System.out.println("onCreate(Bundle) called");
}
@Override

after calling onRestart().
 onResume() is called just before the activity starts interacting
with the user. At this point the activity has the focus and user
input is directed to the activity. Android always calls the
onPause() method after calling onResume(), but only when the
activity must be paused.
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
15
 onPause() is called when Android is about to resume another
activity. This method is typically used to persist unsaved
changes, stop animations that might be consuming processor
cycles, and so on. It should perform its job quickly, because
the next activity won’t be resumed until it returns. Android
calls onResume() after calling onPause() when the activity
starts interacting with the user, and it calls onStop() when the
activity becomes invisible to the user. Many activities
implement onPause() to commit data changes and otherwise
prepare to stop interacting with the user.
 onStop() is called when the activity is no longer visible to the
user. This may happen because the activity is being destroyed
or because another activity (either an existing one or a new
one) has been resumed and is covering the activity. Android
calls onRestart() after calling onStop(), when the activity is
coming back to interact with the user, and it calls the
onDestroy() method when the activity is going away.
 onDestroy() is called before the activity is destroyed, unless
memory is tight and Android is forced to kill the activity’s
process. In this scenario, onDestroy() is never called. If
onDestroy() is called, it will be the final call that the activity

SimpleActivity’s onCreate(Bundle) method. The following example shows you
how to start SimpleActivity2:
Intent intent = new Intent(SimpleActivity.this, SimpleActivity2.class);
SimpleActivity.this.startActivity(intent);
The first line creates an Intent object that describes an explicit intent. It
initializes this object by passing the current SimpleActivity instance’s reference
and SimpleActivity2’s Class instance to the Intent(Context packageContext,
Class<?> cls) constructor.
The second line passes this Intent object to startActivity(Intent), which is
responsible for launching the activity described by SimpleActivity2.class. If
startActivity(Intent) was unable to find the specified activity (which shouldn’t
happen), it would throw an android.content.ActivityNotFoundException
instance.
Figure 1-3 also reveals that onDestroy() might not be called before the app is
terminated. As a result, you should not count on using this method as a place
for saving data. For example, if an activity is editing a content provider’s data,
those edits should typically be committed in onPause().
NOTE: onDestroy() is usually implemented to free system resources (such as
threads) that were acquired in onCreate(Bundle).
The seven life cycle callback methods define an activity’s entire life cycle and
describe the following three nested loops:
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
18
 The
entire lifetime
of an activity is defined as everything from
the first call to onCreate(Bundle) through to a single final call
to onDestroy(). An activity performs all of its initial setup of
‘‘global’’ state in onCreate(Bundle), and it releases all

ACTIVITIES, TASKS, AND THE ACTIVITY STACK
Android refers to a sequence of related activities as a task and provides an activity stack (also
known as history stack or back stack) to remember this sequence. The activity starting the task
is the initial activity pushed onto the stack and is known as the root activity. This activity is
typically the activity selected by the user via the device’s app launcher. The activity that’s
currently running is located at the top of the stack.
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
19
When the current activity starts another, the new activity is pushed onto the stack and takes
focus (becomes the running activity). The previous activity remains on the stack but is stopped.
When an activity stops, the system retains the current state of its user interface.
When the user presses the device’s BACK key, the current activity is popped from the stack (the
activity is destroyed), and the previous activity resumes operation as the running activity (the
previous state of its user interface is restored).
Activities in the stack are never rearranged, only pushed and popped from the stack. Activities
are pushed onto the stack when started by the current activity, and they are popped off the stack
when the user leaves them by pressing the BACK key. As such, the stack operates as a “last in,
first out” object structure.
Each time the user presses BACK, an activity in the stack is popped off to reveal the previous
activity. This continues until the user returns to the home screen or to whichever activity was
running when the task began. When all activities are removed from the stack, the task no longer
exists.
Check out the “Tasks and Back Stack” section in Google’s online Android documentation to learn
more about activities and tasks. You’ll find this documentation located at

Views, View Groups, and Event Listeners
An activity’s user interface is based on
views
(user interface components),

LinearLayout to create a screen where the user enters text and subsequently
clicks the button to display this text via a pop-up message:
@Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
LinearLayout layout = new LinearLayout(this);
final EditText et = new EditText(this);
et.setEms(10);
layout.addView(et);
Button btnOK = new Button(this);
btnOK.setText("OK");
layout.addView(btnOK);
View.OnClickListener ocl;
ocl = new View.OnClickListener()
{
@Override
public void onClick(View v)
{
Toast.makeText(class.this, et.getText(),
Toast.LENGTH_SHORT).show();
}
};
btnOK.setOnClickListener(ocl);
setContentView(layout);
}
After calling its superclass counterpart, onCreate(Bundle) instantiates
LinearLayout. This container arranges its children in a single column or row. Its
default behavior is to arrange the children in a row.
The keyword this is passed to LinearLayout’s constructor, a practice followed

only when ocl does not contain the null reference. However, an even better solution
exists. This solution is presented later in this chapter where resources are discussed.
The toast is created by invoking the android.widget.Toast class’s Toast
makeText(Context context, CharSequence text, int duration) factory
method, where the value passed to duration is one of Toast.LENGTH_SHORT or
Toast.LENGTH_LONG. After the Toast instance has been created, Toast’s void
show() method is called to display the toast for the specified period of time. (The
message fades in when this method is called and fades out after the duration
expires.)
Following listener creation, onCreate(Bundle) invokes Button’s inherited (from
View) void setOnClickListener(View.OnClickListener l) method to register
the previously created listener object with the button.
www.it-ebooks.info
CHAPTER 1: Getting Started with Android
22
Finally, onCreate(Bundle) invokes Activity’s void setContentView(View view)
method. This method is used to install the LinearLayout instance into the
activity’s
view hierarchy
so that the edittext and button widgets can be
displayed in a single row.
NOTE: Although you can create user interfaces by instantiating widget classes, there
are advantages to using resources for this task. This topic is discussed later in this
chapter.
Fragments
Android 3.0 introduced the concept of
fragments
, which are objects that
represent parts of an activity’s user interface. A fragment serves as a modular
section of an activity with its own life cycle and the ability to receive its own