Chapter 4: Exploring the Android Platform

Android is a platform of opportunities. It has a massive user and fan base. It is the worldwide leading smartphone platform, and there’s no end in sight for its growth. Android can be found running on hundreds of different devices and many different device categories. With massive success comes lots of challenges. How do you write apps that run on all of these devices? How different are these devices?

This chapter explains what you can expect from the Android devices. It explains what Android fragmentation means and puts this idea in context. The chapter also talks about the opportunities created by the open Android ecosystem and Open Source community.

Challenges of the android platform

You must have heard about Android fragmentation. It seems to be a buzzword of bloggers and journalists trying to get more interest in their articles. This term is often thrown around without any true understanding of what it means and how it affects developers and users. People often say fragmentation when they actually mean the variation in devices that Android runs on.

There’s no need to panic. The Android platform was built from the ground up to give developers good tools to support multiple different devices. Utilizing the platform tools correctly will help you to support most, if not all, the devices out there. That is not to say that supporting all these devices is free. It requires work and planning but can be done with reasonable effort, if you approach it correctly.

But what does fragmentation mean in practice, and where does it come from? If you walk into a mobile carrier store and look around, it is nearly impossible to recognize which of the phones on the shelves are Android phones and which aren’t unless you’re an expert. Android phones are not built by a single manufacturer, and Android also doesn’t have strict limitations about the hardware it runs on. This means that almost all manufacturers have created their own design language for the software and hardware.

The Android platform is also very open for customization by its users. Users don’t need to hack or jail-break their phones to replace the home screen, app launcher, or keyboard. Replacements for al of these features can be downloaded from Google Play. They are just apps that connect different platform intents (more about intents in Chapter 6).

This chapter covers how Android devices differ from each other—in terms of hardware and software—and seeks to give you an understanding of what a true Android device is.

Hardware

It all starts with the hardware. There is no such thing as standard Android hardware. Android is Open Source, and nobody can stop anyone from putting Android on anything they like. I have seen Android running on washing machines, ski goggles, and wristwatches. These are the extremes, though. Although a correctly written Android app will probably be usable on a wristwatch, it probably won’t be very good. I think that in this context it is pretty safe to exclude the extremes and concentrate on the more normal devices.

Even if you talk about mass-produced devices, the variation in hardware is massive. Android runs on very low-end smartphones with small displays, barely any memory, and cheap (and slow) CPUs. It also runs on the latest super phones with high-density displays, high-end multi-core GPUs, CPUs, and large memories. But it doesn’t stop there. Android also runs on tablets and even on TVs.

There you have it. It is surely impossible to build software for the Android platform. There’s no way the same app could run on a 2-inch cheap phone screen, on a 10-inch tablet screen, and on a 55-inch TV screen. Fortunately things aren’t as bad as all that. The variety of devices does present a challenge. However, with a right approach, it is possible to support most, if not all, of the devices.

Open Source Software

Open Source software is distributed under various Open Source licenses. These licenses vary from strict licenses that require any derived software to be distributed under the same license to more permissive licenses that allow the license terms to be changed when derived software is distributed. GPL, which is used in the Linux kernel, is a common example of a stricter Open Source license. Everyone distributing software based on the Linux kernel must distribute their work under GPL. The Apache license, on the other hand, allows people to take Apache-licensed software and distribute derived work under any other license. The Android project is distributed under the Apache license. All Open Source licenses allow users to modify and redistribute the code. Read more at http://opensource.org/.

Google’s control

As mentioned earlier, Android is Open Source, so the license permits anyone putting it on any device they want. Google doesn’t force any control on Android devices. They do, however, have something called the Android Compatibility Program. The program defines a large number of hardware and software requirements. A device will ship with Google apps and especially Google Play, if has passed the compatibility requirements.

Tablets

Tablets seem to be the latest boom in the mobile market. Every manufacturer is building its own tablet devices. How can you prepare for tablets in Android design?

Let’s draw an analogy from iOS. Those guys have it easy. They either target the iPad or the iPhone and that’s it. Can you do the same? The answer is no. Android devices cannot be categorized to tablets and phones so easily. Where does a tablet start and phone end? If you have a phone with a 5-inch display, will a phone user interface be better for it than a tablet user interface? What about a 7-inch tablet and a 13-inch tablet? Is there a tablet design that works on both?

