Some Devices Just Can't Handle Android Apps

by Tim Kridel

Android App Development: Some Devices Just Can't Handle It

Outdated and sub-$100 Android smartphones and tablets can create challenges for developers and users. With so many of these devices on the market, though, Android app developers need to minimize that risk.

It's not hard to find an Android smartphone or Android tablet for under $100. That's great for Android app developers because the more affordable those devices are, the bigger the pool of potential customers will be.

But there's a potential catch -- "potential" only because just how much of a catch depends on whom you ask. If the Android device's price reflects a slow processor, limited memory or an old version of Android, then it may struggle to deliver a good user experience with certain apps.

One example is Temple Run, whose Android debut incurred complaints from users whose smartphones didn't have the hardware necessary to support the game. (Temple Run's developer, Imangi Studios, declined an interview request due to time constraints.) Those kinds of Android app development problems illustrate how affordable devices don't necessarily translate into a big pool of potential customers -- or at least happy customers.

Developers face a similar challenge with Android smartphones aimed at the middle or higher end of the market. A smartphone priced at $199 with a two-year data plan at $80/month isn't exactly aimed at bargain shoppers. But mobile operators and handset vendors often don't provide more than one or two major operating system upgrades -- such as from Froyo to Gingerbread -- during a smartphone's shelf life. So if an app works best on the latest version of Android, its addressable market shrinks to smartphones that are only a year or two old. Additionally, there are also big disparities in how quickly a handset vendor or mobile operator pushes out the latest version of Android -- seven months, in some cases.

How big a problem are outdated or underpowered devices? The definitive answer is, it depends. "This will depend on how resource-intensive the app is," says Derek Ting, Enflick co-founder. "Games or other resource-intensive apps will typically be more likely to see these issues. Our app, Touch, runs on cheap, underpowered Android phones, but it doesn't run as smoothly. However, the user experience is still acceptable."

Android App Development: Going Back to the Future

Some developers avoid the potential problems with outdated or underpowered devices by testing their apps on the very first Android smartphone: the G1, which went on sale in October 2008.

"I test on the G1 for a couple of reasons," says Sterling Udell, whose apps include TerraTime and PolyClock. "Obviously, if I'm advertising that a given app works on Donut, I need to verify that's actually true. But it's also a minimum-spec example device, sort of a ‘worst-case scenario' device. I also try not to over-emphasize the worst-case scenario. As long as an app works passably well on low-spec hardware, I don't spend too much time trying to make it run as fast as it does on my Galaxy Nexus. I figure that most people who own low-end hardware know it, and don't expect miracles. Everything runs slowly on a low-spec device, not just my apps."

Even the largest app developers don't have the resources to test their apps on every single Android device ever made, let alone the most widely used models. So there's always a chance that testing on the G1 will leave out some other hardware-OS-software configuration that could result in a bad app experience.

"But over the three years I've been doing this, I've accumulated a small stable of devices that I think offer a fairly representative sample," Udell says. "We test every release on all of them before it goes out. Several of these devices are decidedly low-end: Archos 70, Momo Bird 8. It's not just the G1. It's a question of balancing the risk against the time to do all that testing, and the importance of small edge cases (is problem X going to affect enough people to justify spending the time needed to fix it?)."

Other developers see the challenge of "least-cost handsets" (LCH) potentially disappearing if the smarts in today's smartphones move to the cloud tomorrow.

"I foresee an opportunity for running Android apps in the cloud, [specifically a] thin client model, where the user of the LCH sees and interacts with the app as normal, but where the processing power and memory is in the cloud," says Terry Hughes, who developed apps such as momentem before becoming managing director of AppCarousel. "Then it doesn't matter whether the LCH is out of memory or trying to run too many apps; all that is dealt with in the cloud."

Android App Development: What's in Store

Stores such as Google Play help developers reduce the chances that their app will wind up on a smartphone or tablet that can't handle it.

"Before the initial submission of the app or any subsequent update, the developer can specify which OS versions the app can support via the SDK," Ting says. "Play (and other app stores) will take care of the rest."

Other developers agree that Play is pretty effective. "Google Play already provides a quite extensive device filtering system, and on top of that it allows you to exclude specific device models if they are problematic," says Chris Pruett, chief taskmaster at Robot Invader.

"For example, Wind-up Knight requires OpenGL ES 2.0 and EGL format texture support. Those are widely supported by Nexus One-and-up class devices, but were not available on lower-end machines. This effectively makes the Nexus One our minimum spec," Pruett says. "Google Play doesn't allow a device that doesn't meet our specified requirements to install our game. There are similar controls for number of touch points, details regarding accelerometer and gyroscope, minimum Android OS version, etc. It's actually quite a lot of control."

Some developers who distribute through Amazon's Appstore say they're not sure how that store handles filtering. "When listing an app, you can specify whether it's for phones, tablets or both, but I really don't know what other filtering they do," Udell says. "On the other hand, I can't recall ever having a compatibility support issue from an Amazon sale, which would imply that they do manifest-based filtering as well. I do know that they specifically test apps for Kindle Fire compatibility before release.

"Most other app stores that I've dealt with either auto-detect compatibility data from the manifest, or have manual compatibility options when listing and app for sale. These usually are limited to Android version and screen size, rarely anything else. I have no reason to believe that any store doesn't honor what compatibility items they do ask for."

If developers are concerned that old or underpowered devices won't deliver a good experience with their app, should they consider putting minimum spec requirements in their app store descriptions? There's no definitive answer here, either. One risk is confusion because the average user might not know which version of Android they have.

"If an app requires something unusual -- especially something that manifest-based filtering doesn't cover -- then yes, I'd think developers should mention that quite prominently in the app description," Udell says. "But not general device requirements, like Android version or screen size. I'd have much more confidence in the store filtering on these things

Software Development - Android App Development: Some Devices Just Can't Handle It

Some Devices Just Can't Handle Android Apps

Android App Development: Going Back to the Future

Android App Development: What's in Store

Software Development - Android App Development: Some Devices Just Can't Handle It

Technology