How to find out whether multi-touch is supported on Android…

Edit: wall of text sorry.
Correction: Android devices are indeed required to have a touch screen per CDD
Update: finished reading the 2.2 CDD. Section 8.5 Touchscreen input: “SHOULD support fully independently tracked points, if the touchscreen supports multiple pointers.”. So i gather it’s not a MUST. Oh well…

So, for nearly a year now i’ve been very disappointed with how multi-touch works on Android. Or rather does not work on most devices. This is nothing we can blame on Google. Some hardware manufacturers (HTC, Motorola to name the most prominent ones) don’t like bundling proper multi-touch screens with your 500$ phones. Why? I have no freaking idea, i imagine the cost of a proper touch pad wouldn’t be that much higher and i’d even be willing to throw out a few extra bugs to have proper multi-touch.

There’s two types of multi-touch functionality on Android. Let’s call them gesture multi-touch and real multi-touch. Gesture multi-touch is the only thing available on phones like the Nexus One. It features a “self capacitive” touch pad suited for gestures like pinch zoom but not suited for keeping track of multiple finger positions. Check the link to find out more. Real multi-touch on the other hand allows both, gesture detection as well as keeping track of multiple individual fingers.

Now, i could live with that fact if only there was a way for me as a programmer to know what’s actually supported by the phone my app is running on. Last time i checked (and i checked long and hard) there was no such thing. That was when API version 6 came out.

I wanted to implement multi-touch support for libgdx today and checked again. And, oh my fsm, i found something in the PackageManager class. Namely the following constants to be used with PackageManager.hasSystemFeature():

  • PackageManager.FEATURE_TOUCHSCREEN, The device’s display has a touch screen.
  • PackageManager.FEATURE_TOUCHSCREEN_MULTITOUCH, The device’s touch screen supports multitouch sufficient for basic two-finger gesture detection.
  • PackageManager.FEATURE_TOUCHSCREEN_MULTITOUCH_DISTINCT, The device’s touch screen is capable of tracking two or more fingers fully independently.
  • For games we want PackageManager.FEATURE_TOUCHSCREEN_MULTITOUCH_DISTINCT for obvious reasons. The N1 will return false. I have to test with the Motorola Droid, but it should also return false. Its screen is also severly broken.

    Seeing this i was happy at first. Then i realized that PackageManager.FEATURE_TOUCHSCREEN is actually pretty scary. There will be Android devices without a touch screen? I thought that was a minimum requirement? Maybe the documentation is just not extensive enough though and it serves as a valid but ultimately useless counterpart to PackageManager.FEATURE_TOUCHSCREEN_MULTITOUCH. If that’s not the case than i’m really afraid of the future. I assume that all the game UIs out there are touch driven, those would brake immediatly. Of course you could check at startup whether the device has a touchscreen at all. But…

    Those 3 constants are API Level 7 and 8, that is 2.1 and 2.2. Now, a lot of devices have received an update to 2.1 already, even my trusty HTC Hero. But i’d assume that only very low-budget devices would not have a touch screen. I’d further assume that those wouldn’t sport 2.1 or 2.2 either than. As a developer i’d have no chance of detecting the missing touch screen then.

    Why those constants weren’t there from at least 2.0 onwards is a riddle to me. Better late than never though, at least things are moving forward.

    In order to access the market with a new device each manufacturer has to pass the Android compatibility program. This program is executed by Google itself which sets the minimum software and hardware requirements a device has to fulfill for a specific version in order to be allowed to access the market. Additionally the software and hardware stack have to pass the compatibility test suite as a final test. Real multi-touch support from day 1 would have been the bestest thing since sliced bread for Android in my opinion. I can live with a software renderer for OpenGL, even one that does only affine texture mapping. But having this mess of multi-touch support is just sad.

    I still love Android and think Google is doing a fine job! It’s everyone’s fault!

