We recently wrote about USB chip specialist FTDI’s progress into Android, supporting – via open accessory mode – connecting an Android device to peripheral hardware over USB.
It immediately provoked the question, what exactly is Open Accessories Mode? How exactly would your Android phone control, for example, your customised home gadget (a curtain closing device, perhaps)? And where does this fit with standard USB comms?
Well, it’s not the same as the PC way of operation. Things are apparently turned upside down, with the accessory acting as the ‘master’ (USB Host) and the Android device as the ‘slave’ (USB Device)…
In the beginning, 2011
Back in May 2011 a post on the Android Developers Blog – by Justin Mattson, an Android Developer Advocate, and Erik Gilling, an engineer on the Android systems team – heralded the beginning of Open Accessories (see the YouTube video below, of the Google I/O 2011: Keynote Day One).
The Android Open Accessory APIs for Android were designed to allow USB accessories to connect to Android devices without special licensing or fees, they say. The new “accessory mode” means the Android device is not required to support USB Host mode (there is, apparently, also USB Host mode APIs for devices with hardware capable of supporting it).
They write about why the extra support is necessary:
“To understand why having a USB port is not sufficient to support accessories let’s quickly look at how USB works. USB is an asymmetric protocol in that one participant acts as a USB Host and all other participants are USB Devices. In the PC world, a laptop or desktop acts as Host and your printer, mouse, webcam, etc., is the USB Device. The USB Host has two important tasks. The first is to be the bus master and control which device sends data at what times. The second key task is to provide power, since USB is a powered bus.”
“The problem with supporting accessories on Android in the traditional way is that relatively few devices support Host mode. Android’s answer is to turn the normal USB relationship on its head. In accessory mode the Android phone or tablet acts as the USB Device and the accessory acts as the USB Host. This means that the accessory is the bus master and provides power.”
Two major stages in the protocol involve ‘connection’ and ‘communication’.
First, they write, there’s a handshake to establish a bi-directional connection – the accessory needs to connect with the app running on the Android device. The latter identifies itself with the Vendor-ID/Product-ID appropriate to the manufacturer and model of the device.
Next, the accessory asks the Android device it does indeed support accessory mode. When the accessory receives confirmation, it sends a series of strings to the Android device, which allow the device to identify compatible applications and tells it to enter accessory mode.
“The Android device then drops off the bus and reappears with a new VID/PID combination. The new VID/PID corresponds to a device in accessory mode, which is Google’s VID 0x18D1, and PID 0x2D01 or 0x2D00. Once an appropriate application is started on the Android side, the accessory can now communicate with it using the first Bulk IN and Bulk OUT endpoints.”
The authors say the protocol is easy to implement on your accessory. The Accessory Development Kit (ADK) enables the use of the AndroidAccessory library to implement the protocol, to make things more straightforward.
After the low-level USB-level connection is established between the Android device and the accessory, control is handed over to an Android application. Such an app registers to handle comms with a USB accessory through an entry in the AndroidManifest.xml. You also have to define the accessories the Activity supports.
As is standard, the user will be presented with a dialog asking what application should be opened, after the Android system has signalled that an accessory is available by issuing an Intent. As part of the accessory-mode protocol, the accessory can specify a URL to present to the user if no application is found which knows how communicate with it. It may for example, be the URL for an application in Android Market that is specifically designed for use with the accessory. Plug and discover and play, as it were.
After the app opens, it uses the Android Open Accessory APIs in the SDK to communicate with the accessory. The data will be sent and received following the opening of a single FileInputStream and single FileOutputStream. “The protocol that the application and accessory use is then up to them to define”. In other words, the comms can then be accessory – and app – specific. Your curtain closing device, for example, may require a special curtain closing app.
Pick up and run
Google encourages third-party development in this area:
“Accessory mode opens up Android to a world of new possibilities filled with lots of new friends to talk to,” write Mattson and Gilling. “We can’t wait to see what people come up with. The docs and samples are online; have at it!”
Accessory Development Kit – Enter Arduino
The Accessory Development Kit (ADK) is a reference implementation for hardware manufacturers and hobbyists to use as a starting point for building accessories for Android.
Note that ADK 2012 is the latest reference implementation of an Android Open Accessory device, released at Google I/O 2012. The ADK 2012 is actually based on the Arduino open source platform, but with some hardware and software extensions that allow it to communicate specifically with Android devices – see Build Android accessories with Cortex-M3 based Arduino Due.
Android Open Accessory Protocol 1.0
Finally, if you want to dive even deeper into the topic, you will want to reference Android Open Accessory Protocol 1.0. This details the control requests and string IDs required.
The FTDI product was the source for this post, and you can read the company App Note on this topic – Accessing Android Open Accessory Mode with Vinculum-II (Application Note AN_181).