Advertisement

The basics of USB device development using the Android framework

Rajaram Regupathy

November 19, 2014

Rajaram RegupathyNovember 19, 2014

(Editor's Note: Excerpted from Unboxing Android: A hands on approach with real world examples, by Rajaram Regupathy, the author takes you through features of importance to a device developer.in Android’s USB framework. He explains the various USB APIs that it exports to assist in implementation of an application on an embedded/mobile/consumer IoT design.)

Android has become one of the most successful open platforms, powering up millions of mobile devices and similar embedded devices worldwide. According to Google, more than a million new Android devices are added to this statistic every day. This large market presence and continuous market penetration makes it the ideal platform for developers, SMEs, and bigger enterprises to portray their presence and reach out to end users. For Android devices, Google provides the necessary infrastructure to develop new applications. These devices can reach millions of end users through Google’s open market platform named “Google Play.”

Such a large development and deployment process necessitates standardization in order to ensure compatibility of these applications across the multitudes of Android devices that exist. To facilitate this, Google created a compatibility program that enables application developers, end users, and platform manufacturers to maintain program consistency and a similar user experience across devices. A detailed overview of the compatibility program is available on Google’s Android web site.
.
The compatibility program consists of three key components: a Compatibility Definition Document (CDD), theAndroid Platform Source Code, and  a Compatibility Test Suite (CTS). Any device that claims to be an “Android” device has to comply with the Android CDD and successfully pass all CTS test suites.

In order to study the framework within Android, it is important to understand the aforementioned three key components. Thus, in order to best study the Android USB framework, it is important to focus and explore what Android CDD defines as a USB requirement, and how that requirement is implemented. This article explores the USB section of the Android CDD in the Android USB framework. It will also introduce you to the various USB APIs that the Android framework exports in order to assist an application developer in managing the USB functionality of an Android device.

Android CDD – USB
At the time of this writing, Android 4.4 Kit Kat is the latest version of Android and Android 4.4 CDD defines the compatibility requirement of the Android Kit Kat version. You can find the complete list of Android CDDs on Google’s Android website.

So, what is an Android CDD? In simple terms, the Android CDD defines the requirements that must be met in order for a device to claim that it is an Android-compatible device. To an extent, Android CDD is brief in that it is a 30-40 page document. This document can point to specifications like the USB Audio, for example, to indicate the user’s expectation. The CDD also identifies features as “must,” “must not,” “required,” “shall,” “shall not,” “should,” “should not,” “recommended,” “may,” and “optional,” as per the IETF standard that is defined in RFC2119. It is important for developers to pay attention to these terms and take care while developing Android applications when using an optional feature or any feature listed as “may.”

When it comes to USB, an Android device can operate in two modes—USB device mode or USB host mode.

USB Device Mode
When an Android device is connected to a host PC using USB, as illustrated in Figure 1, the Android device is said to be in USB device mode and power is sourced from the host PC USB port. (A device that needs more power than the host can provide should have its own power source.)



Figure 1: Illustration of an Android device in USB device mode

USB Host Mode
When a USB device is connected to an Android device, as illustrated in Figure 2, the Android device is said to be in USB host mode, and the Android device has to supply power to the connected device. An Android device functioning as a USB embedded host or as an On-The-Go (OTG) host must supply 5V/500mA of power when the connected device is USB bus powered.



Figure 2: Illustration of an Android device in USB host mode

There is also a unique Android USB setup, which was introduced during the Honeycomb version of Android, named the USB accessory mode.

USB Accessory Mode
In USB accessory mode, an Android device that is in the USB device mode can manage external devices. This ability is achieved by connecting the Android device to an external embedded accessory device, which acts as a USB host. The Android device goes to USB accessory mode in order to manage devices that connect to the accessory device. Figure 3 depicts Android accessory mode with a simple illustrative example of managing a camera from an Android device using an accessory device. Accessory mode is explained in detail in Chapter 5 of the book, which will provide you with a better understanding of the process.



Figure 3: Illustration of an Android device in USB accessory mode

The USB section of Android CDD defines which USB functionalities have to be supported in the host and device modes. Table 1 and Table 2 capture the requirements when an Android device acts as a USB device or as a USB host.


USB Device Requirement
  • The port must be connectable to a USB host with a standard USB-A port.
  • The port should use the micro-USB form factor on the device side
  • The port should be centered in the middle of an edge. Device implementations should either locate the port on the bottom of the device (according to natural orientation) or enable software screen rotation for all apps (including the home screen), so that the display draws correctly when the device is oriented with the port at the bottom. Existing and new devices that run Android 4.4 are very strongly encouraged to meet these requirements in Android 4.4 so that they will be able to upgrade to future platform releases.
  • If the device has other ports (such as a non-USB charging port) it should be on the same edge as the micro-USB port.
  • It must allow a host connected to the device to access the contents of the shared storage volume using either USB Mass Storage Protocol or the Media Transfer Protocol.
  • It must implement the Android Open Accessory API and specification as documented in the Android SDK documentation, and also must declare support for the hardware feature android.hardware.usb. accessory .
  • It must implement the USB audio class (version not mentioned in CDD) as documented in Android SDK documentation (http://developer. android.com/reference/android/hardware/usb/UsbConstants. html#USB_CLASS_AUDIO).
  • It should implement support for USB battery charging specification (version 1.2) [Resources, 64]. Existing and new devices that run Android 4.4 are very strongly encouraged to meet these requirements in Android 4.4, so that they will be able to upgrade to future platform releases.
  • Device implementations must implement the Android Debug Bridge.
  • If a device implementation omits a USB client port, it must then implement the Android Debug Bridge via a local area network (such as Ethernet or 802.11).


Table1: Android CDD 4.4 requirements as defined in USB Device Requirements

Existing and new devices that run Android 4.4 are very strongly encouraged to meet these requirements in Android 4.4 so that they will be able to upgrade to future platform releases.


USB Host Requirement
  • It may use a non-standard port form factor, but if so, the device must be shipped with a cable or cables that will adapt the port to a standard USB-A.
  • It must implement the Android USB host API as documented in the Android SDK and declare support for the hardware feature android.hardware.usb.host.


Table 2: Android CDD 4.4 as Defined in USB Host Requirements

These requirements are defined in section 7.7 USB of the Android CDD 4.4, and you should also note that the requirements are brief and point to the actual specifications. It is important to note that there are few requirements that define actual physical characteristics of an Android device. These physical characteristics will be handy when maintaining compatibility with external accessories, such as audio docks.

Over and above these two tables, USB requirements can also be found across other sections such as “Memory and Storage.” The following snippet captures one such requirement from the storage section of CDD:

“Regardless of the form of shared storage used, device implementations MUST provide some mechanism to access the contents of shared storage from a host computer, such as USB mass storage (UMS) or Media Transfer Protocol (MTP). Device implementations MAY use USB mass storage, but SHOULD use Media Transfer Protocol. If the device implementation supports Media Transfer Protocol:
  • The device implementation should be compatible with the reference Android MTP host and Android File Transfer.
  • The device implementation should report a USB device class of 0x00.
  • The device implementation should report a USB interface name of MTP.

If the device implementation lacks USB ports, it must then provide a host computer with access to the contents of the shared storage by some other means, such as a network file system.”

The storage section defines how the storage space of an Android device should be shared by a host PC over USB and. The storage section explains in detail mandating MTP as the preferred USB protocol for sharing the storage space.

These requirements are defined in section 7.7 USB of the Android CDD 4.4, and you should also note that the requirements are brief and point to the actual specifications. It is important to note that there are few requirements that define actual physical characteristics of an Android device. These physical characteristics will be handy when maintaining compatibility with external accessories, such as audio docks.

Now that you are able to understand Google Android’s USB requirements, you can now explore how these requirements are built within the Android framework.

< Previous
Page 1 of 2
Next >

Loading comments...

Most Commented