FTF2014 - Android Accessory Protocol

Android Accessory Protocol
FTF2014
04/10/2014
Gary Bisson
Embedded Software Engineer

SESSION OVERVIEW
1. Introduction
2. Protocol Specifications
3. Accessory Development Kit
4. Software Implementation
5. Demonstrations
6. Conclusion

ABOUT THE PRESENTER
• Embedded Software Engineer at Adeneo Embedded
(Bellevue, WA)
Linux / Android
♦ BSP Adaptation
♦ Driver Development
♦ System Integration
Partners with Freescale

Android Accessory Protocol Introduction
INTRODUCTION TO AOA
• Allows USB hardware to interact with an Android-powered
device
No need for the Android device to act as USB Host
Standard API
• Introduced in Android 3.1 (API level 12)
Backported to Android 2.3.4 (API level 10)
• Version 2.0 released with Android 4.1
5

Android Accessory Protocol Introduction
INTRODUCTION TO AOA
6

Android Accessory Protocol Protocol Specifications
AOA 1.0 PROTOCOL
• Android Open Accessory 1.0 is a protocol that allows an
Android device to interact with an Android USB
Accessory in a special accessory mode.
• Basically there are four steps to initiate the
communication.
8

AOA 1.0 PROTOCOL
1. Wait for and detect connected devices
9

AOA 1.0 PROTOCOL
2. Determine the device’s accessory mode support
10

AOA 1.0 PROTOCOL
• The accessory must check the Vendor & Product ID’s of
the connected device
Possibility to target some devices
Detection of devices already in Accessory mode
• If it is already in accessory mode then:
Vendor ID = 0x18D1 (Google)
Product ID = 0x2D00 || 0x2D01
11

AOA 1.0 PROTOCOL
• Accessory mode product IDs
0x2D00 – Supports Accessory Mode
♦ 1 interface with 2 bulk endpoints
0x2D01 – Supports Accessory Mode + ADB
♦ 2 interfaces with 2 bulk endpoints each
• If it is not in accessory mode then Accessory mode support
can be asked:
Send a “Get Protocol” request (51) on endpoint 0
♦ AOA Version (1.0 or 2.0) is returned by Android
device
12

AOA 1.0 PROTOCOL
3. Attempt to start the device in accessory mode
13

AOA 1.0 PROTOCOL
• If the AOA Version # is okay, then send string’s identifying
our ADK to the device
Send “Identity” request (52) for each identifier:
♦ Manufacturer
♦ Model Name
♦ Description
♦ Version
♦ URL
♦ Serial Number
Send “Start Accessory” request (53) to request the
Android device re-introduce itself on the bus in
accessory mode
14

AOA 1.0 PROTOCOL
4. Establish communications
15

AOA 1.0 PROTOCOL
• The accessory must obtain the Bulk endpoints and be
prepared to initiate communication with the device
From this point the communication is defined by the ADK
Developer
16

AOA 2.0 PROTOCOL
• AOA 2.0 was released at Google I/O end of June 2012
alongside Jelly Bean
• Two new features:
Audio Output
Accessory as HID
17

AOA 2.0 PROTOCOL
• Audio output:
From an Android device to an accessory
Standard USB audio class interface (ISO)
Only supports 2 Channel, 16-bit PCM @ 44100KHz
• To enable the audio support, the accessory must send a
new USB control request:
“Audio Support” request (58)
18

AOA 2.0 PROTOCOL
• HID support:
Registers one or more USB HID with to the Android
device.
Reverses the direction of communication for typical
USB HID (Host <-> Device).
Uses USB control requests:
♦ ACCESSORY_REGISTER_HID
♦ ACCESSORY_UNREGISTER_HID
♦ ACCESSORY_SET_HID_REPORT_DESC
♦ ACCESSORY_SEND_HID_EVENT
19

AOA 2.0 PROTOCOL
• Compatible with original AOA 1.0 protocol
• Also adds Bluetooth support
Not the focus of this presentation...
Example available in ADK source code
20

AOA 2.0 PROTOCOL
• New Product ID’s
0x2D02 – Supports Audio
♦ 2 Audio interfaces (control + streaming)
0x2D03 – Supports Audio + ADB
♦ 3 interfaces: 2 Audio + 1 Bulk
0x2D04 – Supports AOA 1.0 + Audio
0x2D05 – Supports AOA 1.0 + Audio + ADB
21

Android Accessory Protocol Accessory Development Kit
GOOGLE ADK
• Hardware for ADK 2011 is based on a Arduino Mega2560
• Hardware for the ADK 2012 is based on an ARM
Cortex-M3
• ADK 2012 Guide
23

WHAT PART OF AOA DO YOU CONTROL?
• ADK HW
Schematics provided for the alarm clock
24

• Other solutions?
Any USB Host capable device that can provide power
to the Android device.
This is what makes it easy to port the ADK SW to any
ARM-based board
♦ e.g. i.MX SoCs,Kinetis MCU
♦ Brings more capabilities (video control...)
25

• ADK SW
Developer controls what runs on the ADK HW and
what runs on the Android device
• Google provides sample software:
Source code repo:
♦ android.googlesource.com/accessories/manifest
Android device application can apply on any device
with API level > 10
♦ Android Application presents UI for control, and
communication
26

ADK SOFTWARE
• Accessory side:
Full-featured:
♦ Accessory
Basic controls (LEDs, GPIOs)
♦ Audio
♦ Bluetooth
Code is Arduino-specific
♦ For other solutions, need for a “portable”
Accessory sample code
27

