Chapter 4

Determining the Appropriate SDK for Your Application

The great thing about versions is that there are so many to choose from.

Paraphrased from — Unknown

The Android Software Development Kit (SDK) is a moving target. The engineers at Google continually tweak and improve the SDK by adding new features and pushing others aside. While these new versions become available on newly purchased phones (and tablets), existing devices might not be updated to the most recent version. As a result, you have to consider a wide variety of SDKs when developing an application.

Every version of the Android SDK has been named after a dessert, in alphabetical order: Cupcake, Donut, Eclair, Froyo (short for frozen yogurt), and Gingerbread. For every release, Google marks the occasion by placing a giant sculpture of the corresponding dessert on its Googleplex campus in Mountain View, California. As of February 2011, the latest major version of the SDK, version 3.0, is codenamed Honeycomb. This has been quickly followed by two incremental releases — version 3.1 and, in July 2011, version 3.2. The next major release is expected to be Android 4.0 (also known as Ice Cream Sandwich).

Along with the cool marketing name (Honeycomb, Ice Cream Sandwich, and so on) and the version, each SDK release is numbered with an always-increasing Application Programming Interface (API) level. Thus, Android SDK version 1.5 was API level 3, and the latest version 3.2 is API level 13.

Note that not all possible SDK versions and API levels are assigned to SDKs — or if they are, some versions are not released to external developers (those outside Google). For example, there was a version 2.3.1 and a version 2.3.3, but no Android SDK version 2.3.2 was ever released.

In this chapter, you discover what the most important differences are between the major versions of the Android SDK and how to select the right version for targeting your application.

Exploring the Variety of Android Devices and SDKs

Android is available on a wide variety of devices. These devices have different characteristics such as screen size and screen resolution, and they can also have different versions of the Android SDK installed. The various combinations of devices and SDK versions can be a boon for consumers and a headache for application developers.

Understanding display characteristics

Screens on Android devices can be categorized into one of four general display sizes: small, normal, large, and extra large. They can also be categorized into a set of four generalized densities: low density, medium density, high-density, and extra-high-density. As of June 2011 (see Figure 4-1 and refer to www.androidontop.com/2011/06/22/android-screen-sizes-and-densities-distribution-until-june-1/), roughly three-quarters of the Android devices were of normal size with high-density displays (240 dots per inch). Relatively few devices have extra-high-density displays (320 dots per inch) although you can expect this number to increase. Similarly, relatively few devices used to have extra large displays (7 inches or more). With the advent of tablets, however, you can now expect this number to increase soon as well.

Figure 4-1: Distribution of Android screen sizes.

The reason to avoid pixels as units of measurement is that the size of a measurement such as 80 pixels depends on the resolution of the screen. For example, on a medium-density display with a resolution of 160 dots per inch, every pixel is 1/160 of an inch. An 80-pixel width, then, appears on the display as about half an inch, or roughly the width of your fingertip. However, on an extra-high-density display with a resolution of 320 dots per inch, the same 80-pixel width appears as only a quarter-inch, or roughly the width of a standard pencil. If the button size is specified in pixels, your application may look fine at one resolution but be annoyingly difficult to use at higher resolutions.

A better measurement unit to use is the density independent pixel, or dp. It's the same physical size — about 1/160 of an inch — regardless of the resolution density of the display. In other words, for a medium-density display (160 dots per inch), a dp is equal to exactly 1 pixel. On the other hand, for an extra-high-density display (320 dots per inch), a dp is equal to 2 pixels. When you work with positions and sizes in terms of dps, your user interface will have the same physical feature size on all displays.

The Tic-Tac-Toe example (which we tell you how to install in Chapter 3) is an example of a resolution-independent application. If you examine the Board class, you see two private fields: width and height. Both fields are in pixels, but they're calculated dynamically in the onDraw(…) method based on the size of Canvas. This approach guarantees that the Tic-Tac-Toe board fills the entire Canvas, regardless of the size or resolution of the display.

Recognizing there's more than one version of the SDK

Android devices not only have different hardware configurations, such as screen size and resolution, but can also have different software configurations. That is, several different versions of the Android SDK itself exist. Since the initial release of the Android SDK, it has undergone many revisions. On one hand, this quick evolution indicates the level of excitement and development effort behind Android. On the other hand, the speedy evolution means that many devices now in use don't have the latest version installed. Application developers must deal with this diversity.

Google tracks the distribution of platforms as observed by accesses to the Android Market. A recent snapshot is posted at http://developer.android.com/resources/dashboard/platform-versions.html and shown in Figure 4-2 below.

Figure 4-2: Distribution of Android versions.

For example, in July 2011, about 60 percent of Android devices accessing the Android Market were running SDK version 2.2 while 18 percent were still running the previous version, 2.1. Versions of SDK version 2.3 (including maintenance releases) made up 19 percent of the devices. Devices with the latest Android version (3.0) were slowly coming into use. Conversely, about 4 percent of devices were still using the even older SDK version 1.5, which had been superseded a full two years earlier!

