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 2014, Canalys reports that, in the year’s first quarter, 81 percent of all new smartphones in the world run Android.* (I know. You’re sitting reading this book sometime after 2014. But that’s okay.)

The Consumer Perspective

A consumer considers the mobile phone 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 hand-held 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, or some other non-Android, non-Apple smartphone.

  Advantages: Having a smartphone without belonging to a crowd.

  Disadvantages: Other smartphones don’t have nearly as many apps as Android phones and Apple phones.

• 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 deal with Apple as an intermediary). Publishing software without facing a challenging approval process.

  Disadvantages: Security concerns when using an open platform. Confusion about the variety of manufacturers, each with different hardware and with some changes to the Android platform. 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, 2nd Edition, 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.4.” (If you read between the lines, what the salesperson really means is “This phone comes with Android 3.2, 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 4.3 has an established set of features. To plain old Android 4.3, you can add the Google APIs (thus adding Google Maps functionality) and still use platform 4.3. You can also add a special set with features tailored for a particular device manufacturer or a particular mobile service provider.

Most consumers know Android’s versions by their codenames. Unlike Apple (which named its operating systems after ferocious cats) or automakers (who name their SUVs after cowboys), Google names Android versions after desserts. (See Figure 1-1.)

A few notes on Figure 1-1 are in order:

• The platform number is of interest to the consumer and to the company that sells the hardware.

  If you’re buying a phone with Android 4.3, for example, you might want to know whether the vendor will upgrade your phone to Android 5.0.

• The API level (also known as the SDK version) is of interest to the Android app developer.

  For example, the word MATCH_PARENT has a specific meaning in Android API levels 8 and higher. You might type MATCH_PARENT in code that uses API level 7. If you do (and if you expect MATCH_PARENT to have that specific meaning), you’ll get a nasty-looking error message.

• The code name is of interest to the creators of Android.

  A code name (also known as the version code) refers to the work done by the creators of Android to bring Android to the next level. Picture Google’s engineers working for months behind closed doors on Project Jelly Bean, and you’ll be on the right track.

  For completeness, I should add that code names are interesting for consumers, too. My taste buds tingle when I reply to “Which Android version are you running?” with the name “KitKat.”

As a rule, platform numbers change faster than API levels, and API levels change faster than codenames. For example, the Android platforms 4.1 and 4.1.1 both belong to API Level 16, and API Levels 16, 17, and 18 all have codename Jelly Bean.

New Android codename releases arrive every year or so. Codenames proceed alphabetically, starting with Cupcake, Donut and Éclair, and (if the trend continues) working their way to Zucchini Bread in this century’s next decade. Depending on a device’s manufacturer, model, and (if applicable) telephone service provider, a device may or may not get upgrades to newer Android releases.

Storks and fairies don’t install updates on your Android devices. The updates come via Wi-Fi or phone service through your carrier or device manufacturer. But by downloading and installing an independently developed Android release, you can break free of the corporate giants. The most popular such release is called CyanogenMod. For more information, visit www.cyanogenmod.org. For information about some other independently developed releases, visit http://forum.xda-developers.com/custom-roms.

As a developer, your job is to balance portability with feature richness. When you create an app, you specify a minimum Android version. (You can read more about this in Chapter 4 of this minibook.) The higher the version, the more features your app can have. But the higher the version, the fewer the 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 multifaceted beast. When you develop for Android, you use many toolsets. This section has a brief rundown.

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 built on top of 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?). For a long time, Google wasn’t merging Android’s modifications of Linux back into the main Linux development tree. This seems to have been resolved in March 2012, but old wounds die hard. Blog posts by Linux and Android experts still waver on the question of Android’s place within the Linux movement. 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-2 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-2 are the applications — the web browser, the contacts list, the games, the dialer, and 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.

The Google Play Store 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 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. The Google Play Store had 1,000,000 apps in mid-2013. By the time you read this book, the number 1,000,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 the Google Play Store 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 VI covers the business of posting apps on the Google Play Store 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.

Notes