Fatal Assumptions: Touch


The Fatal Assumptions blog post series will review some assumptions Android application developers may make, and why those assumptions may harm their app’s acceptance, immediately or in the near future.

Right now, every major Android device has a touchscreen. I say “major” because while there are a few netbooks without touchscreens, none have exactly caught fire in the marketplace.

Hence, right now, it seems safe for an Android developer to assume that all Android devices will have touchscreens. However, in the near future, that may be a fatal assumption…particularly if you don’t set up your manifest properly.

It is fairly likely that devices sans touchscreens will be hitting the market more substantially in 2010. Beyond the rumored Google TV running Android, there are other set-top box manufacturers at least experimenting with Android. It would not shock me to see some low-end smartphones being made without touchscreens, to cut the costs even further, particularly when aiming at markets that value simpler phones. Combine those with more netbooks and other new segments, and it’s reasonable to think that something running Android and without a touchscreen will be a significant player.

Ideally, your applications should not require a touchscreen, so they can be used on these newer devices. Standard Android widget-based UIs support navigation by D-pad or trackball — just test your app this way and confirm that it is indeed usable.

If you specifically need a touchscreen for your game or soundboard or whatever, that’s fine. However,  you really should consider adding one or two <uses-configuration> elements to your AndroidManifest.xml file, with android:reqTouchScreen attributes. This way, you can indicate that your app indeed needs a touchscreen (designed for fingers, styluses, or both). This should prevent your app from being installed on devices without a touchscreen, so those users will not get frustrated and leave you with poor ratings on the Market. You might even do this if you intend to support a touchscreen but do not have time to test it thoroughly at this time.


  1. Of course, there's already devices in the market without a physical trackball or D-pad so you can't count on anything _but_ a touch screen to be available either.

    For standard UI elements this is not a problem of course (they support various input methods), but if you need to do your own input then you probably should consider abstracting the input layer from the rest of the code so you can add support for more than one way to interact with your app.

    • Correct. And there are similar <uses-configuration> elements you should add if you absolutely need a pointing device.

  2. For certain markets, government users, including education there are issues with ADA compliance of touchscreen only interfaces. It is a good idea to have a backup mouse, other pointer based and key stoke access method to comply with ADA and 508 requirements.

  3. Android set-top boxes & tv would have a remote control of some sort with dpad/trackball/buttons/motion sensors/touch screen etc and perhaps some notion of a pointer on the tv display. The Android framework could also present this mixed information to applications through the touch screen interface. I also think it is likely you'll be able to use the touch screen on your Android phone/pad/tablet to control Android set-top boxes & tv, at any distance.

  4. My advice to aspiring Android developers is to select a popular Android phone – and at the time of this writing that would be Droid – and make sure your application works well and looks great on that particular phone. If you get wind in your sail you can deal with all kinds of pesky issues on other devices later. You didn't think you'd release a single version of your app and declare a victory, did you?

    Having said that, you are better off if you follow Android application best practices and guidelines that can be found athttp://developer.android.com.

    In addition to that there's a particular case when you might want to do some advanced planning and that is if your app interacts with the phone hardware such as camera, accelerometer, or GPS. Android phones built by different manufacturers have peculiarities when it comes to the hardware and Android is not perfect in this area either. If you can, test on different phones before going to the market. Otherwise, collect early user feedback and resolve all the reported issues before the big day.

    Kind regards,
    Borys Burnayev
    GTD for Android and Web