Google’s Android Accessory Framework outlines several different options for accessory development. For designers considering developing Android-based accessories, this article covers some of the design considerations for determining which of the possible routes to take. Each application is different and these criteria may or may not change a designer’s mind, but knowing the options is the key to ending up with the best possible outcome.
by David Flowers
Principal Applications Engineer – Advanced Microcontroller Architecture Division
Microchip Technology Inc.
USB Hosts and Peripherals
USB is logically a point-to-point communication system between an attached peripheral and the host controller. Peripherals can never talk to each other through USB. There is only ever one host on the bus. Typically in a USB system, the USB host is the more powerful machine (more memory, more CPU power, better connectivity, and is going to typically be the focal point for the user), while the peripheral is often a simpler device with basic functionality on the bus as a service to the host.
The host also has two key responsibilities on the bus; the first is to supply power to attached peripherals and the second is to manage the devices on the bus. Because of these differences, the USB host-enabled device and USB peripheral devices often have very different designs.
Android Accessories as USB Peripherals
At first glance, the choice between these two USB options might seem clear. An accessory to a smartphone/tablet makes the most sense as a USB peripheral. The phone or tablet is likely to be the central focus point for the user, and the accessory is
likely going to be providing a service for the phone/tablet. Having the phone/tablet supply power to the accessory is also an attractive option. The option to use the Android phone or tablet as a USB host was enabled in the Android 3.1+ devices. However, this option is not available in other operating-system versions.
Android Accessories as USB Hosts
When Google released their OpenAccessory framework they recognised that many Android devices already in the marketplace were designed only for USB peripheral capability
and as such these phones and tablets don’t have the hardware required to operate as a USB host. In order to enable these products to attach to an accessory, Google created an accessory framework option based on the accessory being the USB host and the Android phone/tablet being the USB device. This OpenAccessory-framework option is enabled in both the Android 2.3.4 and Android 3.1+ operating-system versions.
Android Accessories for Standard USB Accessories
A third option that is available is native OS support; with the addition of USB host capabilities to the operating system, support for some standard accessories such as mice, keyboards, thumb drives, etc. was also added. For USB peripheral manufacturers
who make these types of standard accessories, they don’t need to worry about creating new devices or software to work with Android phones/tablets because their accessories will work on any operating system that supports that specific standard class driver. All three of these support options are highlighted in Figures 1a, 1b and 1c.
Which Option Should I Choose?
Each of the three available options has implications in the creation of an accessory. The first issue is the target set of Android devices for the accessory – In order to create an accessory that is a USB device, it requires the target Android phone/tablet to have the built-in hardware capability of being a USB host. Even if the hardware is capable of running USB host, unless the Android device is running Android 3.1+, it will not be able to use either of the USB host options. So an accessory designer needs to weigh the options of cost/features against what the Android 3.1+ adoption rate will be when the accessory is released. As new Android devices are released to the market, most are including the latest versions of Android. Figure 2 breaks down the adoption rates for the various versions of the Android operating system.
USB Host Must Provide The Power
The decision to select accessory mode, where the accessory is the USB host, isn’t as clear cut as just looking at the version adoption-rate information. In a USB system, the USB host must provide power to an attached peripheral. Peripherals can request up to 500 mA of current from the host. Most USB peripherals expect that a host can supply at least 100 mA. While this might be a suitable requirement for a refrigerator doing diagnostics or firmware updates, it might be too large a limitation for a device like a pulse oximeter, where the consumer is expecting the device to be mobile, small and have a long battery life. Having to provide a minimum of 100 mA is a very large power requirement for many mobile applications. Figures 1a, 1b and 1c show how the power is provided in the three possible accessory configurations.
Standard or Custom Applications?
In addition to the power-supply requirements, a designer must also consider how the accessory is going to be used and whether a custom application is acceptable. Any designer using the accessory mode, with the accessory as the USB host, will likely need to create a custom protocol for their application. Using the same two examples as before, the refrigerator and the pulse oximeter, it would be reasonable, or even expected, for the refrigerator to have a custom protocol, wherein the customer must use a vendor-specific application to talk to that device. The pulse oximeter, however, would likely want to use the built-in Personal Healthcare Device Class (PHDC) available in the USB protocol. Using this protocol allows the device to be used on any USB host machine, and allows the hardware to interface to a wide range of software. However, limiting this hardware to a vendor-specific application might be too constraining for consumers to accept.
If an accessory should be compatible with Android devices that don’t have USB host functionality, either due to hardware limitations or because they haven’t received an OS update to 3.1+ or later, then the accessory must use a custom protocol, as seen in Figure 1b. For accessories that can be limited to use with USB-host-enabled Android devices, the choice between a standard USB class or a custom class is entirely up to the designer. Though the OS may not have native support for a device, a custom application should still be able to access the device. This also allows the Android phone/tablet to work on other USB hosts that may support that device natively.
USB Physical Connectors
While they may not be a major determining factor, the physical connectors might also play a role in deciding which mode is used. For an accessory that is acting as the USB host, the USB specification indicates that that accessory should have a
full-sized, A-style female connector, like the connector found on a computer. Figure 3 shows how an accessory supporting a USB-peripheral-only Android device would connect to that device.
If the accessory is designated as the USB peripheral, designers have the option of using the full-size-B, mini-B, or micro-B female connectors. The other side of the cable must also be considered, however. For accessories that run as a USB peripheral, the Android device will be the USB host and most Android devices don’t have a full-size-A female connector, in which to plug a USB cable. For this reason, many of the Android devices on the market today that enable USB host mode require an adapter of some sort in order to use this functionality. In an ideal situation, the Android device would have a micro-A/B female connector, and the user would be able to use a micro-A to micro-B OTG cable to connect the accessory to the Android device and then use a micro-B to full-size-A cable to connect the Android device to a USB host, such as a standard PC.
Figure 4 shows how a USB OTG-capable Android device could connect to various targets.
USB OTG for Both Peripheral & Host
If the choice between the USB host-mode accessory and USB peripheral accessory options is not obvious, or both are desired—USB host in order to support devices without USB host capabilities, and USB peripheral for those that do, in order to use standard software—then there is another option available. Android accessories can be designed as a USB OTG device. The USB OTG specification allows an accessory to be either USB host or USB device, based on the cable that is plugged into it. Using USB OTG, an accessory can be a USB host for Android phones/tablets without host capability, and a USB peripheral for those Android phones/tablets with USB host functionality.
There are some complications associated with using USB OTG. The cable that is provided with the Android device will not connect to the accessory because that cable is likely going to have a full-size-A plug, which will not fit into the micro-A/B receptacle of the OTG accessory, so an additional micro-A cable would be required. Due to the various hardware connectors found on Android devices, this cabling issue is a significant challenge as only a micro-A to micro-B cable as a standard USB cable can be used, but many Android devices have either mini-B receptacles or custom female connectors. To further complicate the issue, there are some tablets and phones on the market that have OTG capability but are not using the micro-A/B receptacle. Instead, they use a micro-B receptacle with a custom, non-USB-compliant cable to enable the host-mode operation. Figure 5 shows how an OTG-capable accessory is able to interface to these types of Android devices; those with USB peripheral capability only, as well as those with USB host or OTG functionality.
If the accessory mode is selected, with the accessory acting as the USB host, there is still one more decision that needs to be made—which API set to use. When the accessory framework was added to Android 2.3.4, it was added as a Google API add-on library. The library module used in Android 2.3.4 (com.android.future.usb) is slightly different than the library used in Android 3.1 (android.hardware.usb). The interface between these two libraries also varies, but the functionality is basically the same. The main consideration here is that the android.hardware.usb library is only available in Android 3.1+, whereas the com.android.future.usb library is available in both Android 2.3.4 and Android 3.1+ devices. It is also important to note that the com.android.future.usb library is not a required library in Android 2.3.4, so there might be devices that are running Android 2.3.4 but do not have support for these features. It is up to the device manufacturer to determine whether they will include this feature in their OS build.
Using IOIO – The Android Debugger Interface
One final option should be covered on the topic of Android accessories. The IOIO solution enables the development of Android-based accessories through the Android ADB debugger interface. This solution provides a method for enabling accessories for
Android phones/tablets running Android 1.5 or greater, eliminating the issue of having to wait for the hardware manufacturers to push out Android 2.3.4 or Android 3.1+ to their devices before the accessory will work with them. There are also downsides to this solution as the following example, presented in the accessory development class at Google I/O 2011, demonstrates. While the ADB interface has not changed much in recent history, the presenters indicated that Google reserves the right to change this interface as it needs to on future devices, in order to enable development and debugger features for hardware and software developers. Additional information about comparing the accessory framework and the IOIO solution is available at the IOIO developers’ blog ( http://ytai-mer.blogspot.com/2011/06/ioio-over-openaccessory-adk-available.html ).
This article has covered some of the design considerations for determining which of the possible routes to take when considering Android-base accessories. Developers looking for additional information about Android-based accessories can refer to http://developer.android.com/guide/topics/usb/index.html or www.microchip.com/android
Questions can also be sent to androidsupport@microchip.com.
www.microchip.com