Android devices are a continuum instead of a clear separation between two device categories. You should try to avoid talking about designing for tablet or designing for phones. Android apps should not have a separate tablet-user interface. This doesn’t mean that a user interface designed for phone screens will work perfectly on a larger screen. Due to the lack of clear separation between device categories and big difference in devices in each category, it is important that Android user interfaces are scalable. This situation is very familiar to any web designer or developer. Web designers have solved the same problem using something called responsive design. Responsive web pages rearrange their components when necessary to create optimal performance for any screen resolution.

OEM distributions, skins, and themes

Android devices are manufactured by hundreds of different manufacturers. These devices are then marketed by dozens of carriers all around the world. Both the manufacturers and carriers often want to make their own modifications to the operating system. Many of the larger manufacturers have created fully themed Android distributions featuring original equipment manufacturer (OEM) skins. Probably the best known examples of these are HTC Sense and Samsung TouchWiz. The OEM skins add their own features and functionality on top of the default Android experience. The main home page of phones is often altered drastically to make the phone’s branding stand out. See Figure 4-1 for examples of three manufacturer home screens.

Figure 4-1: Home screens from left to right by HTC, Samsung, and Sony on their Android 2.3 devices.

Sources: HTC Corporation, SAMSUNG, and Sony Mobile Communications AB

Although the OEM skins rarely break compatibility, they can make detailed visual design more difficult. A typical change the manufacturers tend to make is to change the system default colors. For example in Android 2.3, the default highlight color for buttons and text fields is orange, but on HTC devices it is green, and Sony devices use blue. In Figure 4-2, you can see how much the manufacturers have changed the default component look and feel; it shows a window from three different manufacturers. Buttons on the top part are in their default states and in the bottom part the OK button is in its pressed state. All of these screenshots are from Android 2.3. This demonstrates how much Android visuals can vary even inside one Android version. Especially noteworthy is that on Sony device the window has a header part whereas on other devices it does not.

Figure 4-2: A window and buttons with default themes from HTC, Samsung, and Sony.

Sources: HTC Corporation, SAMSUNG, and Sony Mobile Communications AB

In addition to visual changes, manufacturers tend to bundle their own versions of Android default apps. Often, the dialer, messenger, or contact app is replaced. Although they do good work ensuring compatibility by making the intent interface the same (intents are explained in more detail in Chapter 6), there can be some nasty surprises on some devices when they are depending on the default Android apps. In Figure 4-3 you can see the dialer apps manufacturers have used to replace Android’s default dialer.

Figure 4-3: Manufacturer dialer app replacements from left to right: HTC, Samsung, and Sony. All screenshots are from Android 2.3.

Sources: HTC Corporation, SAMSUNG, and Sony Mobile Communications AB

Holo theme unifies Android app look

Starting with Android 4.0, all manufacturers are required to include Android Holo themes in their Android distribution to fulfill the Android compatibility requirements. In practice this means that developers and designers can depend on the default themes and define their user interfaces by using the default themes or extending them. The apps will look the same on all Android 4.0 or newer devices. Figures 4-4 and 4-5 show two example apps using the two default themes—one light and one dark. Note that developers must set their app’s target SDK level to Android 4.0 or newer for the apps to utilize this new look.

Keyboard replacements

All Android released APIs are open to every application. Everything Google is doing in their apps can be done in any other app. The open APIs leave the door open to third-party replacements for everything, including the keyboard.

As a designer you cannot assume that the user is using the default keyboard. It is possible that the user has replaced the keyboard that was shipped with their phone with something they got from the Android Market. The third-party keyboards can differ radically from the default keyboards. The user might not be typing in one key at time but instead using a cluster of keys. So don’t rely on individual key presses on any design. In fact, the users might not be pressing any keys at all. Figures 4-6, 4-7, and 4-8 show different keyboards.

Figure 4-8: This is the standard Android voice input mode. It is used instead of a keyboard.

Source: Android

Given the changes in this field in the past few years, it’s hard to even imagine what kind of keyboards there will be in the future.

Third-party home screen replacements

Users can replace the Android home screen (OEM or Google). Replacing the home screen and the app launcher is literally as simple as installing an app from Google Play.

The home screen is a central app of the phone, and replacing it can change the phone’s behavior and feel radically. The home screen or app launcher changes are not visible to normal apps though. Once an app is launched, its behavior stays unchanged no matter which home screen or launcher you used to start it.

