diff options
Diffstat (limited to 'docs/html/tools/adk/aoa.jd')
| -rw-r--r-- | docs/html/tools/adk/aoa.jd | 186 |
1 files changed, 0 insertions, 186 deletions
diff --git a/docs/html/tools/adk/aoa.jd b/docs/html/tools/adk/aoa.jd deleted file mode 100644 index 7884d6e..0000000 --- a/docs/html/tools/adk/aoa.jd +++ /dev/null @@ -1,186 +0,0 @@ -page.title=Android Open Accessory Protocol -@jd:body - -<div id="qv-wrapper"> - <div id="qv"> - <h2>In this document</h2> - <ol> - <li><a href="#accessory-protocol">Implementing the Android Accessory Protocol</a> - <ol> - <li><a href="#wait">Wait for and detect connected devices</a></li> - <li><a href="#determine">Determine the device's accessory mode support</a></li> - <li><a href="#start">Attempt to start the device in accessory mode</a></li> - <li><a href="#establish">Establish communication with the device</a></li> - </li> - </ol> - - <h2>See also</h2> - <ol> - <li><a href="aoa2.html">Android Open Accessory Protocol 2.0</a></li> - <li><a href="{@docRoot}guide/topics/connectivity/usb/accessory.html">USB Accessory Dev -Guide</a></li> - </ol> - </div> - </div> - - <p>With Android 3.1, the platform introduces Android Open Accessory - support, which allows external USB hardware (an Android USB accessory) to interact with an - Android-powered device in a special accessory mode. When an Android-powered powered device is - in accessory mode, the connected accessory acts as the USB host (powers the bus and enumerates - devices) and the Android-powered device acts as the USB device. Android USB accessories are - specifically designed to attach to Android-powered devices and adhere to a simple protocol - (Android accessory protocol) that allows them to detect Android-powered devices that support - accessory mode. Accessories must also provide 500mA at 5V for charging power. Many previously - released Android-powered devices are only capable of acting as a USB device and cannot initiate - connections with external USB devices. Android Open Accessory support overcomes this limitation - and allows you to build accessories that can interact with an assortment of Android-powered - devices by allowing the accessory to initiate the connection.</p> - - <p class="note"><strong>Note:</strong> Accessory mode is ultimately dependent on the device's - hardware and not all devices support accessory mode. Devices that support accessory mode can - be filtered using a <code><uses-feature></code> element in your corresponding application's - Android manifest. For more information, see the <a href= - "{@docRoot}guide/topics/connectivity/usb/accessory.html#manifest">USB Accessory</a> developer -guide.</p> - - <h2 id="accessory-protocol">Implementing the Android Accessory Protocol</h2> - - <p>An Android USB accessory must adhere to Android Accessory Protocol, which defines how - an accessory detects and sets up communication with an Android-powered device. In general, an - accessory should carry out the following steps:</p> - - <ol> - <li>Wait for and detect connected devices</li> - - <li>Determine the device's accessory mode support</li> - - <li>Attempt to start the device in accessory mode if needed</li> - - <li>Establish communication with the device if it supports the Android accessory protocol</li> - </ol> - - <p>The following sections go into depth about how to implement these steps.</p> - - <h3 id="wait">Wait for and detect connected devices</h3> - - <p>Your accessory should have logic to continuously check - for connected Android-powered devices. When a device is connected, your accessory should - determine if the device supports accessory mode.</p> - - <h3 id="determine">Determine the device's accessory mode support</h3> - - - <p>When an Android-powered device is connected, it can be in one of three states:</p> - - <ol type="a"> - <li>The attached device supports Android accessory mode and is already in accessory mode.</li> - - <li>The attached device supports Android accessory mode, but it is not in accessory mode.</li> - - <li>The attached device does not support Android accessory mode.</li> - </ol> - - <p>During the initial connection, the accessory should check the vendor and product IDs of the - connected device's USB device descriptor. The vendor ID should match Google's ID (0x18D1) and the - product ID should be 0x2D00 or 0x2D01 if the device is already in accessory mode (case A). If so, - the accessory can now <a href="#establish">establish communication with the device</a> through - bulk transfer endpoints with its own communication protocol. There is no need to start the device - in accessory mode.</p> - - <p class="note"><strong>Note:</strong> 0x2D00 is reserved for Android-powered devices that - support accessory mode. 0x2D01 is reserved for devices that support accessory mode as well as the - ADB (Android Debug Bridge) protocol, which exposes a second interface with two bulk endpoints for - ADB. You can use these endpoints for debugging the accessory application if you are simulating - the accessory on a computer. In general, do not use this interface unless your accessory is - implementing a passthrough to ADB on the device.</p> - - <p>If the vendor and product ID do not match, there is no way to distinguish between states b and - c, so the accessory <a href="#start">attempts to start the device in accessory mode</a> to figure - out if the device is supported.</p> - - <h3 id="start">Attempt to start the device in accessory mode</h3> - - <p>If the vendor and product IDs do not correspond to an Android-powered device in accessory - mode, the accessory cannot discern whether the device supports accessory mode and is not in that - state, or if the device does not support accessory mode at all. This is because devices that - support accessory mode but aren't in it initially report the device's manufacturer vendor ID and - product ID, and not the special Android Open Accessory ones. In either case, the accessory should -try to start - the device into accessory mode to figure out if the device supports it. The following steps - explain how to do this:</p> - - <ol> - <li>Send a 51 control request ("Get Protocol") to figure out if the device supports the Android - accessory protocol. A non-zero number is returned if the protocol is supported, which - represents the version of the protocol that the device supports (currently, only version 1 - exists). This request is a control request on endpoint 0 with the following characteristics: - <pre> -requestType: USB_DIR_IN | USB_TYPE_VENDOR -request: 51 -value: 0 -index: 0 -data: protocol version number (16 bits little endian sent from the device to the -accessory) -</pre> - </li> - - <li>If the device returns a proper protocol version, send identifying string information to the - device. This information allows the device to figure out an appropriate application for this - accessory and also present the user with a URL if an appropriate application does not exist. - These requests are control requests on endpoint 0 (for each string ID) with the following - characteristics: - <pre> -requestType: USB_DIR_OUT | USB_TYPE_VENDOR -request: 52 -value: 0 -index: string ID -data zero terminated UTF8 string sent from accessory to device -</pre> - - <p>The following string IDs are supported, with a maximum size of 256 bytes for each string - (must be zero terminated with \0).</p> - <pre> -manufacturer name: 0 -model name: 1 -description: 2 -version: 3 -URI: 4 -serial number: 5 -</pre> - </li> - - <li>When the identifying strings are sent, request the device start up in accessory mode. This - request is a control request on endpoint 0 with the following characteristics: - <pre> -requestType: USB_DIR_OUT | USB_TYPE_VENDOR -request: 53 -value: 0 -index: 0 -data: none -</pre> - </li> - </ol> - - <p>After sending the final control request, the connected USB device should re-introduce itself - on the bus in accessory mode and the accessory can re-enumerate the connected devices. The - algorithm jumps back to <a href="#determine">determining the device's accessory mode support</a> - to check for the vendor and product ID. The vendor ID and product ID of the device will be - different if the device successfully switched to accessory mode and will now correspond to - Google's vendor and product IDs instead of the device manufacturer's IDs. The accessory can now - <a href="#establish">establish communication with the device</a>.</p> - - <p>If at any point these steps fail, the device does not support Android accessory mode and the - accessory should wait for the next device to be connected.</p> - - <h3 id="establish">Establish communication with the device</h3> - - <p>If an Android-powered device in accessory mode is detected, the accessory can query the - device's interface and endpoint descriptors to obtain the bulk endpoints to communicate with the - device. An Android-powered device that has a product ID of 0x2D00 has one interface with two bulk - endpoints for input and output communication. A device with product ID of 0x2D01 has two - interfaces with two bulk endpoints each for input and output communication. The first interface - is for standard communication while the second interface is for ADB communication. To communicate - on an interface, all you need to do is find the first bulk input and output endpoints, set the - device's configuration to a value of 1 with a SET_CONFIGURATION (0x09) device request, then - communicate using the endpoints.</p> - |