Concepts PDF
Concepts PDF
Hello, Android
Introducing Google’s
Mobile Development Platform, 3rd Edition
This PDF file contains pages extracted from Hello, Android, published by the
Pragmatic Bookshelf. For more information or to purchase a paperback or PDF
copy, please visit http://www.pragprog.com.
Note: This extract contains some colored text (particularly in code listing). This
is available only in online versions of the books. The printed versions are black
and white. Pagination might vary between the online and printer versions; the
content is otherwise identical.
Copyright © 2010 The Pragmatic Programmers, LLC.
You’ll need a good understanding of these key concepts in order to write well-
behaved Android applications, so if you read only one chapter in this book,
read this one.
Each layer uses the services provided by the layers below it. Starting from
the bottom, the following sections highlight the layers provided by Android.
Linux Kernel
Android is built on top of a solid and proven foundation: the Linux kernel.
Created by Linus Torvalds in 1991, Linux can be found today in everything
from wristwatches to supercomputers. Linux provides the hardware abstrac-
tion layer for Android, allowing Android to be ported to a wide variety of
platforms in the future.
Internally, Android uses Linux for its memory management, process manage-
ment, networking, and other operating system services. The Android phone
user will never see Linux, and your programs will not make Linux calls directly.
As a developer, though, you’ll need to be aware it’s there.
Some utilities you need during development interact with Linux. For example,
the adb shell command1 will open a Linux shell in which you can enter other
commands to run on the device. From there you can examine the Linux file
system, view active processes, and so forth, subject to security restrictions.
Native Libraries
The next layer above the kernel contains the Android native libraries. These
shared libraries are all written in C or C++, compiled for the particular hard-
ware architecture used by the phone, and preinstalled by the phone vendor.
1. http://d.android.com/guide/developing/tools/adb.html
• Media codecs: Android can play video and record and play back audio in
various formats including AAC, AVC (H.264), H.263, MP3, and MPEG-4.
See Chapter 5, Multimedia, on page ? for an example.
• Browser engine: For the fast display of HTML content, Android uses the
WebKit library.4 This is the same engine used in the Google Chrome
browser, Apple’s Safari browser, the Apple iPhone, and Nokia’s S60 plat-
form. See Chapter 7, The Connected World, on page ? for an example.
These libraries are not applications that stand by themselves. They exist only
to be called by higher-level programs. Starting in Android 1.5, you can write
and deploy your own native libraries using the Native Development Toolkit
(NDK). Native development is beyond the scope of this book, but if you’re
interested, you can read all about it online.5
Android Runtime
Also sitting on top of the kernel is the Android runtime, including the Dalvik
virtual machine and the core Java libraries.
• The Dalvik VM runs .dex files, which are converted at compile time from
standard .class and .jar files. .dex files are more compact and efficient than
class files, an important consideration for the limited memory and battery-
powered devices that Android targets.
• The core Java libraries that come with Android are different from both
the Java Standard Edition (Java SE) libraries and the Java Mobile Edition
(Java ME) libraries. There is a substantial amount of overlap, however.
In Appendix 1, Java vs. the Android Language and APIs, on page ?, you’ll
find a comparison of Android and standard Java libraries.
2. http://www.sqlite.org
3. See http://www.zdnet.com/blog/burnette/iphone-vs-android-development-day-1/682
for a comparison of iPhone and Android development.
4. http://webkit.org
5. http://d.android.com/sdk/ndk
Joe asks:
What’s a Dalvik?
Dalvik is a virtual machine (VM) designed and written by Dan Bornstein at Google.
Your code gets compiled into machine-independent instructions called bytecodes,
which are then executed by the Dalvik VM on the mobile device.
Although the bytecode formats are a little different, Dalvik is essentially a Java virtual
machine optimized for low memory requirements. It allows multiple VM instances to
run at once and takes advantage of the underlying operating system (Linux) for secu-
rity and process isolation.
Bornstein named Dalvik after a fishing village in Iceland where some of his ancestors
lived.
Application Framework
Sitting above the native libraries and runtime, you’ll find the Application
Framework layer. This layer provides the high-level building blocks you will
use to create your applications. The framework comes preinstalled with
Android, but you can also extend it with your own components as needed.
• Activity Manager: This controls the life cycle of applications (see Section
2.2, It's Alive!, on page 9) and maintains a common “backstack” for user
navigation.
• Resource manager: Resources are anything that goes with your program
that is not code. See Section 2.4, Using Resources, on page ?.
see only these programs, blissfully unaware of all the action going on below
the waterline. As an Android developer, however, you know better.
Applications are programs that can take over the whole screen and interact
with the user. On the other hand, widgets (which are sometimes called gad-
gets), operate only in a small rectangle of the Home screen application.
The majority of this book will cover application development, because that’s
what most of you will be writing. Widget development is covered in Chapter
12, There's No Place Like Home, on page ?.
• Phone dialer
• Email
• Contacts
• Web browser
• Android Market
Using the Android Market, the user will be able to download new programs
to run on their phone. That’s where you come in. By the time you finish this
book, you’ll be able to write your own killer applications for Android.
Now let’s take a closer look at the life cycle of an Android application. It’s a
little different from what you’re used to seeing.
When the user runs an application, Android starts it and brings it to the
foreground. From that application, the user might invoke another application,
or another screen in the same application, and then another and another.
All these programs and screens are recorded on the application stack by the
system’s Activity Manager. At any time, the user can press the Back button
to return to the previous screen on the stack. From the user’s point of view,
it works a lot like the history in a web browser. Pressing Back returns them
to the previous page.
Process != Application
Internally, each user interface screen is represented by an Activity class (see
Activities, on page ?). Each activity has its own life cycle. An application is
one or more activities plus a Linux process to contain them. That sounds
pretty straightforward, doesn’t it? But don’t get comfortable yet; I’m about to
throw you a curve ball.
In Android, an application can be “alive” even if its process has been killed.
Put another way, the activity life cycle is not tied to the process life cycle.
Processes are just disposable containers for activities. This is probably different
from every other system you’re familiar with, so let’s take a closer look before
moving on.
You override these methods in your Activity class, and Android will call them
at the appropriate time:
• onCreate(Bundle): This is called when the activity first starts up. You can use
it to perform one-time initialization such as creating the user interface.
onCreate() takes one parameter that is either null or some state information
previously saved by the onSaveInstanceState() method.
• onResume(): This is called when your activity can start interacting with the
user. This is a good place to start animations and music.
• onPause(): This runs when the activity is about to go into the background,
usually because another activity has been launched in front of it. This is
where you should save your program’s persistent state, such as a database
record being edited.
• onStop(): This is called when your activity is no longer visible to the user
and it won’t be needed for a while. If memory is tight, onStop() may never
be called (the system may simply terminate your process).
Activities that are not running in the foreground may be stopped, or the Linux
process that houses them may be killed at any time in order to make room
for new activities. This will be a common occurrence, so it’s important that
your application be designed from the beginning with this in mind. In some
cases, the onPause() method may be the last method called in your activity, so
that’s where you should save any data you want to keep around for next time.