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.
As with the other chapters, we have not tried to simply re-hash everything from the Google Android site here. For all the gory details, see http://developer.android.com/sdk/index.html.
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.
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.
Avoid using pixels to specify positions and dimensions. For the most part, Android does the heavy lifting of making your application run on any of these platforms and display on any of these screen sizes and resolutions, but you can still benefit from following this important piece of advice.
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.
In addition to dp, other abbreviations for density independent pixel are sometimes used by Android developers and in the Android SDK documentation. In particular, you might see dip or DIP. Rest assured that they all mean the same thing. But just to confuse matters, dpi refers to a completely different concept: dots per inch.
Unfortunately, many methods in the SDK use the pixel as the unit of measurement. When calling these methods (or using their return values), you need to convert between dps and pixels. The android.util.DisplayMetrics.density field contains the scale factor needed for this conversion. For example, on an extra-high-density display, this field has the value 2.
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.
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.
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” />
Notice the gap between API levels 5 and 7. API level 6 had no major release — instead, an intermediate release, 2.0.1, was assigned level 6. (We don't list API levels earlier than 1.5 because there's no need.)
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.
Cupcake released new features in these categories:
Complete details on Cupcake are here: http://developer.android.com/sdk/android-1.5.html.
Released on September 15, 2009, Donut included an improved Android Market experience and improvements in these categories:
Complete details on Donut are here: http://developer.android.com/sdk/android-1.6.html.
Released on October 26, 2009, Eclair included these improvements:
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.
Released on May 20, 2010, Froyo (frozen yogurt) included these features:
Details on the 2.2 version of the SDK are here: http://developer.android.com/sdk/android-2.2.html.
On December 7, 2010, Gingerbread (2.3.3 is the generally available) was released with these new features:
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.
On February 22, 2011, the Android 3.0 (Honeycomb) SDK was released. The changes in this release of Android included
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.
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!
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.)
Never assume that a device has the current SDK installed. In fact, if you want the broadest possible reach, you should assume the opposite.
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).
Though a deprecated method or class is still present, it may disappear in future releases.
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.
18.117.187.113