[box style="note"]UPDATE: We have now launched Triggertrap Mobile for Android. See this post for more info.[/box] On the 1st of May 2012, we launched Triggertrap Mobile for iOS. The reception was incredible, but not everyone was happy: Within minutes of us announcing Triggertrap Mobile for iOS, Android users were asking why they'd been left behind. As a happy owner of an HTC One X and HTC Legend before that, I can understand the frustration, and we explained some of the reasons behind our decision in a post at the time.

We did promise that we wouldn't forget Android users, and that we'd release a version as soon as we were able. The first order of business was doing a 'viability study'. Basically, that's project management speak, and it answers a simple question: "Can we even make this happen?

We still don't have a clear answer to that question, but we did run into an issue that will at least limit functionality of any current Android version.

<Geeky Interlude>

Triggertrap Mobile works by communicating with the dongle using audio signals from the headphone port. This is fine on iOS, as audio is very high performance and low latency, which is one reason why there are so many cool audio apps out there. Android, however, takes a different approach to Apple.

Understandably, Android's priority is smooth playback of music, movies etc. They do that in many ways, but one of them they do this is by buffering the audio output. This works like a pipe: the app sends audio in one end, and when it's full it sends it out the other end to the headphones or speaker. This means that if there are any delays in sending the audio it doesn't cause glitches, because there's a buffer of audio to keep it running smoothly. There's a delay when the audio first starts as the buffer fills up, but that's not normally a problem.

When you press play on your music, you're unlikely to notice if there's a fraction of a second's delay before it starts playing. Apple has a similar system on iOS. The big difference is that on iOS, that's not the only way of sending audio. There are a number of audio systems available to Android developers, but all of them have to deal with this buffer. A lot of developers are unhappy about this.

</Geeky Interlude>

The upshot of all of this, is that there's an unavoidable delay to any audio signal on Android. The exact amount varies according to device, but is rarely less than 80 milliseconds. On some devices people have reported delays of over half a second. This will be in addition to any shutter lag on the camera.

What does this mean?

Obviously, a bit of a delay isn't necessarily a problem for modes that are based on timers; we can try and find a way of discovering what the delay is, and compensate for it. These modes would include stuff like timelapse and HDR modes, and certain distance-based modes. And, of course, any manual triggers, like the Cable Release mode.

However, a variable delay of 80 - 500 ms is somewhere between 'extremely inconvenient' and 'completely unacceptable' for sensor-based modes. We believe that the whole point of Triggertrap is that you can clap your hands or nudge a table to take a photo, which necessarily means that we need to be able to respond quickly.

The limitation in Android is an operation-system level limitation that will affect any camera trigger app on Android that uses the audio port to trigger the device. The only way to fix this would be to release our own version of the Android operating system that works around the issue. You'll have to forgive us; that's probably a little bit outside the scope of what we were hoping to do.

A possible solution

The only way we can see around this problem right now, is to use the USB port on the Android phones, instead of the audio port, but there are some special challenges with that as well. It will certainly involve developing brand new hardware, which - given that we've just been through a whole hardware development cycle to create our new European Union compatible Triggertrap Mobile Dongles - isn't ideal.

So... What now?

An Android version of Triggertrap Mobile is feasible, but the problem is that a large number of the Triggertrap modes aren't. As a result, we're facing a bit of a question: What do we do now?

Personally, some of the things we are most excited about are precisely the modes we can't do, which leaves us with an interesting question: As a company, do we want to spend a lot of time and money on a product that won't be able to do what we want?

We're going to continue our prototyping and experimenting for the Android platform, but the main message is that unless we find a solution that works with our current-generation hardware, we probably won't be launching an Android version anytime soon.

Can you help?

However, we don't want to leave it at that. We want an Android version, but for all of the reasons mentioned above, we are stuck. If you have any ideas for how we can make it all work, please don't hesitate to leave a comment below, or send us an e-mail on [email protected]