Part VIII

The Ever-Evolving Android

Chapter 48

Dealing with Devices

Android is open source and made available freely for device manufacturers. 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 can choose among Android devices in a variety of shapes, sizes, and colors. This also means developers 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 earlier chapters.

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, though, hundreds of other devices exist, many with different hardware capabilities (e.g., no keyboard, multiple screens, game controller buttons, and more!).

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 that tell Android what you need, so that your application is not installed on devices lacking such hardware. We'll look at that now, and then move on to implied feature requests.

Explicit Feature Requests

In addition to using the target ID system to indicate the level of device your project is targeting, you can use an 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 that your application will work with. 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 whether 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>, that is designed to document requirements an application has for other optional features on Android devices. For example, 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., 0×00010002 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

Each Android release adds more features that you can require. A great example is the recently added android:hardware:nfc feature, for using near-field communication (NFC). These requests will cause the Android Market—and other, third-party markets, one hopes—to filter your application out from being loaded on devices for which it is unsuitable.

The <uses-feature> element has an android:required attribute that you can specify. By default, it is set to true, meaning your application absolutely needs this feature. If you set it to false, you are advertising that your application can take advantage of the feature if it exists, but does not absolutely need it. To find out at runtime whether the feature exists on the device, you can use the hasSystemFeature() method on PackageManager to interrogate the device.

Implied Feature Requests

If you have requested permissions like CALL_PHONE or SEND_SMS, unless you take the proper steps, your application will not be available for the Motorola XOOM, nor presumably for other Wi-Fi-only Android tablets.

Some permissions imply that you need certain hardware features. Scroll down to the “Permissions that Imply Feature Requirements” section on the <uses-feature> page to find the list.¹

The Android Market treats a request for a permission like CALL_PHONE as though it is also a request for the following:

The XOOM was the first Android device to lack telephony; several other devices have followed in its footsteps. While the XOOM can have a data plan, it has no voice or SMS capability, so it is treated as not having android.hardware.telephony. But, if you request permissions like CALL_PHONE, the Android Market by default will assume you need android.hardware.telephony. As a result, you will be filtered out of the Android Market for the XOOM.

The solution is simple: for any hardware features that might be implied by permissions but that your application does not absolutely need, manually add the appropriate <uses-feature> element to your manifest with android:required="false":

Then, before you try placing a phone call or sending an SMS or something, use PackageManager and getSystemAvailableFeatures() to find out if android.hardware.telephony is available on the device. For example, you might check for telephony early on and disable various menu choices, such as buttons that might lead the user to place a call or send an SMS.

If your application absolutely needs telephony, then the implied <uses-feature> will work, though you may wish to consider putting one in explicitly. However, just bear in mind that this means your app will not work on the XOOM or other tablets that lack telephony.

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.

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. Specifically, any device that has the Android Market

• Meets the criteria outlined in the Compatibility Definition Document (CDD)
• Has passed the Compatibility Test Suite (CTS)

Other Stuff That Varies

Other things that vary from device to device include the following:

• Which location technologies are available (e.g., GPS, cell tower proximity, Galileo)
• Which camera features are available (e.g., flash, autofocus, sepia tone)
• Which sensors are available (e.g., accelerometer, gyroscope, barometer)

The strategy for dealing with these variables is to interrogate the system first to find out what the possibilities are, and then decide which to use, where the decision could be made solely by you or with user input. For example, you can use Criteria to determine which is the best location provider to use with LocationManager.

Bugs, Bugs, Bugs

Unfortunately, devices inevitably have bugs. Some bugs are truly accidental. Some are side effects from changes the device manufacturer made to achieve some business aims. Some are actually intentional, though the engineers who implemented them may not have fully understood their ramifications.

There is not much you can do tactically about these bugs, beyond try to work around them. The Build class, in the android.os package, can tell you the make and model of the device that is running your app. That, plus your own hard-won experience with certain problems, will help you identify where you need to route around firmware damage.

Strategically, if you find something that is clearly a device bug, you should file an issue to have this bug detected via the CTS. The CTS is supposed to filter out devices that cannot faithfully run Android applications. However, the CTS has many holes, and device bugs slip through. By collectively improving the CTS, we can help prevent problems from cropping up in the future. You can file an issue at the Public Issue Tracker for Android Bugs, http://code.google.com/p/androidbugs/issues/list.

Device Testing

Ideally, you should try to test your apps on a variety of hardware. However, this can get expensive. Here are some options for doing it more cheaply:

• Sign up for Keynote DeviceAnywhere's independent developer plan, which is a lower-cost way of being able to access their device farm for remote testing.
• Some device manufacturers hold device labs at various events, such as Motorola held at AnDevCon 2011.
• Some carriers have perpetual device labs, such as Orange's developer centres.
• You may be able to arrange short-term (e.g., 15-minute) device swaps as part of a Meetup or Google Technology User Group with fellow Android developers.