Global Sources
EE Times-India
Stay in touch with EE Times India
 
EE Times-India > Embedded
 
 
Embedded  

Designing USB device with Android framework

Posted: 05 Dec 2014     Print Version  Bookmark and Share

Keywords:Android  USB  Compatibility Test Suite  Linux kernel  RFC2119 

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. Title-1

Android USB Architecture
This section explains Android USB architecture based on the various USB modes in which an Android device can perform as explained in the initial section.

In simple terms, an Android platform is made of Android Linux kernel as the base to manage the platform resources. A Java-based Android framework sits on top of Android Linux kernel, providing the necessary user experience. Some Android features lay within the kernel, and certain features are available only at the Android framework. In case of USB, the functionality is managed between the Android Linux kernel and the user space Android framework.

The following section provides a top-level architectural view of Android USB in USB device mode, detailing the complete Android USB starting from the Android Linux kernel to the user space Android framework. When you connect an Android device to a host PC, the Android device is said to be in USB device mode and can export multiple USB functionalities like MTP, ADB, or CDC to the host PC through its descriptors. This type of USB device is referred as a composite device, where a single USB device supports multiple USB functions through their interfaces.

From the architecture diagram shown in figure 4, you can infer that the composite infrastructure is part of the kernel and most of the USB device functions are implemented as "class drivers" within the Android Linux kernel. There are exceptions, like ADB and MTP, which are implemented on both sides, i.e. the kernel and user space.

In such cases, the kernel driver implements just the transport part of USB, guaranteeing delivery of the data. The Android framework performs the functional management, implementing the class level protocol, which other chapters of this book will explore in more detail later. The following section provides a brief overview of the architectural blocks used in the USB device mode, as represented in figure 4.

 Android device in USB device framework architecture

Figure 4: Android USB device framework architecture.

USB Service Framework
The USB Service framework is the key factor and is the backbone in Android USB device mode. In a way, the role of this framework is to listen to and communicate state changes in Android kernel USB driver and subsequently pass that information on to other interested Android frameworks. Those frameworks then pass that information further to other modules by broadcasting their intent with only the necessary information. This framework also manages USB functions that an Android device has to share when connected to a host PC.

USB user space daemons
Most of the USB functions are implemented in the Android Linux kernel space. However, USB functions like ADB or MTP are implemented as user space daemons integrated within the Android framework. This block represents the daemons that implement USB Class requirements. Subsequent chapters on ADB and MTP provide a detailed view on how this module interacts with the kernel below and other Android frameworks.

android.hardware.usb
Android APIs for USBs are represented as a android.hardware.usb package and are discussed in further detail in later sections of this article. In a USB device mode, these APIs have a minimal role, as there are no APIs that allow managing a USB device's functionality. The exception to this is Android accessory mode, where developers are required to write applications to manage external devices over USB device mode.

Other infra frameworks
Within the Android framework there are many other frameworks that are interested in the USB state changes, like connection, disconnection, or a switch of USB functionalities. This "other infra" represents Android modules like storage infrastructure, network daemon infrastructure, and charging infrastructure, to name a few that are interested in USB state changes. These other infrastructures hook themselves up to the USB framework for the Intent that the USB Service module generate.

This module also represents the user interface part of Android that communicates USB state changes to the user over the Notification panel. The Android USB architecture is the same in USB accessory mode and USB device mode, as accessory mode is nothing but the USB device mode with some deviation.

 First Page Previous Page 1 • 2 • 3 • 4 • 5 Next Page Last Page



Comment on "Designing USB device with Android fr..."
Comments:  
*  You can enter [0] more charecters.
*Verify code:
 
 
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

 

Go to top             Connect on Facebook      Follow us on Twitter      Follow us on Orkut

 
Back to Top