ADK SOFTWARE
• Android device side:
Hardware control
28

Android Accessory Protocol Software Implementation
SOFTWARE IMPLEMENTATION
1. Software on the ADK HW
Handles communication with Android device
Controls sensors, displays, etc. on the ADK HW
2. Software on the Android device
Can be installed automatically via pop-up URL on
connection
Handles communication with ADK HW
Presents a GUI for control, data input/output from ADK
30

SOFTWARE INSTALLATION
In case the software is not already installed:
31

FIRST USE
Otherwise the user must authorize the execution of the
Accessory app:
32

ANDROID APPLICATION
• Must discover the accessory when it is attached
• Communicate with the accessory via ADK Developer
defined commands over USB
• Utilizes the USB API in Android
33

ANDROID APPLICATION
• Android contains two different packages to support AOA
protocol:
android.hardware.usb
♦ Works with no add-on library for Android 3.1 or
higher
com.android.future.usb
♦ From Google API add-on library for Android 2.3.4
or higher
♦ Wrapper around android.hardware.usb
♦ Better choice to support the widest range of
devices
34

ANDROID APPLICATION
• First add an intent-filter to the application’s manifest
(manifest.xml)
1 <intent-filter >
2 <action android:name="android.intent.action.MAIN" />
3 <category android:name="android.intent.category.LAUNCHER" />
4 <action
android:name="android.hardware.usb.action.USB_DEVICE_ATTACHED"/>
5 </intent-filter>
6 <meta-data
android:name="android.hardware.usb.action.USB_DEVICE_ATTACHED"
7 android:resource="@xml/device_filter" />
35

ANDROID APPLICATION
• Then define a resource file that details which USB
Accessory this Application communicates with
(accessory_filter.xml)
1 <?xml version="1.0" encoding="utf-8"?>
2 <resources>
3 <usb-accessory
4 manufacturer="Google, Inc."
5 model="DemoKit"
6 version="2.0" />
7 </resources>
36

COMMUNICATION WITH THE ACCESSORY
• Grab the UsbAccessory handle from the Intent received
• Open up input/output file streams with the Accessory
1 if (UsbManager.ACTION_USB_ACCESSORY_ATTACHED.equals(action)) {
2 UsbAccessory accessory = UsbManager.getAccessory(intent);
3 if (intent.getBooleanExtra(UsbManager.EXTRA_PERMISSION_GRANTED
, false)) {
4 mAccessory = accessory;
5 fd = UsbManager.getInstance(getApplicationContext()).
openAccessory(accessory).getFileDescriptor();
6 mFout = new FileOutputStream(fd);
7 mFin = new FileInputStream(fd);
8 }
9 }
37

ACCESSORY APPLICATION
• Control transfers for initialization
• Bulk transfers for custom com
MCU sample code:
1 res = usbh_check_transfer(outpipe);
2 if (res != PIPE_RESULT_NOT_QUEUED)
3 return -1;
4 usbh_queue_transfer(outpipe, buf, len);
Linux sample code:
1 ret = libusb_bulk_transfer(acc->handle,
2 AOA_ACCESSORY_EP_IN, acc_buf,
3 sizeof(acc_buf), &transferred,
4 200);
38

• Audio streaming
Arduino ADK or MCU:
♦ DMA to DAC
♦ Simple solution
Linux implementation:
♦ ALSA sound card
♦ Custom ISO implementation
39

40

• HID support:
4-step process
♦ Register HID device
♦ Set HID report (defines capabilities)
♦ Send HID reports
♦ Unregister HID device
41

• Tool to create your HID report structure:
HID Descriptor Tool
42

Android Accessory Protocol Demonstrations
HARDWARE SELECTION
• Android Device
Stock Nexus 7 Tablet running Android KitKat (v4.4.2)
• Custom ARM-based accessory
i.MX6 SabreLite
GNU/Linux
44

HARDWARE SELECTION
• Why were these particular platforms chosen?
i.MX6: powerful & famous nowadays
Show ease of using libusb-based code
Nexus 7: stock device that needs no modification
♦ Any Android device would work the same
45

DEMONSTRATION #1
• Create an accessory device that:
Displays pictures
Allows control of the slideshow from Android
• Shows AOA v1.0 capabilities
46

DEMONSTRATION #2
Get ADK app data
Plays audio
Audio streaming
47

DEMONSTRATION #3
Requires no app
Plays audio
Send HID events
HID device
48

MUSIC
• Moby - Innocents
Open-source tracks
Available on SoundCloud
More on mobygratis
• Blend.io
GitHub for Music
Pull entire project
Ableton / Logic /
GarageBand
49

Android Accessory Protocol Conclusion
CONCLUSION
• Interesting standard
Great flexibility
Can overcome HW access issues
Compatibility v2.0 / v1.0
• Limitations
• Code source of Linux ADK available:
https://github.com/gibsson/linux-adk
51

QUESTIONS?
52

REFERENCES
• Di Cerbo, Manuel: “Turn your Linux computer into a huge
Android USB Accessory”
http://android.serverbox.ch/?p=262
• libusb: http://www.libusb.org/
• Android Developers:
http://developer.android.com/index.html
• Jesse Dannenbring: AOA presentation
53

FTF2014 - Android Accessory Protocol

More Related Content

What's hot (20)

Similar to FTF2014 - Android Accessory Protocol (20)

Recently uploaded (20)

FTF2014 - Android Accessory Protocol