Chapter 37

Dealing with Devices

Android is “free as in beer” for device manufacturers, as it is an open source project. Hence, device manufacturers have carte blanche to do what they want with Android as they put it on their devices. This means a breadth of choices for device users, who will be able to have Android devices in all shapes, sizes, and colors. This also means developers will have some device differences and idiosyncrasies to take into account.

This chapter will give you some tips and advice for dealing with these device-specific issues, to go along with the screen size material in Chapter 36.

This App Contains Explicit Instructions

Originally, the only Android device was the T-Mobile G1. Hence, if you were writing an Android application, you could assume the existence of a hardware QWERTY keyboard, a trackball for navigation, and so on. Now, other devices (e.g., HTC Magic) exist with different hardware capabilities (e.g., no keyboard).

Ideally, your application can work regardless of the existence of various types of hardware. Some applications, though, will be unusable without certain hardware characteristics. For example, a full-screen game may rely on a hardware keyboard or trackball to indicate player actions—soft keyboards and touchscreens may be insufficient.

Fortunately, starting with Android 1.5, you can add explicit instructions telling Android what you need, so your application is not installed on devices lacking such hardware.

In addition to using the target ID system to indicate the level of device that your project is targeting, you can use a new AndroidManifest.xml element to specify hardware that is required for your application to run properly. You can add one or more <uses-configuration> elements inside the <manifest> element. Each <uses-configuration> element specifies one valid configuration of hardware with which your application will work. At the present time, there are five possible hardware requirements you can specify this way:

• android:reqFiveWayNav: Indicates you need a five-way navigation pointing device of some form (e.g., android:reqFiveWayNav = "true").
• android:reqNavigation: Restricts the five-way navigation pointing device to a specific type (e.g., android:reqNavigation = "trackball").
• android:reqHardKeyboard: Specifies if a hardware (physical) keyboard is required (e.g., android:reqHardKeyboard = "true").
• android:reqKeyboardType: Used in conjunction with android:reqHardKeyboard, indicates a specific type of hardware keyboard is required (e.g., android:reqKeyboardType = "qwerty").
• android:reqTouchScreen: Indicates what type of touchscreen is required, if any (e.g., android:reqTouchScreen = "finger").

Starting in Android 1.6, there is a similar manifest element, <uses-feature>, which is designed to document requirements an application has for other optional features on Android devices. Specifically, the following attributes can be placed in a <uses-feature> element:

• android:glEsVersion: Indicates that your application requires OpenGL, where the value of the attribute indicates the level of OpenGL support (e.g., 0x00010002 for OpenGL 1.2 or higher).
• android:name = "android.hardware.camera": Indicates that your application needs a camera.
• android:name = "android.hardware.camera.autofocus": Indicates that your application specifically needs an autofocus camera.

Button, Button, Who's Got the Button?

There are few, if any, requirements on device manufacturers as to what buttons are available as physical buttons, versus on-screen soft keys, versus simply not being available on a given Android device.

For example, the HTC Dream (a.k.a., T-Mobile G1) has call, end call, home, back, menu, and camera buttons, along with a volume control and a dedicated search button on its QWERTY keyboard. The HTC Magic (a.k.a., T-Mobile myTouch 3G) lacks the camera button, putting the search button in its place. The Archos 5 Android Internet Tablet has no hardware buttons at all beyond the volume control, with soft keys for home, back, and menu.

Therefore, you should be careful about assuming the existence or placement of hardware buttons. Provide alternative means of performing operations that you tie to buttons. For example, if you override the volume control to serve as page-up/page-down keys, make sure there is some other way for the user to move between pages.

A Guaranteed Market

As mentioned in the introduction to the chapter, Android is open source. Specifically, it is mostly available under the Apache Software License 2.0. This license places few restrictions on device manufacturers. Therefore, it is very possible for a device manufacturer to create a device that, frankly, does not run Android very well. It might work fine for standard applications shipped on the device but do a poor job of handling third-party applications, like the ones you might write.

To help address this, Google has some applications, such as the Android Market, that it has not released as open source. While these applications are available to device manufacturers, the devices that run the Android Market are tested first, to help ensure that a user’s experience with the device will be reasonable.

A Google engineer cited one case where a device manufacturer was readying a phone that had a QVGA screen, before the release of Android 1.6 where QVGA support was officially added to the platform. While that manufacturer had arranged for the built-in applications to work acceptably on the smaller-resolution screen, third-party applications were a mess. Google apparently declined to provide the Android Market to the manufacturer for this device.

