Chapter 1: All about Android

In This Chapter

Your take on Android (depending on who you are)

A tour of Android technologies

Until the mid-2000s, the word “Android” stood for a mechanical humanlike creature — a root’n toot’n officer of the law with built-in machine guns, or a hyperlogical space traveler who can do everything except speak using contractions. But in 2005, Google purchased Android, Inc. — a 22-month-old company creating software for mobile phones. That move changed everything.

In 2007, a group of 34 companies formed the Open Handset Alliance. The Alliance’s task is “to accelerate innovation in mobile and offer consumers a richer, less expensive, and better mobile experience.” The Alliance’s primary project is Android — an open, free operating system based on the Linux operating system kernel.

HTC released the first commercially available Android phone near the end of 2008. But in the United States, the public’s awareness of Android and its potential didn’t surface until early 2010. Where I’m sitting in August 2011, Canalys reports that nearly half all smartphones in the world run Android.* (I know. You’re sitting sometime after August 2011. But that’s okay.)

The Consumer Perspective

A consumer considers the alternatives.

• Possibility #1: No mobile phone.

Advantages: Inexpensive, no interruptions from callers.

Disadvantages: No instant contact with friends and family. No calls to services in case of an emergency. No handheld games, no tweeting, tooting, hooting, homing, roaming, or booping. And worst of all, to break up with your boyfriend or girlfriend, you can’t simply send a text message.

• Possibility #2: A feature phone.

I love the way the world makes up fancy names for less-than-desirable things. A feature phone is a mobile phone that’s not a smartphone. There’s no official rule defining the boundary between feature phones and smartphones. But generally, a feature phone is one with an inflexible menu of home-screen options. A feature phone’s menu items relate mostly to traditional mobile phone functions, such as dialing, texting, and maybe some web surfing and gaming. In contrast, a smartphone’s home screen provides access to the underlying file system, has icons, customizable skins, and many other features that used to be available only to general-purpose computer operating systems.

Advantages: Cheaper than a smartphone.

Disadvantages: Not as versatile as a smartphone. Not nearly as cool as a smartphone. Nowhere near as much fun as a smartphone.

• Possibility #3: An iPhone.

Advantages: Great graphics. More apps than any other phone platform.

Disadvantages: Little or no flexibility with the single-vendor iOS operating system. Only a handful of different models to choose from. No sanctioned “rooting,” “modding,” or “jailbreaking” the phone. No hesitation permitted when becoming a member of the Mystic Cult of Apple Devotees.

• Possibility #4: A Windows phone, a BlackBerry, a WebOS phone, or some other non-Android, non-Apple smartphone.

Advantages: Having a smartphone without belonging to a crowd.

Disadvantages: The possibility of owning an orphan product when the smartphone wars come to a climax.

• Possibility #5: An Android phone.

Advantages: Using an open platform. Using a popular platform with lots of industry support and with powerful market momentum. Writing your own software and installing the software on your own phone (without having to post the software on a company’s website). Publishing software without facing a challenging approval process.

Disadvantages: Security concerns when using an open platform. Worry over a number of lawsuits heaped upon Android manufacturers in 2011. Dismay when iPhone users make fun of your phone.

For me, Android’s advantages far outweigh the possible disadvantages. And you’re reading a paragraph from Android Application Development All-in-One For Dummies, so you’re likely to agree with me.

Having decided to go with an Android phone, the consumer asks, “Which phone?” And the salesperson says, “This phone comes with Android 4.0” (which means “This phone comes with Android 2.3, which will eventually be upgraded to Android 4.0, or so claims the vendor”). So the consumer asks, “What are the differences among all the Android versions?”

Android comes with a few different notions of “version.” Android has platform numbers, API levels, codenames, and probably some other versioning schemes. (The acronym API stands for Application Programming Interface — a library full of prewritten programs available for use by a bunch of programmers. In this case, the “bunch” consists of all Android developers.)

To complicate matters, the versioning schemes don’t increase in lockstep. For example, from platform 1.5 to 1.6, the API level goes from 3 to 4. But platform 2.3 sports two API levels — level 9 for platform 2.3.1 and level 10 for platform 2.3.3. Versions that are skipped (such as API level 5 and platform 2.5) are lost in the annals of Android development history.

An Android version may have variations. For example, plain old Android 2.2 has an established set of features. To plain old Android 2.2, you can add the Google APIs (thus adding Google Maps functionality) and still use platform 2.2. You can also add a special set with features tailored for the Samsung Galaxy Tab.