Why should you care about all these different versions and API levels? As an application developer, you decide the minimum API level suitable for your application to run (and set it in the AndroidManifest.xml file — see the section below). This API level is used by the standard app downloaders (such as the Android Market application) to decide whether your app should be allowed to be purchased and installed on a user's machine. Pick too low of a number and you have to test more thoroughly, and perhaps limit the features you can offer. Pick too high of a number and you limit your market. Incidentally, Eclipse also looks at the minimum API level to decide whether an app can be downloaded onto an active emulator or device.

The API level identifier (see Table 4-1) can be used to mark the minimum level needed for an application to run. This identifier may also be used to indicate two of the additional SDK levels: the preferred level and the maximum level of the SDK in your application properties. Once again, you set minimum, maximum, and target API levels in the AndroidManifest.xml file; an example is shown below:

<uses-sdk>
    android:minSdkVersion=“6”
    android:targetSdkVersion=“11”
    android:maxSdkVersion=“11”
/>

Table 4-1 API Levels for Major SDK Releases

Examining the Differences between SDK Versions

Every major SDK release has generally added, rather than removed, features and supported devices. Thus, an application built on an earlier release is forward compatible with a later release. For example, an app developed for Android 2.1 also runs on Android 2.3.

The following sections describe the features that were added in each release.

The earliest Android release documented by Google is Android 1.1. Both 1.0 and 1.1 well-supported the Android Application Model (see Chapters 1 and 3) in that they both had the capability to support Activities, Services, Menus, and so on. In other words, the foundation for all the stuff that you see in this book was in place with Android 1.0. Android 1.1 fixed quite a few bugs, added Locale support (so that Android could handle multiple languages), and added the first set of built-in applications (beyond the telephone dialer). Most importantly, 1.1 added support for external libraries. This meant that starting with this version, Google Map functionality was supported.

Android 1.5 — Cupcake

Cupcake released new features in these categories:

• Communications: Support for stereo audio streaming (A2DP) and remote control of Bluetooth-enabled media devices (AVRCP); automatic connection to Bluetooth headsets within range
• Data entry: A new soft keyboard with text completion
• Multimedia: The ability to record and watch videos in Camcorder mode and upload videos to YouTube and pictures to Picasa from the phone
• User interface: New widgets and folders that can populate the Home screens; animated screen transitions

Complete details on Cupcake are here: http://developer.android.com/sdk/android-1.5.html.

Android 1.6 — Donut

Released on September 15, 2009, Donut included an improved Android Market experience and improvements in these categories:

• Accessibility: A text-to-speech engine (which we're experimenting with in order to build apps for folks with visual impairments)
• Applications: Free turn-by-turn navigation from Google
• Communications: Updated support for the CDMA/EVDO and 802.11x Wi-Fi standards, and virtual private networks (VPNs)
• Multimedia: An integrated camera, camcorder, and gallery interface; better performance for camera applications
• Search: Updated voice search; better speed and integration with native applications, including the ability to dial contacts and search bookmarks, history, contacts, and the web from the Home screen
• User interface: Support for WVGA screen resolutions, the gesture framework, and the GestureBuilder development tool

Complete details on Donut are here: http://developer.android.com/sdk/android-1.6.html.

Android 2.0 — Eclair

Released on October 26, 2009, Eclair included these improvements:

• Applications: New contact lists; Microsoft Exchange support, searchable SMS messages
• Communications: Bluetooth 2.1 with new Bluetooth profiles
• Data entry: Improved virtual keyboard
• Mapping: Improved Google Maps 3.1.2
• Multimedia: Built-in flash support, digital zoom, and other enhancements for the Camera app
• System and performance: Optimized hardware speed
• User interface: Support for more screen sizes and resolutions; new browser user interface and HTML5 support; better contrast ratio for backgrounds; MotionEvent class enhanced to track multitouch events; live (animated, interactive) wallpapers

Note:The 2.0.1 SDK was released on December 3, 2009, and the 2.1 SDK was released on January 12, 2010. These maintenance releases had bug fixes but no additional features.

Details on the 2.0 version of the SDK are here: http://developer.android.com/sdk/android-2.0.html.

Android 2.2 — Froyo

Released on May 20, 2010, Froyo (frozen yogurt) included these features:

• Applications: Better Microsoft Exchange support (autodiscovery, calendar synchronization, global address list look-up, remote wipe, security policies,); updated Market application with batch and automatic update features; support for file upload fields in the built-in browser, which can now also display animated GIFs (rather than just the first frame)
• Communications: USB tethering and Wi-Fi hotspot functionality; the option to disable data access over a mobile network (to prevent unexpected data charges); voice dialing and contact sharing over Bluetooth
• Data entry: Quick switching between multiple keyboard languages and their dictionaries; support for numeric and alphanumeric passwords
• System and performance: General Android operating system speed, memory, and performance optimizations; application speed improvements in the Dalvik VM from the use of just-in-time (JIT) compilation; support for installing applications to the expandable memory
• User interface: Integration of the Chrome V8 JavaScript engine into the Browser application; improved application launcher with shortcuts to the Phone and Browser applications; Adobe Flash 10.1 support in the browser

Details on the 2.2 version of the SDK are here: http://developer.android.com/sdk/android-2.2.html.

Android 2.3 — Gingerbread

On December 7, 2010, Gingerbread (2.3.3 is the generally available) was released with these new features:

• Applications: Improved social networking features
• Application development: Faster, concurrent garbage collection and faster event distribution, making possible the development of higher-performing applications (such as for gaming); the ability of native code (applications in C and C++) to directly gain access to sensor inputs; a new Activity subclass, NativeActivity, allowing life cycle callbacks to be implemented in native code
• Communications: Internet calling; near-field communications (NFC) capability (which allows the device to act as an RFID-like reader, for example)
• Multimedia: Support for the VP8 open video-compression format and the WebM open container format; AAC encoding and AMR wideband encoding (in software) so that applications can capture higher-quality audio than narrowband; access to multiple cameras and mixable audio effects
• User interface: Improved copy-and-paste functionality

Details on Gingerbread are here: http://developer.android.com/sdk/android-2.3.3.html. Note that documentation for the base 2.3 version is no longer on Google's site.

Android 3.0 — Honeycomb

On February 22, 2011, the Android 3.0 (Honeycomb) SDK was released. The changes in this release of Android included

• Applications: Support for video chat using Google Talk
• Application development: Enhanced input device and USB support (in 3.1), API for interacting with connected cameras (in 3.1)
• Communications: Background Wi-Fi networking
• System and performance: Refined multitasking, hardware acceleration, and support for multicore processors
• User interface: Optimized tablet support with a new fragments-based user interface; an Action Bar that can be used to enhance the previously available Menu functionality; a 3D desktop with redesigned widgets with new themes; system clipboards and drag-and-drop; enhanced App Widgets; animation of UI components (in 3.0 and enhanced in 3.1); compatibility zoom for fixed-size apps (in 3.2), that is, apps written for smaller devices

We are underselling 3.0 and its incremental releases 3.3 and 3.4 with the bland descriptions above. 3.0 was a major release that has essentially revamped the Android SDK, in particular, the way user-interfaces can be built for Android by decoupling the UI from the activity, and giving each its own separable life cycle.

And beyond

The next major version of the Android SDK (expected in the third quarter of 2011) will continue the push towards a single, unified platform for both phones and tablets. At the time this book was published, the name of this new SDK had not been officially announced. To no one's surprise, Google has hinted that the new version “will start with an I, and be named for a dessert.” Whether the next version ends up being named Ice Cream, or perhaps Ice Cream Sandwich, it's likely to be delicious!

Dealing with API Levels

Given this information, what should be your general strategy? We recommend choosing the minimum-level API that your application needs. The conventional wisdom is that a balance exists: Pick the smallest version number to reach the highest number of devices, but pick the largest number to minimize the amount of testing. We'll go out on a limb and add that because Android adoption is deep into the growth phase, don't worry about sinking below SDK version 2.1 (API Level 7) — there's enough of a market to sell to. (Ninety percent or more of the current market is at version 2.1 or later. Google maintains a current snapshot of devices accessing the Android Market; see http://developer.android.com/resources/dashboard/platform-versions.html.)

The above guidelines apply, of course, when you first develop your app. How do you deal with the fact that, over time, the Android SDK will evolve, with new features being added and old capabilities being improved? To begin with, most apps will be forwardly compatible (that is, an app built for an earlier version of Android will mostly work just fine on a later version). That is, though applications designed on previous SDK versions won't take advantage of all the features added to future SDK versions, they should work mostly as well as they did on older SDK versions. However, don't rely completely on this compatibility. As each version comes out into the market, test your application against it, if only to make sure that all the features at least superficially work. In particular, make sure that the user interface is usable because as new versions come out on new devices, there are likely to be changes in the way the API handles the new display sizes and new resolutions.

You will also have to worry about “deprecated” elements of the API. Most changes in the SDK from one version to the next involve additions. For example, new classes are added to control new types of phone sensors, or a range of possible values is extended to account for more types of phones. Occasionally, however, a method or class is marked as deprecated (for more on deprecation, see http://download.oracle.com/javase/1.5.0/docs/guide/javadoc/deprecation/deprecation.html).

So what do you do about deprecated methods or classes? To begin with, don't use deprecated functionality when you are developing a new application. After your app has been released, if the method or class becomes deprecated, and your app doesn't work quite right because of its reliance on the deprecated API, you simply have to redo and re-release your app. The good news is that the SDK is, by and large, backward compatible, and newer SDK versions should still be able to run all applications that worked on previous versions, so you won't have to do this redoing very often.

Finally, you also have to deal with backward compatibility. That is, you will most likely target a version to develop against that is higher than the minimum version you want the software to support. This is because, even though you are supporting a minimum version, your goal is not to develop for that version (and simply let the forward compatibility of the Android SDK take care of the app working properly on the later versions you are targeting). Rather, you want to target a version in-between the minimum and the latest version where you have the best tradeoff between backward compatibility and features you can exploit in the API to make your application really cool. We won't go into techniques for ensuring backward compatibility here, because these techniques are not Android specific (but just plain old Java techniques — such as using the “factory” pattern). If you e-mail us, though, we'll be happy to give you some pointers.