Although most of the home screen replacements support standard Android home screen widgets, they often provide extra APIs that developers can use to build home screen widgets for that home screen replacement. Some popular launchers have managed to gain enough momentum to create mini ecosystems of people building and distributing apps and themes that work only on that home screen replacement.

Go Launcher (see Figure 4-9) is probably the most popular home screen replacement ecosystem in current circulation. The core app itself has more than 10 million downloads from Google Play. There are hundreds of themes, widgets, and plug-ins for the Go Launcher. Users can use them to make their home screen much more interactive than the default Android APIs allow.

Other popular and noteworthy home screen replacement is the ADW Launcher (see Figure 4-10). ADW Launcher is noteworthy because of its popularity, but also because it is the default home screen on the most popular third-party ROM, CyanogenMod (more about ROMs later in this chapter).

Home screen replacements don’t end here. At the time of this writing, there are nearly 150 home screen replacement apps available for Android phones.

Android versions

An Android OS version has a name and version number. Google uses dessert names in alphabetical order. Not every new release receives a new name though. For example, both 2.0 and 2.1 are release Eclair and 3.0, 3.1, and 3.2 are Honeycomb. Versions without a new name can be seen as minor updates, and it is fairly safe to assume that all devices will get updates to the largest version number of a named release. The Android update cycle is about six months.

Technically Android versions are differentiated with number code called the API level. API levels run sequentially from API level 1 upward. Whenever there’s a change in Android API the number is increased.

Every Android version has a name, version number, and API level. Table 4-1 shows a list of Android versions released so far. As you see, there are some missing versions like Android 2.0. That is a version that was updated to Android 2.1 so soon that no devices have it anymore, so there is no point listing it. Android 3.0 – 3.2 Honeycomb is likely to have the same fate. I believe that all Honeycomb devices will be updated to Ice Cream Sandwich or above very soon.

Table 4-1 Android Versions, Their Names, and the API Level Code

Android Version	Name	API Level
Android 1.5	Cupcake	3
Android 1.6	Donut	4
Android 2.1	Eclair	7
Android 2.2	Froyo	8
Android 2.3 – 2.3.2	Gingerbread	9
Android 2.3.3 – 2.3.7	Gingerbread	10
Android 3.0	Honeycomb	11
Android 3.1	Honeycomb	12
Android 3.2	Honeycomb	13
Android 4.0 – 4.0.2	Ice Cream Sandwich	14
Android 4.0.3	Ice Cream Sandwich	15
Android 4.1 – 4.1.1	Jelly Bean	16

Google releases accurate numbers of Android version distribution on devices on the Android developer website. The numbers are updated relatively often and are usually very current. The version distribution numbers are based on Android devices that access Google Play within a 14-day period. The version distribution chart can be found here: http://developer.android.com/resources/dashboard/platform-versions.html.

Android on tablets

Android Honeycomb was an exception to the normal release cycle. It was a tablet-only Android version. It was only ever released to selected manufacturers to be put on tablet devices, and the source code was never released. It is safe to assume that a large majority of devices that shipped with Honeycomb will be updated to Android 4.0 Ice Cream Sandwich or newer. I recommend ignoring Honeycomb and targeting the Ice Cream Sandwich instead.

Android Jelly Bean, the latest android release

At the Google I/O 2012 conference Google announced the Android 4.1 Jelly Bean. At the time of writing this it is the latest Android version. The Jelly Bean release follows the visual guidelines set in the previous Android 4.0 Ice Cream Sandwich release. The Android 4.1 added only few new features, but it improved a lot on some existing features, like adding expandable notifications and offline voice input. The latest version greatly improved Android user interface speed and responsiveness. In the last two releases Android has truly matured as an operating system.

Nexus Devices

Usually, Google releases an updated Android version in cooperation with a device manufacturer. This device acts as a reference implementation of the new OS version. This line of devices is called the Nexus devices.

A Nexus phone always ships with vanilla Android (which means no manufacturer skins or any other third-party customizations). Some carriers still put their own apps on them, though. Nexus devices are also updated directly by Google, which in practice means that they get new Android version updates before other devices. This makes them ideal developer devices.

Previous Nexus devices have been Nexus One built by HTC, Nexus S, and Galaxy Nexus built by Samsung. Other devices that basically belong to this same series but don’t carry the Nexus name are the very first Android phone HTC G1, Motorola Droid, and Motorola Xoom tablet. They also were used to release a new Android version and shipped without any manufacturer customization.