Most consumers know Android’s versions by their codenames. Unlike Apple (which names its operating systems after ferocious cats) or automakers (who name their SUVs after cowboys), Google names Android versions after desserts. (See Table 1-1.) I’m waiting impatiently for a version codenamed Chocolate. (Maybe one will be released by the time you read this book.)

As a developer, your job is to balance portability with feature richness. When you create an app, you specify a target Android version and a minimum Android version. (You can read more about this in Chapter 3 of this minibook.) The higher the version, the more features your app can have. But the higher the version, the fewer devices that can run your app. Fortunately, this book has lots of tips and tricks for striking a happy medium between whiz-bang features and universal use.

The Developer Perspective

Android is a multi-faceted beast. When you develop for Android, you use many toolsets. This section has a brief rundown.

Java

James Gosling from Sun Microsystems created the Java programming language in the mid-1990s. (Sun Microsystems has since been bought out by Oracle.) Java’s meteoric rise in use came from the elegance of the language and the well-conceived platform architecture. After a brief blaze of glory with applets and the web, Java settled into being a solid, general-purpose language with special strength in servers and middleware.

In the meantime, Java was quietly seeping into embedded processors. Sun Microsystems was developing Java ME (Mobile Edition) for creating midlets to run on mobile phones. Java became a major technology in Blu-ray disc players. So the decision to make Java the primary development language for Android apps is no big surprise.

An embedded processor is a computer chip that’s hidden from the user as part of some special-purpose device. The chips in today’s cars are embedded processors, and the silicon that powers your photocopier at work is an embedded processor. Pretty soon, the flower pots on you windowsill will probably have embedded processors.

The trouble is, not everyone agrees about the fine points of Java’s licensing terms. The Java language isn’t quite the same animal as the Java software libraries, which in turn aren’t the same as the Java Virtual Machine (the software that enables the running of Java programs). So in marrying Java to Android, the founders of Android added an extra puzzle piece — the Dalvik Virtual Machine. And instead of using the official Sun/Oracle Java libraries, Android uses Harmony — an open-source Java implementation from the Apache Software Foundation. Several years and many lawsuits later, companies are still at odds over the use of Java in Android phones.

For more information about Dalvik (the Virtual Machine, not the town in Iceland) see Book II, Chapter 2.

Fortunately for you, the soon-to-be Android developer, Java is deeply entrenched in the Android ecosystem. The time you invest in developing mobile Java-based apps will continue to pay off for a long, long time.

If you already have some Java programming experience, great! If not, you can find a fast-paced introduction to Java in Book II, Chapters 2, 3, and 4. For a more leisurely introduction to Java, buy Java For Dummies, 5th Edition.

XML

If you find View Source among your web browser’s options, you see a bunch of Hypertext Markup Language (HTML) tags. A tag is some text enclosed in angle brackets. The tag describes something about its neighboring content.

For example, to create boldface type on a web page, a web designer writes

<b>Look at this!</b>

The angle-bracketed b tags turn boldface type on and off.

The M in HTML stands for Markup — a general term describing any extra text that annotates a document’s content. When you annotate a document’s content, you embed information about the document’s content into the document itself. So, for example, in the line of code in the previous paragraph, the content is Look at this! The markup (information about the content) consists of the tags <b> and </b>.

The HTML standard is an outgrowth of SGML (Standard Generalized Markup Language). SGML is an all-things-to-all-people technology for marking up documents for use by all kinds of computers running all kinds of software, and sold by all kinds of vendors.

In the mid-1990s, a working group of the World Wide Web Consortium (W3C) began developing XML — the eXtensible Markup Language. The working group’s goal was to create a subset of SGML for use in transmitting data over the Internet. They succeeded. Today, XML is a well-established standard for encoding information of all kinds.

For a technical overview of XML, see Book II, Chapter 5.

Java is good for describing step-by-step instructions, and XML is good for describing the way things are (or the way they should be). A Java program says, “Do this and then do that.” In contrast, an XML document says, “It’s this way, and it’s that way.” So Android uses XML for two purposes:

• To describe an app’s data.

An app’s XML documents describe the look of the app’s screens, the translations of the app into one or more languages, and other kinds of data.

• To describe the app itself.

Each Android app comes with an AndroidManifest.xml file. This XML document describes features of the app. The operating system uses the AndroidManifest.xml document’s contents to manage the running of the app.

For example, an app’s AndroidManifest.xml file describes code that the app makes available for use by other apps. The same file describes the permissions that the app requests from the system. When you begin installing a new app, Android displays these permissions and asks for your permission to proceed with the installation. (I don’t know about you, but I always read this list of permissions carefully. Yeah, right!)

For more information about the AndroidManifest.xml file and about the use of XML to describe an app’s data, see almost any chapter in this book.

