1 page.title=Android Open Accessory Protocol 2 @jd:body 3 4 <div id="qv-wrapper"> 5 <div id="qv"> 6 <h2>In this document</h2> 7 <ol> 8 <li><a href="#accessory-protocol">Implementing the Android Accessory Protocol</a> 9 <ol> 10 <li><a href="#wait">Wait for and detect connected devices</a></li> 11 <li><a href="#determine">Determine the device's accessory mode support</a></li> 12 <li><a href="#start">Attempt to start the device in accessory mode</a></li> 13 <li><a href="#establish">Establish communication with the device</a></li> 14 </li> 15 </ol> 16 17 <h2>See also</h2> 18 <ol> 19 <li><a href="aoa2.html">Android Open Accessory Protocol 2.0</a></li> 20 <li><a href="{@docRoot}guide/topics/connectivity/usb/accessory.html">USB Accessory Dev 21 Guide</a></li> 22 </ol> 23 </div> 24 </div> 25 26 <p>With Android 3.1, the platform introduces Android Open Accessory 27 support, which allows external USB hardware (an Android USB accessory) to interact with an 28 Android-powered device in a special accessory mode. When an Android-powered powered device is 29 in accessory mode, the connected accessory acts as the USB host (powers the bus and enumerates 30 devices) and the Android-powered device acts as the USB device. Android USB accessories are 31 specifically designed to attach to Android-powered devices and adhere to a simple protocol 32 (Android accessory protocol) that allows them to detect Android-powered devices that support 33 accessory mode. Accessories must also provide 500mA at 5V for charging power. Many previously 34 released Android-powered devices are only capable of acting as a USB device and cannot initiate 35 connections with external USB devices. Android Open Accessory support overcomes this limitation 36 and allows you to build accessories that can interact with an assortment of Android-powered 37 devices by allowing the accessory to initiate the connection.</p> 38 39 <p class="note"><strong>Note:</strong> Accessory mode is ultimately dependent on the device's 40 hardware and not all devices support accessory mode. Devices that support accessory mode can 41 be filtered using a <code><uses-feature></code> element in your corresponding application's 42 Android manifest. For more information, see the <a href= 43 "{@docRoot}guide/topics/connectivity/usb/accessory.html#manifest">USB Accessory</a> developer 44 guide.</p> 45 46 <h2 id="accessory-protocol">Implementing the Android Accessory Protocol</h2> 47 48 <p>An Android USB accessory must adhere to Android Accessory Protocol, which defines how 49 an accessory detects and sets up communication with an Android-powered device. In general, an 50 accessory should carry out the following steps:</p> 51 52 <ol> 53 <li>Wait for and detect connected devices</li> 54 55 <li>Determine the device's accessory mode support</li> 56 57 <li>Attempt to start the device in accessory mode if needed</li> 58 59 <li>Establish communication with the device if it supports the Android accessory protocol</li> 60 </ol> 61 62 <p>The following sections go into depth about how to implement these steps.</p> 63 64 <h3 id="wait">Wait for and detect connected devices</h3> 65 66 <p>Your accessory should have logic to continuously check 67 for connected Android-powered devices. When a device is connected, your accessory should 68 determine if the device supports accessory mode.</p> 69 70 <h3 id="determine">Determine the device's accessory mode support</h3> 71 72 73 <p>When an Android-powered device is connected, it can be in one of three states:</p> 74 75 <ol type="a"> 76 <li>The attached device supports Android accessory mode and is already in accessory mode.</li> 77 78 <li>The attached device supports Android accessory mode, but it is not in accessory mode.</li> 79 80 <li>The attached device does not support Android accessory mode.</li> 81 </ol> 82 83 <p>During the initial connection, the accessory should check the vendor and product IDs of the 84 connected device's USB device descriptor. The vendor ID should match Google's ID (0x18D1) and the 85 product ID should be 0x2D00 or 0x2D01 if the device is already in accessory mode (case A). If so, 86 the accessory can now <a href="#establish">establish communication with the device</a> through 87 bulk transfer endpoints with its own communication protocol. There is no need to start the device 88 in accessory mode.</p> 89 90 <p class="note"><strong>Note:</strong> 0x2D00 is reserved for Android-powered devices that 91 support accessory mode. 0x2D01 is reserved for devices that support accessory mode as well as the 92 ADB (Android Debug Bridge) protocol, which exposes a second interface with two bulk endpoints for 93 ADB. You can use these endpoints for debugging the accessory application if you are simulating 94 the accessory on a computer. In general, do not use this interface unless your accessory is 95 implementing a passthrough to ADB on the device.</p> 96 97 <p>If the vendor and product ID do not match, there is no way to distinguish between states b and 98 c, so the accessory <a href="#start">attempts to start the device in accessory mode</a> to figure 99 out if the device is supported.</p> 100 101 <h3 id="start">Attempt to start the device in accessory mode</h3> 102 103 <p>If the vendor and product IDs do not correspond to an Android-powered device in accessory 104 mode, the accessory cannot discern whether the device supports accessory mode and is not in that 105 state, or if the device does not support accessory mode at all. This is because devices that 106 support accessory mode but aren't in it initially report the device's manufacturer vendor ID and 107 product ID, and not the special Android Open Accessory ones. In either case, the accessory should 108 try to start 109 the device into accessory mode to figure out if the device supports it. The following steps 110 explain how to do this:</p> 111 112 <ol> 113 <li>Send a 51 control request ("Get Protocol") to figure out if the device supports the Android 114 accessory protocol. A non-zero number is returned if the protocol is supported, which 115 represents the version of the protocol that the device supports (currently, only version 1 116 exists). This request is a control request on endpoint 0 with the following characteristics: 117 <pre> 118 requestType: USB_DIR_IN | USB_TYPE_VENDOR 119 request: 51 120 value: 0 121 index: 0 122 data: protocol version number (16 bits little endian sent from the device to the 123 accessory) 124 </pre> 125 </li> 126 127 <li>If the device returns a proper protocol version, send identifying string information to the 128 device. This information allows the device to figure out an appropriate application for this 129 accessory and also present the user with a URL if an appropriate application does not exist. 130 These requests are control requests on endpoint 0 (for each string ID) with the following 131 characteristics: 132 <pre> 133 requestType: USB_DIR_OUT | USB_TYPE_VENDOR 134 request: 52 135 value: 0 136 index: string ID 137 data zero terminated UTF8 string sent from accessory to device 138 </pre> 139 140 <p>The following string IDs are supported, with a maximum size of 256 bytes for each string 141 (must be zero terminated with \0).</p> 142 <pre> 143 manufacturer name: 0 144 model name: 1 145 description: 2 146 version: 3 147 URI: 4 148 serial number: 5 149 </pre> 150 </li> 151 152 <li>When the identifying strings are sent, request the device start up in accessory mode. This 153 request is a control request on endpoint 0 with the following characteristics: 154 <pre> 155 requestType: USB_DIR_OUT | USB_TYPE_VENDOR 156 request: 53 157 value: 0 158 index: 0 159 data: none 160 </pre> 161 </li> 162 </ol> 163 164 <p>After sending the final control request, the connected USB device should re-introduce itself 165 on the bus in accessory mode and the accessory can re-enumerate the connected devices. The 166 algorithm jumps back to <a href="#determine">determining the device's accessory mode support</a> 167 to check for the vendor and product ID. The vendor ID and product ID of the device will be 168 different if the device successfully switched to accessory mode and will now correspond to 169 Google's vendor and product IDs instead of the device manufacturer's IDs. The accessory can now 170 <a href="#establish">establish communication with the device</a>.</p> 171 172 <p>If at any point these steps fail, the device does not support Android accessory mode and the 173 accessory should wait for the next device to be connected.</p> 174 175 <h3 id="establish">Establish communication with the device</h3> 176 177 <p>If an Android-powered device in accessory mode is detected, the accessory can query the 178 device's interface and endpoint descriptors to obtain the bulk endpoints to communicate with the 179 device. An Android-powered device that has a product ID of 0x2D00 has one interface with two bulk 180 endpoints for input and output communication. A device with product ID of 0x2D01 has two 181 interfaces with two bulk endpoints each for input and output communication. The first interface 182 is for standard communication while the second interface is for ADB communication. To communicate 183 on an interface, all you need to do is find the first bulk input and output endpoints, set the 184 device's configuration to a value of 1 with a SET_CONFIGURATION (0x09) device request, then 185 communicate using the endpoints.</p> 186 187