Hence, the existence of the Android Market on a device, beyond providing a distribution means for your applications, also serves as a bit of a seal of approval that the device should support well-written third-party applications.

The Down and Dirty Details

Unfortunately, the Android Market does not guarantee problem-free deployment on Market-enabled devices, nor does it prevent manufacturers from shipping Android devices without going through the Market. Inevitably, devices will have some quirks or idiosyncrasies that might have a negative impact on your applications. The following is a selection of some Android devices, in the order of their public availability, and ways that they differ from more standard devices.

Archos 5 Android Internet Tablet

The Archos 5 Android Internet Tablet is the first mainstream device to be based purely on the Android open source project. Unlike the phones from HTC, Motorola, and others, the Archos 5 is not a Google Experience device and does not have the Android Market, Google Maps, or other proprietary Google applications.

The Archos 5 is a WVGA device, but shipped with Android 1.5. Hence, an original Archos 5 will not honor the new -large resource set designation as documented in Chapter 36. Given that this device is not selling in major quantities, you may wind up with it simply having an unoptimized UI until the Archos 5 has Android 1.6 support.

The Archos 5’s touchscreen is resistive, not capacitive. This means users will be using fingernails or styli to manipulate the screen, more so than fingertips. Bear this in mind when designing finger-friendly UIs.

The Archos 5, as of firmware 1.1.01, returned a somewhat invalid value for ANDROID_ID (a unique ID assigned to each Android device). ANDROID_ID is null in the emulator and is supposed to be a hex string in devices. On the Archos 5, ANRDROID_ID is a non-null but non-hex string. If all you care about is null versus non-null, then the Archos 5 is fine; if you need a hex value for ANDROID_ID, you will experience some problems.

Since the Archos 5 is not a phone, all telephony-related features, such as dialing via ACTION_DIAL, are unavailable. Similarly, since the Archos 5 lacks a camera, all camera-related features are unavailable. As noted earlier, the Archos 5 lacks Google Maps, the Android Market, and other proprietary Google applications.

Also, the Archos IMEI value is fake, since it is not a phone.

Motorola CLIQ/DEXT

The Motorola CLIQ (or DEXT, as it is known outside the United States) is an HVGA device, originally shipping with Android 1.5.

The CLIQ has a D-pad for non-touchscreen navigation. However, the D-pad is on a side-slider QWERTY keyboard, and as such, the D-pad is not available to users when the device is in portrait mode, unless you force portrait mode for your activity via the manifest and force users to use their CLIQ with the keyboard slid out. Do not write applications that assume the D-pad is always available.

The CLIQ also ships with MOTOBLUR, Motorola’s social media presentation layer. This means that the home application, contacts, and select other features that Android normally ships with have been replaced by MOTOBLUR-specific features. This should not cause too many problems if you stick to the SDK. The one area that does get a bit interesting is that not all MOTOBLUR contacts will be available to you via the Android Contacts content provider. For example, Facebook contacts are available to MOTOBLUR, but not to third-party applications, perhaps for licensing reasons. This situation may change when the CLIQ is updated to the new ContactsContract system with Android 2.0.1 and beyond.

Motorola DROID/Milestone

The Motorola DROID (or Milestone, as it is known outside the United States) is a WVGA854 device, originally shipping with Android 2.0, though most of these devices will now be running Android 2.0.1.

The DROID, like the CLIQ, has a D-pad on the side-slider keyboard, meaning the D-pad is not readily available to users when the device is in portrait mode.

Because the DROID has a WVGA854 screen on a normal phone-sized device, Android will consider the DROID to have a high-density screen, so -hdpi resource sets will be used.

Google/HTC Nexus One

The Nexus One—built by HTC and sold by Google—is a WVGA800 device, originally shipping with Android 2.1.

Like the DROID, the Nexus One will be a high-density (-hdpi) device.

Motorola BACKFLIP

The Motorola BACKFLIP has yet another take on pointing devices. Rather than a trackball or a D-pad, the BACKFLIP has two non-touchscreen navigation options:

• The QWERTY keyboard has PC-style arrow keys, which should generate standard DPAD key events.
• The BACKFLIP touchpad on the reverse side of the touchscreen will generate trackball events (or DPAD key events, if the trackball events are not consumed).