Concerning XML, there’s bad news and good news. The bad news is, XML isn’t always easy to compose. At best, writing XML code is boring. At worst, writing XML code is downright confusing.

The good news is, automated software tools compose most of the world’s XML code. As an Android programmer, the software on your development computer composes much of your app’s XML code. You often tweak the XML code, read part of the code for info from its source, make minor changes, and compose brief additions. But you hardly ever create XML documents from scratch.

Linux

An operating system is a big program that manages the overall running of a computer or a device. Most operating systems are built in layers. An operating system’s outer layers are usually right up there in the user’s face. For example, both Windows and Macintosh OS X have standard desktops. From the desktop, the user launches programs, manages windows, and so on.

An operating system’s inner layers are (for the most part) invisible to the user. While the user plays Solitaire, the operating system juggles processes, manages files, keeps an eye on security, and generally does the kinds of things that the user shouldn’t micromanage.

At the very deepest level of an operating system is the system’s kernel. The kernel runs directly on the processor’s hardware, and does the low-level work required to make the processor run. In a truly layered system, higher layers accomplish work by making calls to lower layers. So an app with a specific hardware request sends the request (directly or indirectly) through the kernel.

The best-known, best-loved general purpose operating systems are Windows, Macintosh OS X (which is really Unix), and Linux. Windows and Mac OS X are the properties of their respective companies. But Linux is open-source. That’s one of the reasons why your TiVo runs Linux, and why the creators of Android based their platform on the Linux kernel.

Android’s brand of Linux is an outlier among Linuxes (Linuces?). Based on the Linux 2.6.x kernel, Android uses stripped-down versions of many commonly -used Linux packages. The Android shell lacks many of the commands sported by desktop Linux shells. And instead of glibc, Android uses its own C-language library (named Bionic). There’s also some tooth-gnashing among Linux geeks about the legitimacy of Android’s drivers. So if you attend a Linux rally and you mention Android, be sure to do so with a wry look on your face. This protects you in case the person you’re talking to doesn’t think Android is “real” Linux.

Open-source software comes in many shapes and sizes. For example, there’s the GNU General Public License (GPL), the Apache License, the GNU Lesser General Public License (LGPL), and others. When considering the use of other people’s open-source software, be careful to check the software’s licensing terms. “Open-source” doesn’t necessarily mean “do anything at all for free with this software.”

Figure 1-1 is a diagram of the Android operating system. At the bottom is the Linux kernel, managing various parts of a device’s hardware. The kernel also includes a Binder, which handles all communication among running processes. (When your app asks, “Can any software on this phone tell me the current temperature in Cleveland, Ohio?”, the request for information goes through the kernel’s Binder.)

At the very top of Figure 1-1 are the applications — the web browser, the contacts list, the games, the dialer, your own soon-to-be-developed apps. Both developers and users interact mostly with this layer. Developers write code to run on this layer, and users see the outer surface of the apps created by developers.

As a developer, your most intimate contact with the Android operating system is through the command line, or the Linux shell. The shell uses commands, such as cd to change to a directory, ls to list a directory’s files and subdirectories, rm to delete files, and many others.

Google’s Android Market has plenty of free terminal apps. A terminal app’s interface is a plain text screen in which you type Linux shell commands. And with one of Android’s developer tools, the Android Debug Bridge, you can issue shell commands to an Android device through your development computer. If you like getting your virtual hands dirty, the Linux shell is for you.

For information about operating systems’ command interfaces, see Book VI, Chapter 3. For a look at the Android Debug Bridge, see Chapter 2 of this minibook.

The Business Perspective

I admit it. I’m not an entrepreneur. I’m a risk-averse person with a preference for storing money in mattresses. My closest brush with a startup business was a cab ride in Kuala Lumpur. The driver wanted me to help finance his new restaurant idea. “Not Kentucky Fried Chicken!” he yelled. “Kentucky Fried Duck!”

Anyway, the creation and selling of mobile phone apps is an enormous cottage industry. Google’s Android Market had 300,000 apps in mid-2011. By the time you read this book, the number 300,000 will seem pathetically obsolete. Add the marketing potential of Amazon’s Appstore for Android, and you have some very natural distribution channels for your apps.

Anyone can post an app on Google’s Android Market and on Amazon’s Appstore. You can post free apps, paid apps, and programs with in-app billing. You can test an app with a select group of users before making your app available to everyone. You make a small one-time payment to register as an Android developer. Then you design apps, develop apps, and post apps for the general public.

Book V covers the business of posting apps on Google’s Android Market and Amazon’s Appstore for Android. I don’t promise that you’ll become a millionaire selling Android apps, but I promise that you’ll have fun trying.