10 thoughts on “How to find out whether multi-touch is supported on Android…

  1. >Why those constants weren’t there from at least 2.0 onwards is a riddle to me.

    I’ll stick with that it was a lack of planning and minimal architecture foresight until proven otherwise.. ;P After all I generally consider how multitouch was tacked onto MotionEvent to not exactly be very clean so to speak.

    >I still love Android and think Google is doing a fine job! It’s everyone’s fault!

    I love it too and have bet the farm on it, but sadness sometimes creeps in when I think of big G & Android… I’ll add… It’s everyone’s fault – “in at least one parallel universe!.”

    Fault in this universe can’t really be extended to the dev community I’m afraid (big G, OEMs, carriers to some extent sure). The only practical way I’ve found to manage adhoc ecosystem configuration is an external database / XML file specifically tracking device constraints of interest. This is the only thing that will work across all OSes (1.5+) and the entire ecosystem for all devices irregardless of API level and such a solution doesn’t come from big G.

    In this universe from the big G side (still on the universe theme!) though it comes down to old engineering methods being applied to a modern mobile OS attempt not suited for a wide and rapidly growing ecosystem of devices. The fact that Google only primarily shipped web oriented apps prior was a major difference when it came to shipping an OS across a wide and rapidly growing ecosystem. Management for Android & Google didn’t seem to take this into account. The ship it ship it ship it meme works great for web apps. However, ownership, accuracy / strong QA, and advanced architecture insight can go a long way. For the most part big G got a lot of things right – upwards of 80 or 90% – kudos, seriously. In this market driven world and the meteoric rise of Android market share I gotta say that the ship it, ship it, ship it meme did work for market share, but will things implode now or get better. Android isn’t the new kid on the block anymore and it’s got to get past these types of growing pains. I thought only year 1 would be dicey, but year 2 was just more of the same or worse. Year 3… time to hit a home run big G and shut me up! ;P

    The things that faltered unfortunately have a way of impacting real time app / game dev somewhat severely compared to many other app categories. The big problem is that each release hasn’t seemed to abate quality problems for real time app / game dev. I don’t think I’ve had a positive feeling about an OS update/release since 2.0.1 which mostly fixed a horribly buggy and obviously rushed 2.0 esp for GL ES concerns. Every release since then and most if not all major flagship devices have had various issues for real time app / game dev. IE I understand the latest EVO update this week finally backs out that horrible 30FPS capping constraint (horrible because of how poorly it was implemented by HTC!).

    I’d like to believe it will get better. But I’m not going to bet on that horse right now. It’ll still be up to the devs to work around the madness. I have a lot of hope for Gingerbread (and our forthcoming Tegra 2 overlords), but this year wasn’t a shining light for real time app / game dev on Android. Let’s hope next year will be… Unfortunately practically the entire existing ecosystem or at least upwards of 75% of current devices conceivably will EOL on FroYo or 2.1 if they even get updated that far; you’re Hero won’t see FroYo after all.

    I do find your general optimism refreshing though; usually that only comes from everyone else not doing lower level audio/graphics dev.. 🙂

  2. I hope you don’t mind me not quoting, it’s tedious in this comment system.

    When i said “it’s everyone’s fault” i only thought of Google, manufacturers and carriers. Developers can be a real pain in the ass i assume, either due to their ignorance and not RTFM or due to their attitude that they’d have done it better. While i don’t want to ignore the obvious problems like the multitouch API i have to say that Android is a pretty solid piece of software most of the time. Given the short periods in between releases and the size of the Android team i think it’s pretty amazing what they are able to pull off and we sometimes have to cut them some slack.

    Now, i can easily say that. I don’t make a living with my Android stuff (which there is not a lot off really…). Others are much more dependent on Google not screwing up. And i can see that this is indeed a big problem for real-time app/game developers. Many of the areas touched by such apps are subject to the most sever fragmentation of Android, hardware- and software-wise.Those guys suffer the most and i have the fullest empathy. While i tend to write as compatible and high-performance code as possible i’m not totally destroyed if i find out that some cheap-ass Android device has a quirk i can’t reproduce nor fix due to me not having said device. If been there on the PC. Granted, user reactions in market comments tend to be brutal when negative. But you have to learn to get over that. And you have to learn how to communicate that you are aware of those short-comings in your code (you actually only pretend that those are your short-comings as you know that in reality it’s a freaking graphics driver that’s responsible). The only thing i’d like to see in that regard is a better mechanism to get in contact with your users. A threaded comment system in the market would just be perfect i think. Of course that brings a slew of design problems with it but i guess that’s what some people on the Android team are paid for. If there was a single feature i could wish for it was this: threaded comment system in the market with clear indications if it’s a developer comment or a user comment. Give users an option to reveice notifications if a developer responded to a comment and i’d be in heaven. Again, this has implications, privacy being one of them. I think that the bare bones implementation of this would be as unintrusive as can be.

    I’m actually far from being an optimist. I tend to be practical. If there’s a problem i can’t fix or have no influence on i have to work with what i got. It won’t get better from complaining. It never has (unless you cound violent riots as complaints). Get your ass up and do something that fixes it for your specific set of problems or even for a whole community sharing the same problem. Again, it’s easy to talk like this being in my situtation, i’m aware of this.

    Thinking about what’s currently lacking in Android when it comes to game development i actually couldn’t come up with an extremely big list:
    – Garbage Collector, could be fixed in future releases. If you write games in Java you should keep an eye on these things anyways though, see Minecraft as a negative example. Granted, when system libraries leak (PlatformAddress used in NIO) then i start to rage too.
    – No native audio API. That just sucks. A very thin wrapper around the internal audio classes would have been sufficient and pretty much low maintainance. People would only need a way to feed PCM to the audio device. No decoding, no nothing, we can easily roll our own.
    – Proper OpenGL ES 2.0 Java bindings. Should be fixed in Gingerbread, in the meantime you can use my bindings which are backwards compatible down to version 2.0
    – Multitouch. Probably the biggest fuck up. I wished the minimum specs would require true multi-touch on all compatible devices. But i can see that certain device classes wouldn’t fit that requirements. It’s a hard decision. As multi-touch seems to grow stronger i think it would be a save bet to just include it as a minimum spec for 3.0 and be done with the issue. Oh, and the API is just hideous. I don’t know a lot of Java APIs that require you to do bit twiddling to arrive at actual data. That’s just nasty. If you force Java on your developers then stay within the common Java world. (i like bit twiddling, other’s don’t, it’s more a matter of consistency).
    – I don’t care for Canvas and general Skia related performance. I don’t use it enough for me to be a problem. 30fps cap? Cool with me, i’ll have a seperate thread using all the CPU i can get while the swap happens for things like CPU vertex skinning or physics. It is stupid, i agree. But i will make damn sure that a user of such a device knows what she just bought for a couple of hundred bucks.
    – Proper String measurements. They wrap FreeType (which in itself is a bit of a bitch already) but seem to have a problem somewhere. Either that or i fucked up in my glyph caching code. Probably the later though :p. Not a big deal, works for me after wasting some hours to figure out the fairy dust numbers… (and i have a not so weak background in font rendering…).
    – Buggy GPU drivers. Now that just plain sucks. I had my share of finding out that HTC can’t write one correct driver. It’s hard i grant them that. But they should have the money and engineering power to come up with something that passes the mininum Ogl tests. If Ogl would be new technology i could understand it. Think of CSS3/HTML5. It’s totally OK to not be compliant when the technology has just barely learned to crawl. But freaking OpenGL? I’ve never done graphics driver programming, but i can’t imagine that putting a nice and functional OpenGL layer on top of it is an unsolveable engineering problem. Hell, people even make OpenGL ES 2.0 work on top of the shitty DirectX 9 API (see ANGLE project by Google).

    Now the question is how much impact does all this have on you actually writting a game? I don’t have the impression that the top selling games on the market went through all this hazzles. Why is taht? I can only assume that focusing on a small subset of low-level functionality is the key. Don’t try to support and use every fucking feature out there, focus on what you need and make damn sure that it works. Testing 10 features is easier than testing 100 features.

    For me it all comes down to whether you love doing what you do or not. I love fighting with the machine. It’s like a very stimulating puzzle to me. I might not always find the perfect solution (or a solution at all) but that is often not my goal. As cheesy as it sounds, getting there is the fun part. Figuring stuff out, be they as annoying as they are. At the end of the day you learned something new which will hopefully help you in the future.

    Again, i’m not an apologist for anyone here. I think people should be spanked for the stupid they’ve produced at times. I just don’t mind all this that much that it really becomes a problem for me. Going full circle: i can talk like this, i’m financially independent from the Android ecosystem 🙂

    See, i too can write long comments. Now i demand a worthy reply!

  3. Those comments are to long 😉

    But on a side note: Along the knowen GestureDetector Android 2.2 brought a new ScaleGestureDetector which can be used to easily work with two finger zoom like gestures.

    Obviously this is not the point of concern for this blog post but its worth mentioning.

  4. Thanks for the post! It was ridiculous to find an android device(2.2) that does not support multi-touch, which lead us to this post and eventually we had to add the code if(!multiTouchSupport){…}

Leave a Reply

Your email address will not be published.