Updates to older devices

Android has become infamous for not updating old devices to newer OS versions. Some manufacturers do a better job than others maintaining their older devices, but many of them simply ignore all devices that are older than one year.

Manufacturer unwillingness to support old devices hinders Android version propagation. Historically, it has taken at least a year from a new version release for it to gain significant enough market share to be viable target to be developed for. It is safe to assume that this trend will continue.

Which version should you target?

Selecting the minimum Android version to support is tricky, but here are few guidelines. As a rule of thumb you should try to support all Android versions. In practice this is not always possible. New versions bring new APIs and new features that are often very desirable. If you find that you need some of the newer features, you might have to start raising the minimum supported Android version of your app.

First, take a look at the latest Android version distribution numbers from the Developer Dashboard mentioned previously. At the time of this writing, it is clear that Android versions 1.5 and 1.6 can be ignored without much thought, as their distributions are 0.4% and 0.8%, respectively.

Secondly, determine whether the features you need are optional or mandatory. Features that only improve your app’s functionality are optional, for example. You can use simple coding tricks to enable them on devices that support them and leave them out of older versions.

A good example of this kind of functionality is multi-touch gesture support like pinch-to-zoom. On an Android web view pinch-to-zoom works, but users can also zoom using the standard on-screen controls. Using multi-touch gestures on Android 2.1 requires a lot more work than on 2.2, so adding multi-touch gesture support to your app only when it is running on 2.2 or a newer Android version is possible. This way you still allow users with Android 2.1 devices to install your app but enable users with newer devices to fully enjoy their device capabilities.

Only when the user experience is unacceptable without a newer Android version should you raise the minimum supported version. You will have smaller target group of users but the ones who do use your app will be getting the most out of it.

Android app distribution

Some other mobile operating systems have become famous about their so-called walled garden approach to software installations, whereby any software must be installed only from official software distribution channels. Android is very different in this sense. Google doesn’t force any limitations to the operating system.

Some carriers have enforced stricter app installation policies by preventing app installation from sources they have not approved. Fortunately, this has happened only in very rare cases. In general users can install apps from different app stores or directly by downloading the app package (APK) from the Internet. Installing apps directly is called side loading. Side loading isn’t enabled by default, but any user can enable that function in the Android Security settings (see Figure 4-11).

Figure 4-11: To side load an app, users must first enable it from the Android settings.

Source: Android

The app stores

As already mentioned, there are multiple ways users can download apps to their devices. Besides side loading users have a choice of multiple app stores. The most prominent app store is the Google’s Play Store. By far the most Android devices ship from the Play Store, and many users are happy with it and don’t search for alternatives.

Another very popular app store is the Amazon Android App Store. Amazon’s entry to tablet market has sparked an interesting situation in the Android ecosystem. Although Amazon bundles its own app store with its own devices, it is also available with any other device.

In addition to these two big app stores, there are many smaller ones. Barnes & Noble has its own store that serves apps only to their own devices. GetJar is a popular multi-platform app store as well.

Application safety and approval processes

Different app stores have different approaches to app security. Google’s Play Store doesn’t require developers to put their apps through any kind of approval process to get their apps into the store. But that doesn’t mean that anything is allowed into the store. There are guidelines the developer must agree to before uploading the app. Apps breaking the guidelines are removed from the store and violating developers might end up losing their account. Google Play developer program policies can be found at http://www.android.com/us/developer-content-policy.html.

The lack of approval process has caused controversy and malware found from Google Store has been visible in news and blogs. To help to prevent malware getting into Google Play, Google has implemented an automatic virus scanning system called Bouncer, which scans all uploaded apps for known viruses.

Lack of an approval process does have positive implications to app quality on the market. Developers are free to upload patches to their apps without having to go through complex processes. Android apps generally receive small patches fairly regularly on Google’s Play Store and therefore detected bugs get squashed faster than on app stores that require approval processes.

Which app store to use

Selecting the app store to use is an important decision. Uploading your app to all app stores might sound like the obvious choice but could end up not being the best approach after all. There are so many apps on all the app stores nowadays that gaining visibility can be very difficult.

