Android Open Accessory Mode (AOA) Support in 2017
08 May 2017While Bluetooth gets plenty of attention for providing sensor and accessory connectivity to Android devices, an older protocol introduced at Google I/O 2011 continues to promise widely compatible, no-pairing data wired data transfer.
During the course of evaluating connectivity options for an Android-connected accessory in a recent project, Android Open Accessory (AOA) came up as an option. This is a little talked about protocol that has been around since API 3.1, and provides ‘driverless’ support for communicating to an external USB device which must power the bus (like a host).
‘Widespread compatibility’ was an important metric for us, which ruled out USB OTG. Using OTG/Host mode would reduce the accessory cost and complexity by removing the need for the accessory to have a battery (since the phone powers the accessory in OTG mode), but the spotty availability of native, works-out-of-the-box USB OTG support on low and mid-range handsets eliminated this as a possibility.
This left the choices of WiFi, BlueTooth, and AOA. We decided to determine empirically how widely supported AOA was, and found the results quite promising.
To investigate further, we purchased the UMFT311EV AOA evaluation board from FTDI. This board implements the full AOA protocol, and FTDI provides a UART Terminal App which, if installed on an Android phone, will send data to a connected AOA device.
We used this app and evaluation board, and connected to the UART on the board to attempt bidirectional communication with the phone from a separate computer via the FTDI311 evaluation board, using AOA to the phone.
Phones Tested for AOA Support
This is a list of phones which we tested, where we indicate “AOA 1.0 Bidirectional Data Support” if the phone met the following criteria:
- The phone immediately detects that an AOA accessory is plugged in, and prompts a relevant dialog upon insertion of the AOA
- We are able to receive data at our UART terminal connected to the FTDI evaluation board from the phone
- We are able to send data from our UART terminal to the phone through the FTDI evaluation board
- We do not have to modify any settings or configuration on the phone, it ‘just works’
In the table below, APIs for all phones not supporting AOA are explicitly noted, as well as a few ‘newer’ models to indicate the firmware at time of testing.
Manufacturer
| Manufacturer | Model | AOA 1.0 Bidirectional Data Support |
|---|---|---|
| Alcatel | 918S (API 2.3.6) | No |
| Alcatel | 4007D (API 2.3.6) | No |
| Alcatel | 4015D | Yes |
| Alcatel | 4028S | Yes |
| Alcatel | 4032E Pop C2 | Yes |
| Asus | Zenfone | Yes |
| Blu | Dash 3.5 (API 2.3.5) | No |
| Blu | Dash Jr K | Yes |
| (Unknown) | FS358/WaterWorld67715~ | Yes |
| Huawei | Ideos (API 2.2) | No |
| Huawei | Honor 3x [G750-T00] | Yes |
| Huawei | Y221-U22 | Yes |
| Huawei | Y330-U05 | Yes |
| Huawei | Y336 | Yes |
| Infinix | x351 | Yes |
| Itel | it1409 | Yes |
| Jivi | JSP20 (API 2.3.5) | No |
| LG | E615 | Yes |
| Mi-Fone | MI-A403 | Yes |
| Pixel (API 7.1.2) | Yes | |
| Motorola | Moto G4 [Athene Core] | Yes |
| Motorola | Moto E2 | Yes |
| Plum | X350 | Yes |
| Prestigio | 3540 DUO | Yes |
| Samsung | Galaxy Tab E SMT560-NU | Yes |
| Samsung | GT-S5380V (API 2.3.6) | No |
| Samsung | GT-3501L | Yes |
| Samsung | JM-110H/DS | Yes |
| Samsung | SM-361H/DS | Yes |
| Tecno | P5S | Yes |
| Tecno | W4 | Yes |
| Tecno | Y2 | Yes |
| Tecno | Y4 | Yes |
~ The “FS358” is not labeled beyond the model, and simply reports an oem of “waterworld67715”
This is, of course, not comprehensive by any means – but intentionally skewed towards handsets that are deployed primarily in the developing world.
Note that all phones which did not support AOA are pre API 3.1; which is expected. So far, we have no evidence that phones newer than API 3.1 lack support for AOA.
Future Support?
It is unclear what the roadmap for AOA support moving forward looks like:
- Is there an AOA 3.0 with new features on the horizon?
- Is ‘keeping the status quo’ alive the way forward? or..
- Is AOA going to be unceremoniously chopped out at some point?
As ‘feel-good’ evidence for ongoing support, it’s nice that the Pixel clearly supports AOA (so, this functionality isn’t getting deprecated in today’s latest ‘flagship’ handsets, at least). It is also nice that all phones we tested with API >= 3.1 were fully supported.
Straight from the documentation itself, however, there is no guarantee that a given handset will have AOA support:
Because not all Android-powered devices are guaranteed to support the USB accessory APIs, include a
element that declares that your application uses the android.hardware.usb.accessory feature.
Android Open Accessory Protocol 1.0
As for existing uses, a cursory search for commercial products using AOA turned up automotive head units (car stereos) supporting AOA. A major online vendor in the space, Crutchfield, lists a specific section for “Android Control AOA Car Stereos”. This application appears to leverage the streaming audio endpoints introduced in AOA V2. One can imagine wanting to pipe audio from a handset into a car stereo in higher fidelity than (non-AptX) Bluetooth can provide, but with some form of audio playback control. In this, AOA seems to have found a pleasant market niche.
Will this still be supported on Android handsets being released in 2020? No clear answers yet.
An interesting factoid discovered along the way – connecting to a phone via ADB,
and executing adb shell ls /system/etc/permissions | grep "usb" provides
evidence of whether a phone can potentially support AOA or USB OTG. Specifically:
- Presence of
android.hardware.usb.accessory.xmlindicates AOA may be supported - Presence of
android.hardware.usb.host.xmlindicates USB OTG may be supported
If the relevant XML file is not present, the phone will not support the connection mode of interest.