Google’s Android mobile phone software platform may be the next big opportunity for application software developers.
Google announced the Open Handset Alliance and the Android platform in November of 2007, releasing the first beta version of the Android Software Development Kit (SDK) at the same time. Within a matter of a few months, over 1 million people had downloaded versions of the SDK from Google’s website. In the United States, T-Mobile announced the G1 Android mobile phone in October of 2008, and estimates are that several hundred thousand G1s were sold before the end of that year. There are already several competing mobile phone software stacks in the market, so why is there such interest in Android?
Android has the potential for removing the barriers to success in the development and sale of a new generation of mobile phone application software. Just as the the standardized PC and Macintosh platforms created markets for desktop and server software, Android, by providing a standard mobile phone application environment, will create a market for mobile applications—and the opportunity for applications developers to profit from those applications.
Why hasn’t it been profitable to develop mobile applications for smartphones until now? And what are the problems that Android alleviates?
About 70 million smartphones were sold in 2007, so there are a lot of phones available to run applications, but each brand has a different application environment. This is particularly true of Linux-based phones, where each handset vendor has had to assemble scores of pieces of third-party software to create a viable mobile phone platform. There is no chance that they would all choose the same components to build a mobile smartphone.
Java was supposed to help this situation, with J2ME and the wireless Java recommendations (CDC, CLDC, MIDP, JTWI, MSA, etc.) providing a common applications environment across handsets. Unfortunately, almost every handset that supports J2ME also support vendor-proprietary extensions that limit the portability of applications.
Most existing smartphones use proprietary, relatively closed software stacks, such as Nokia’s Series 60 with the Symbian operating system, or Microsoft’s Windows Mobile. Modifications to these stacks (adding a driver, for example) have to be done either by the stack owner or by the handset manufacturer. The stacks are not open source, so changing anything in the stack is difficult at best. Most Linux-based phones to date have an open source kernel (as required by the GPL license), but keep other details of the software stack (application framework, multimedia framework, applications) proprietary.
Series 60 and Windows Mobile do allow the addition of third-party applications, but mobile operators often lock the handsets so applications cannot be added. The operators claim this is needed to preserve the integrity of their mobile networks, making sure that viruses and spam are not inadvertently installed by end users. It also suits the operator’s business model, because their mobile phone customers are confined to the operators’ “walled garden” of applications, both on the phone and in the network. Android includes an open catalog of applications, Android Market, that users can download over the air to their Android phones. It also allows direct loading of applications via USB connection.
Android gives developers a way to develop unique, creative applications and get those applications in the hands of customers. Hundreds of thousands of Android mobile phone users are already there, looking for the next clever or useful application, and that application could be yours.
This alliance shares a common goal of fostering innovation on mobile devices and giving consumers a far better user experience than much of what is available on today’s mobile platforms. By providing developers a new level of openness that enables them to work more collaboratively, Android will accelerate the pace at which new and compelling mobile services are made available to consumers.
For us as mobile application developers, that means we are free to develop whatever creative mobile applications we can think of, free to market them (or give them, at our option) to Android mobile phone owners, and free to profit from that effort any way we can. Each member of the Open Handset Alliance has its own reasons for participating and contributing its intellectual property, and we are free to benefit.
The Open Handset Alliance integrates contributed software and other intellectual property from its member companies and makes it available to developers through the open source community. Software is licensed through the Apache V2 license, which you can see at http://www.apache.org/licenses/LICENSE-2.0.txt. Use of the Apache license is critical, because it allows handset manufacturers to take Android code, modify it as necessary, and then either keep it proprietary or release it back to the open source community, at their option. The original Alliance members include handset manufacturers (HTC, LG, Motorola, Samsung), mobile operators (China Mobile Communications, KDDI, DoCoMo, Sprint/Nextel, T-Mobile, Telecom Italia, Telefonica), semiconductor companies (Audience, Broadcom, Intel, Marvell, NVidia Qualcomm, SiRF, Synaptics), software companies (Ascender, eBay, esmertec, Google, LivingImage, LiveWire, Nuance, Packet Video, SkyPop, SONiVOX), and commercialization companies (Aplix, Noser, TAT, Wind River). The Alliance includes the major partners needed to deliver a platform for mobile phone applications in all of the major geographies.
The Alliance releases software through Google’s developer website (http://developer.android.com). The Android SDK for use by application software developers can be downloaded directly from that website. (The Android Platform Porting Kit for use by handset manufacturers who want to port the Android platform to a handset design is not covered in this book.)
Applications in Android are a bit different from what you may be used to in the desktop and server environments. The differences are driven by a few key concepts unique to the mobile phone environment and unique to Google’s intentions for Android. As you write applications for an Android handset, you will use these concepts to guide the design and implementation of the application:
Mobile phones today are very powerful handheld computers, but they are still limited. The fundamental limitation of a mobile device is battery capacity. Every clock tick of the processor, every refresh of memory, every backlit pixel on the user’s screen takes energy from the battery. Battery size is limited, and users don’t like frequent battery charging. As a result, the computing resources are limited—clock rates are in the hundreds of MHz, memory is at best a few gigabytes, data storage is at best a few tens of gigabytes. Throughout this book we will talk about the mechanisms included in Android to optimize for these limited resources.
In other mobile software environments, applications are coded to access data from specific data providers. If you need to send an email from a Windows Mobile application, for example, you code explicit references to Pocket Outlook’s email interface, and send the email that way. But what if the user wants to use another email client?
Android incorporates a fundamental mechanism (Intents) that is independent of specific application implementations. In an Android application, you don’t say you want to send email through a specific application; instead, you say you want to send an email through whatever application is available. The operating system takes care of figuring out what application can send emails, starts that application if needed, and connects your request so the email can be sent. The user can substitute different browsers, different MP3 players, or different email clients at will, and Android adapts automatically.
These are comparable to standalone utilities on desktop systems, such as office applications. Activities are pieces of executable code that come and go in time, instantiated by either the user or the operating system and running as long as they are needed. They can interact with the user and request data or services from other activities or services via queries or Intents (discussed in a moment).
Most of the executable code you write for Android will execute in the context of an Activity. Activities usually correspond to display screens: each Activity shows one screen to the user. When it is not actively running, an Activity can be killed by the operating system to conserve memory.
These are analogous to services or daemons in desktop and server operating systems. They are executable pieces of code that usually run in the background from the time of their instantiation until the mobile handset is shut down. They generally don’t expose a user interface.
The classic example of a Service is an MP3 player that needs to keep playing queued files, even while the user has gone on to use other applications. Your application may need to implement Services to perform background tasks that persist without a user interface.
These respond to requests for service from another application. A Broadcast Receiver responds to a system-wide announcement of an event. These announcements can come from Android itself (e.g., battery low) or from any program running on the system. An Activity or Service provides other applications with access to its functionality by executing an Intent Receiver, a small piece of executable code that responds to requests for data or services from other activities. The requesting (client) activity issues an Intent, leaving it up to the Android framework to figure out which application should receive and act on it.
Intents are one of the key architectural elements in Android that facilitate the creation of new applications from existing applications (mobile mashups). You will use Intents in your application to interact with other applications and services that provide information needed by your application. Intents and Intent Receivers are covered in more detail in Chapter 13.
These are created to share data with other activities or services. A content provider uses a standard interface in the form of a URI to fulfill requests for data from other applications that may not even know which content provider they are using. For example, when an application issues a query for Contact data, it addresses the query to a URI of the form:
The operating system looks to see which applications have registered themselves as content providers for the given URI, and sends the request to the appropriate application (starting the application if it is not already running). If there is more than one content provider registered for the requested URI, the operating system asks the user which one he wants to use.
An application doesn’t have to use all of the Android components, but a well-written application will make use of the mechanisms provided, rather than reinventing functionality or hardcoding references to other applications. URIs and Intents together allow Android to provide a very flexible user environment. Applications can be easily added, deleted, and substituted, and the loose coupling of intents and URIs keeps everything working together.
Android is designed around the unique requirements of mobile applications. In particular, Android recognizes that resources (memory and battery, for example) are limited on most mobile devices, and provides mechanisms to conserve those resources. The mechanisms are evident in the Android Activity Lifecycle, which defines the states or events that an activity goes through from the time it is created until it finishes running. The lifecycle is shown diagrammatically in Figure 1-1.
Called when your activity is first created. This is the
place you normally create your views, open any persistent
datafiles your activity needs to use, and in general initialize
your activity. When calling
onCreate, the Android framework is
Bundle object that
contains any activity state saved from when the activity ran
Called just before your activity becomes visible on the
completes, if your activity can become the foreground activity
on the screen, control will transfer to
onResume. If the activity cannot
become the foreground activity for some reason, control
transfers to the
Called right after
onStart if your activity is the foreground activity on the
screen. At this point your activity is running and interacting
with the user. You are receiving keyboard and touch inputs, and
the screen is displaying your user interface.
is also called if your activity loses the foreground to
another activity, and that activity eventually exits, popping
your activity back to the foreground. This is where your
activity would start (or resume) doing things that are needed to
update the user interface (receiving location updates or running
an animation, for example).
Called when Android is just about to resume a different activity, giving that activity the foreground. At this point your activity will no longer have access to the screen, so you should stop doing things that consume battery and CPU cycles unnecessarily. If you are running an animation, no one is going to be able to see it, so you might as well suspend it until you get the screen back. Your activity needs to take advantage of this method to store any state that you will need in case your activity gains the foreground again—and it is not guaranteed that your activity will resume. If the mobile device you are running on runs out of memory, there is no virtual memory on disk to use for expansion, so your activity may have to make way for a system process that needs memory. Once you exit this method, Android may kill your activity at any time without returning control to you.
The last chance for your activity to do any processing
before it is destroyed. Normally you’d get to this point because
the activity is done and the framework called its
finish method. But as mentioned
earlier, the method might be called because Android has decided
it needs the resources your activity is consuming.
It is important to take advantage of these methods to provide the best user experience possible. This is the first place in this book we’ve discussed how programming for mobile devices is different from programming for desktop devices, and there will be many more such places as you go through later chapters. Your users will appreciate it if you write your activities with the activity lifecycle in mind, and you will ultimately benefit.
Services can be started when a client calls the
If the service isn’t already running, Android starts it and
followed by the
method. If the service is already running, its
onStart method is invoked again with
the new intent. So it’s quite possible and normal for a
onStart method to
be called repeatedly in a single run of the service.
onStopare not needed
If a client needs a persistent connection to a service, it
can call the
Context.bindService method. This
creates the service if it is not running, and calls
onCreate but not
onStart. Instead, the
onBind method is called with the
client’s intent, and it returns an
IBind object that the client can use
to make further calls to the service. It’s quite normal for a
service to have clients starting it and clients bound to it at
the same time.
As with an activity, the
onDestroy method is called when the
service is about to be terminated. Android will terminate a
service when there are no more clients starting or bound to it.
As with activities, Android may also terminate a service when
memory is getting low. If that happens, Android will attempt to
restart the service when the memory pressure passes, so if your
service needs to store persistent information for that restart,
it’s best to do so in the
Android is a sophisticated platform whose parts all work together: drawing and layout, inter-process communication and data storage, search and location. Introducing it in pieces is a challenge, but we’ve entertained the conceit of introducing the complexities of the platform in a linear order.
The platform is also so rich that we can’t hope to show you how to use everything you want, or even a large subset of its capabilities. We expect you to consult the official documentation while reading this book and trying the examples. You should also use other online resources—but be careful about web pages or forum postings that have been around a while, because interfaces change. There is also a substantial amount of misinformation out on the Web; we discovered scads of it while writing the book.
This book is written for experienced developers who want to quickly learn what they need to know to build Android applications. The book is written with references to an example application (MJAndroid, discussed in much more detail in the next chapter) that you can freely download and reuse. The major topics covered in the book include:
Android builds upon a lot of legacy technology (Java, Linux, and the Internet, just to name a few), but it also introduces some new concepts needed to enable the application environment.
We’ll show how to install the free, open source Android development environment on your own system, and how to use that environment to develop, test, and debug your own applications. You’ll not only learn the mechanics of using the system, but also what’s going on behind the scenes, so you’ll have a better understanding of how the whole system fits together.
The Android user interface elements are similar to things you’ve seen before, but also different. We’ll show you what the principal elements are, how they’re used, and what they look like on the screen. We’ll also show you the basic layout types available for the Android screen.
Android makes it easy to leverage existing applications through the use of Intents. For example, if you want to dial a phone number, you don’t have to do all the work in your application, or even know what applications are available that know how to dial. You can just ask Android to find you an installed application that knows how to dial out, and pass it the string of numbers.
As you’d expect from a Google-sponsored environment, mapping and location are major features of Android. You’ll see how easy it is to create sophisticated mapping and location-based applications.
Android includes the
SQLite database libraries and tools,
which your application can use to store persistent data. Content
providers, which we’ve already introduced, provide data to other
applications. Using the libraries can be a little tricky, but in
Chapter 8 we’ll guide you
through the creation of a database, and reading, writing, and
deleting data records.
Your application has access to 2D and 3D graphics capabilities in Android. Animation and various advanced effects are also provided. This book will show you how to use those libraries so you can build a compelling user interface for your application.
Android, even more than most smartphone operating systems, places great emphasis on communication—by voice, by text messaging, by instant messaging, and by Internet. You’ll see how your application can take advantage of these capabilities so your users can become part of a larger community of data and users.
The next three chapters, Chapters 2 through 4, set you up with a working application, and will give you a sense of how the files and basic classes fit together. Chapter 5 empowers you to better understand what you’re doing and helps you debug your first efforts.
The Android toolkit naturally comes with an enormous number of working code examples in its ApiDemos application. Unfortunately, its very size and sophistication make it a formidable castle for novices to enter. Chapter 6 guides you through it.
A bit of experience with ApiDemos will convince you that you need some more background and tutorial help. In Chapter 7, we’ll show you how to sign and publish your application, which you need to do in order to test it with Google Maps, even before you’re ready to go public.
Chapter 8 presents tutorials on two data storage systems.
Chapter 9 presents location and mapping, which are key features that draw people to mobile devices and which you’ll surely want to incorporate into your application.
Chapter 13 takes another step into the complexity and unique power of Android, by discussing how applications can offer functionality to other applications. This allows for powerful mashups, which involve one program standing on the shoulders of other programs.
There’s even more to Android than these features, of course, but programmers of all stripes will find in this book what they need to create useful and efficient programs for the Android platform.