App store ranking algorithms are closely guarded secrets to prevent people from gaming the system. Some things that affect the app rankings are clear, though. One of them is the download number and the number of active users. Concentrating all downloads to a single store might be smart. If your app is available from multiple sources, the users are also spread between them. Instead of having 6,000 downloads in two stores, you have 12,000 downloads in one store, which might make the app much more visible in that store and cause an exponential trend in downloads.

Make users feel safe

Especially in Google Play, malicious imitation apps pop up all the time. Popular iOS app knockoffs that are not yet available on Android are used to lure unsuspecting users to install the app and then give their login credentials, personal information, or email addresses to the malicious app developer.

Incidents like those cause users to mistrust such app stores. Users are starting to understand that mobile app stores are very similar to the Internet, and not everything is always the way it seems. The users start to look for signs of legitimacy before installing an app. Make sure that all the marketing graphics you have provided to the App Store are high quality and correspond to your app’s general theme to create a more polished impression.

What can you do to make your users trust the app you upload? Although this isn’t much you can do that hasn’t been done by malicious app developers, one way to assure users is to provide a legitimate website. On Google Play, developers always must provide a link to their website. Make sure that the website you provide is the official site of your company. Also make sure that the website links back to your app on the market. Users have already learned how to recognize a trustworthy website and link between the site and the app will make the users feel safer. Never use a Google+ site or a Facebook page as your developer website.

What does open source mean?

Android is Open Source. But what does that mean to developers and designers? First, it is good to understand what Open Source software is and what it isn’t. This topic could fill multiple books, so I’ll try to simplify things here. Basically, Android consists of two distinct components. The core of the operating system is the Linux kernel. The kernel is built by a massive Open Source community and distributed under the General Public License (GPL). The GPL says that anyone can take the Linux code and redistribute it, modify it, and even sell it as long as any derived products are also distributed under GPL and the source code of the new product is distributed alongside any binary distributions. The second part of Android is the Android framework itself. This part is built by Google and distributed under the Apache license. The Apache license isn’t as strict as the GPL. It allows distribution of binaries without releasing source code.

Access to source code

Although Google doesn’t allow feature contributions to their code base directly, they do allow developers to download the full Android code base. You can see how Android internals work and, in some cases, even fix or tweak functionality you need on your applications. This approach should be left as the last resort, but sometimes it can save a feature that is too difficult to build otherwise. You can, for example, make a copy of Android’s Button class, change the internal functionality of it, and then use it to implement some or all of your buttons in your application.

Android community

Although the Android project is not a community-driven project, there are multiple community-driven library projects that support Android development. A search in GitHub reveals more than 15,000 repositories with the word Android. Not all of them are useful projects, but many of them are. Some libraries provide useful front-end functionality like pull-to-refresh or a back-ported Action Bar, some provide easy access to third-party systems like Facebook or Twitter, and others are helpful in other ways.

The best place to reach the Android developer and hacking community is the XDA Developers website and the related forums. The site has a massive registered community of people who are building apps, creating custom ROMs, unlocking and rooting phones, and much more. It is a very good and mostly reliable source for anything technical about Android.

The Android community isn’t just for coding. There are many forums dedicated to helping Android users with their problems of everyday use. Presence on some of the larger ones can be very helpful for promoting your apps.

Custom ROMs

Anyone can take the full Android stack, build it, and redistribute it. This has spawned multiple custom ROM projects. A custom ROM is a full replacement for the operating system that was shipped with the device. Installing (or flashing) a custom ROM to a device is the equivalent of reinstalling an operating system to a computer. Probably the best known ROM project is the CyanogenMod (www.cyanogenmod.com).

Although custom ROMs are not going to gain popularity with average Android users, they are a small but meaningful part of the Android ecosystem. Projects like CyanogenMod often bring newer Android versions to devices that are no longer supported by the manufacturers or enable users to remove manufacturer customizations from their devices.

Summary

The Android platform, with all its openness and flexibility, might feel overwhelming at first glance. The truth is that it is manageable. Understanding the limits and challenges early in the project planning will help you overcome them.

The same flexibility that creates challenges provides opportunities. In an open ecosystem the opportunities are limitless. If you don’t like something you can change it and so can your users.

Don’t be afraid of the Android fragmentation. It is manageable if tackled correctly. It is as much an opportunity as a challenge. Make sure you understand the platform before building apps for it. Otherwise, you might end up in a difficult place and might have to work much harder to reach the Android masses than you’d hope for.