Aoa android что это
После того как я разбил тач на Nexus 7 2013, а теперь сломалось запоминание канала HDMI на «народном» контроллере (+ отваливание хаба от, скорее всего, перегрева) появилась идея использовать вместо полной интеграции телефон с каким-либо крепежом. Первым делом подумал о том, что зае. устану постоянно подключать/отключать, но затем понял, что скорее всего нет, с учётом того что будет всего один кабель.
Идея, конечно же, не нова. Вопросы надо решить следующие:
- Зарядка телефона
- Как пустить звук
- Кнопки на руле (ну в целом управление)
- Возможная периферия (датчики температуры и т.п.)
- Камера заднего вида
Список выше составлен с учётом того что всё это уже было при «полной» интеграции.
1. Зарядка телефона
Всё просто — usb-кабель одним концом в телефон, другим в зарядник. Надеюсь что сработает.
2. Звук
Звук можно было бы пустить через предназначенный для этого разъём, но подключать два кабеля это перебор. Bluetooth. Bluetooth, в целом, это прекрасная штука. Но вот звук по bluetooth не всегда хороший. Я не претендую на экспертные знание в области bluetooth-звука, но есть у меня Alpine CDE-195BT и я пробовал соединение по BT. Не могу сказать, что качество ужас, но вот разницу с AUX слышу даже я со своими неаудиофильскими ушами. Причём, с Nexus 7 2013 было даже нормально, а вот с geekbox совсем никак. Я слышал про aptX, но поддержка должна быть и на «приёмнике» и на «передатчике».
Мне очень повезло наткнуться на проект USB audio dock for Android товарища Jacek Fedoryński. Посмотрев что к чему, расчехлил Raspberry Pi и решил повторить, тем более, что Android Open Accessory Protocol 2.0 решал почти все остальные проблемы из списка.
Сделав всё как в инструкции, я потерпел крах. Звук никак не хотел «идти» куда надо. Но! Сам протокол включался и телефон переходил в режим AOA2, и звук с него просто пропадал, значит он уходил к RPi, а он (пирог же, в переводе) уже лажал и не отдавал звук. Этот факт вселил в меня надежду и я начал дебажить RPi. Опытным путём было установлено что не пашет PulseAudio. Ну как не пашет. если после подключения телефона самому выполнить команду:
то звук чудесным образом появлялся, но вот автоматически никак не хотел. Не хотел и от root’а. Я не знаток linux систем и не знаю от чьего имени выполняются скрипты из правил udev, но все возможные варианты сделать PulseAudio системным демоном/дать права всем пользователям положительного результата не дали.
Ситуация с PulseAudio меня деморализовала. В тщетных попытках нагуглить решение с PulseAudio я натыкаюсь на проект AndroidCarAudioDock. Меняем проблемную строчку на:
и звук уже не пропадает. Проблема, ну на сколько я понял, такая: udev’у нужно чтобы скрипт что-то вернул, чаще всего: ноль — всё хорошо, отрицательные числа — что-то пошло не так. Например exit 0 в конце скрипта. Можно ещё запуск команды в фоне ( . )$. Я честно всё перепробовал, но timeout срабатывал. Заработало только когда запускал через echo . | at now.
В итоге получается, что по одному кабелю идёт зарядка (хоть и максимум 0.5А) и транслируется звук. К RPi можно подключить DAC или взять звук с HDMI и подключить в AUX.
3. Кнопки на руле
4. Возможная периферия (датчики температуры и т.п.)
Наверное можно объединить в один пункт. На счёт периферии все понятно, как подключать всякие модули к RPi информации куча. Плох тот факт, что у RPi нет аналогового входа, что осложняет подключение резистивных кнопок, находящихся на руле (ну и может быть каких-либо датчиков, которые Вы захотите подключить). Но есть куча вариантов решения, в том числе готовые модули.
Передавать информацию с этих датчиков оказалось очень просто, учитывая тот факт, что я чуть-чуть умею писать программы, в том числе на Python и Android 
AOA Protocol 2.0 сам умеет запускать нужную программу при подключении телефона к чему либо. Примерно так:
- Подключаем usb-кабелем Android к ЧёрномуЯщику (назовём так).
- ЧёрныйЯщик понимая что к нему что-то прицепилось по USB, посылает пакеты с информацией: название, производитель, версия. И ещё что он хочет принять аудио.
- Если подключенным устройством оказался Android, то он отсылает версию AOA протокола, отдаёт звук (если может), и пытается запустить программу соответствующую этому конкретному ЧёрномуЯщику (так как уже знает название, производителя и версию).
Всё, дело в шляпе. Пишем программку типа моего ненавистного SerialManager’а, получаем и обрабатываем команды.
5. Камера заднего вида
Лично для меня это просто «Смотрите что ещё у меня в машине есть», а все «Ничего себе 
Как такое возможно».
Есть вариант подключения. Принцип такой — при включении камеры релюшки отключают Android от RPi и подключают OTG с Easycap. Более элегантного решения я придумать не смог.
—- Промежуточный итог —-
Мой репозиторий: https://github.com/delletenebre/AndroidCarAudioDock (описание пока что от форкнутого AndroidCarAudioDock)
Программа для android как прототип уже работает.
Кстати, для облегчения подключения заказал такие магнитные адаптеры.
На данный момент это просто эксперимент. Медленно продвигающийся. Возможно, что всё заброшу.
Источник
Воспроизведение музыки через USB для устройств Android
Содержание
Техническая информация
Данная функция воспроизведения музыкальных файлов использует технологию Android™ Open Accessory 2.0 (AOA 2.0).
- Устройство на платформе Android с версией ОС от 4.1 до 7.х
- Некоторые устройства на платформе Android могут не полностью поддерживать AOA 2.0, даже если установлена версия ОС от 4.1 до 7.x.
Основные функциональные возможности:
- Звук через USB. (Цифровой звук)
- Когда аппаратура подсоединена к устройству Android, все аудиоданные будут направляться на USB-аудиоинтерфейс.
- Устройства Android поддерживают только формат данных 44,1 кГц, 16 бит, ИКМ (PCM).
- Канал связи для управления медийными данными
- Команды управления медийными данными (такие как воспроизведение/ пауза, пропуск вперед, пропуск назад, быстрая перемотка вперед, быстрая перемотка назад и др.) могут передаваться с аппаратуры на устройство Android.
- Устройство Android запускает заданный по умолчанию режим с оригинальным приложением «JVC Music Play» для обработки команд управления медийными данными.
- Пользовательский канал связи между устройством Android и аппаратурой
Технология Android Open Accessory (AOA) представлена компанией Google с целью обеспечения связи между разнообразной аппаратурой (такой как аудио-док-станция или другое устройство воспроизведения музыки) и устройствами Android через USB-соединение. После подключения устройства Android к аппаратуре устройство Android рассматривает аппаратуру в качестве стандартного устройства вывода звука и, следовательно, направляет все аудиоданные на аппаратуру.
Источник
Разработка USB-аксессуаров с поддержкой AOA для Android-систем
Garima Gupta, Joshan Abraham
Теперь разработчики могут сделать свои разработки аксессуаров совместимыми с протоколом Android Open Accessory (AOA)
Стремительный рост использования основанных на Android мобильных интернет-устройств, планшетов и других продуктов начался с 2008 года, и сегодня Android-устройства занимают 70% мобильного рынка. Аналогичным образом происходит рост числа и разновидностей USB-устройств, подключаемых к устройствам на базе Android, от простейших аудио док-станций до сложного медицинского оборудования. Разработчики, оглядываясь на этот растущий рынок, должны быть уверены, что их устройства удовлетворяют требованиям протокола Android Open Accessory (AOA).
USB и Android
Взаимодействие через порт USB между устройством на Android и периферийным USB-устройством или аксессуаром должно происходить в соответствии со спецификацией USB. USB – это хост-ориентированный протокол, означающий, что все транзакции инициирует хост, и что на шине он может быть только один. То есть, USB-хост обязательно должен присутствовать среди соединяемых устройств. Таким образом, Android-устройство может сопрягаться с USB- устройством одним из двух различных способов: в режиме USB-хоста (подключенное устройство называется USB-периферией) и в режиме USB-аксессуара (подключенное устройство называется USB-аксессуаром).
 | |
| Рисунок 1. | Android-устройство при подключении к периферии работает в режиме USB-хоста. |
В режиме USB-хоста Android-устройство выступает в роли управляющего узла, подает питание на шину, регистрирует подключенные к нему периферийные USB-устройства. К работающим в этом режиме Android-устройствам обычно подключается такая периферия, как клавиатуры, мыши и игровые контроллеры (Рисунок 1).
Запущенные в режиме USB-хоста Android-устройства, отдавая подключенному устройству ток до 500 мА, истощают свой аккумулятор, особенно в случае прожорливой периферии. К таковой обычно относятся медицинское и диагностическое оборудование, тренажеры, док-станции, портативные торговые терминалы и автомобильные панели с подключением к Android, а также множество других устройств.
Кроме того, некоторые Android-устройства не имеют аппаратного USB-хоста, необходимого для поддержки передачи данных в хост-режиме. Android-устройства, в большинстве своем, имеют конкретный перечень USB-устройств, называемый целевым списком периферии (target peripheral list – TPL), которые они могут поддерживать. В таких случаях устройства, отсутствующие в TPL, нуждаются в передаче данных альтернативным способом.
Режим USB-аксессуара преодолевает ограничения режима USB-хоста за счет того, что в качестве хоста выступает внешнее устройство. Аксессуар подает питание на шину USB и осуществляет обмен данными с Android-устройстом (Рисунок 2).
 | |
| Рисунок 2. | Android-устройство может также работать в режиме USB-аксессуара. |
Android-устройства, которые не могут выступать в качестве USB-хоста, в таком случае могут взаимодействовать с USB-аксессуаром. Такие аксессуары питаются от больших аккумуляторов или от сети.
Эти Android-устройства и аксессуары должны придерживаться протокола AOA, определяющего, как аксессуар обнаруживает и устанавливает соединение с Android-устройством. Предполагается выполнение аксессуаром следующих четырех шагов, определенных спецификацией AOA:
- Ожидание и обнаружение подключенных устройств
- Определение наличия у устройства режима поддержки аксессуара
- Попытка запуска устройства в режиме аксессуара (при необходимости)
- Установление связи с устройством, если оно поддерживает протокол AOA
Поддержка AOA доступна в Android 3.1 и выше, но она также может быть портирована на Android 2.3.4 посредством дополнительной библиотеки. Даже устройства человеко-машинного интерфейса, такие как клавиатура и мышь, которые обычно подключаются в режиме USB-хоста, могут использоваться в режиме USB-аксессуара посредством AOA 2.0.
Различные рекомендации и шаги для добавления возможностей AOA к существующим конструкциям аксессуаров обсуждаются ниже. Они же могут применяться и при разработке новых аксессуаров. Типичная реализация при расширении до поддержки Android потребует добавления USB-хоста к существующему аксессуару и установления интерфейса обмена данными между ним и микроконтроллером (МК) аксессуара (Рисунок 3).
 | |
| Рисунок 3. | Типичная реализация при расширении до поддержки Android потребует добавления USB-хоста к существующему аксессуару и установления интерфейса обмена данными между ним и микроконтроллером аксессуара. |
Первым шагом будет оценка доступных ресурсов МК аксессуара. Два основных момента, на которые следует обратить внимание – это память и коммуникационный блок. Непременным условием использования кода для обмена данными, управления микросхемой хоста и реализации стека протокола AOA является наличие достаточного объема памяти, как RAM, так и флэш. Блок коммуникации может включать шины SPI/UART/I 2 C или линии ввода-вывода общего назначения.
Для осуществления обмена данными с микросхемой USB-хоста требуется протокол передачи данных подобный SPI/UART/I 2 C. Для этих целей системе требуется также аппаратный блок коммуникации, а если таковой отсутствует, программный стек протокола обмена должен быть реализован средствами ПО, что часто называют еще режимом «bit-banging». Выбранные порты ввода-вывода должны быть совместимы с протоколом, необходимым для связи с микросхемой хоста.
К примеру, при реализации программного модуля мастера SPI на микроконтроллере периферийного устройства, вывод, выбранный в качестве SPI_Clock, должен иметь возможность управляться на тактовой частоте, определяемой требованиями пропускной способности. Точно также, аппаратный SPI-мастер на МК аксессуара даст гибкость в организации обмена данными с подчиненным устройством SPI (контроллером USB-хоста). В этом случае, может потребоваться еще один дополнительный вывод порта ввода-вывода общего назначения (GPIO) для запросов прерываний от микросхемы хоста и один GPIO для сигнала Slave_Select подчиненного устройства SPI. При наличии в системе других подчиненных устройств SPI могут использоваться одни и те же линии MOSI, SPI_Clock и MISO.
Следующий шаг – это выбор подходящей микросхемы USB-хоста, соответствующей возможностям МК и обеспечивающей оптимальные характеристики аксессуара. Тут есть три основных фактора: тип микросхемы (программируемая или с фиксированным функционалом), протокол обмена данными микросхемы хоста и желаемая производительность.
Наиболее простым типом микросхем USB-хоста являются микросхемы с механизмом последовательного интерфейса (SIE), которые предоставляют МК аксессуара полный контроль над передачей данный по USB. МК контролирует каждый пакет данных на шине USB. Такая реализация требует больше памяти программ на МК аксессуара, в связи с чем она не рекомендуется при ограниченных ресурсах памяти МК.
Другая разновидность микросхем хоста имеет встроенные микроконтроллеры, которые могут быть запрограммированы на управление пакетами данных USB любым желаемым образом. Такие контроллеры хоста снижают нагрузку на МК аксессуара, уменьшая одновременно затраты памяти и рабочую загрузку МК. Такая микросхема хоста обладает полным встроенным функционалом стека, оставляя МК аксессуара только обмен данными и отправку специальных управляющих команд для общения с Android-устройством.
Например, запрограммировав микросхему хоста, можно послать запрос Get_Descriptor на получение по SPI специального кода от МК аксессуара. Такие микросхемы могут посылать данные как на МК аксессуара, так и на любое другое подчиненное устройство на шине SPI. При разработке новых аксессуаров эти микросхемы можно использовать в автономном режиме, то есть без внешнего управляющего МК.
Оба типа контроллеров хоста предоставляют широкий спектр коммуникационных интерфейсов, таких как SPI, I 2 C, UART, высокоскоростной последовательный (HSS) и параллельный интерфейсы (такие, как интерфейс внешней памяти или интерфейс процессора). Через любой из этих интерфейсов МК может иметь полный контроль над функционированием USB-хоста. Интерфейсы могут также использоваться для обновления прошивок микросхемы хоста.
Наличие таких интерфейсов позволяет гибко выбирать любую скорость обмена данными. Каждый из них может осуществлять обмен, используя от трех (3-проводная коммуникация по SPI) до n линий (для параллельных интерфейсов), в зависимости от возможностей и потребностей. Основываясь на аппаратных ресурсах, доступных в МК аксессуара, мы можем выбрать наилучший протокол обмена данными. Но даже при отсутствии свободных аппаратных ресурсов в МК аксессуара, можно использовать четыре вывода порта общего назначения, а стек SPI реализовать в прошивке.
Еще одним фактором, влияющим на выбор микросхемы хоста, является требование к USB-хосту: должен ли он быть полноскоростным или высокоскоростным. Полноскоростной режим (full-speed, USB 1.1) поддерживает скорость передачи данных до 12 Мбит/с. В высокоскоростном режиме (high-speed) микросхема хоста обеспечивает скорость до 480 Мбит/с, и обычно имеет параллельный интерфейс для обмена данными и управляющей логики, необходимый для достижения высокой пропускной способности. Некоторые высокоскоростные микросхемы хоста также имеют SPI, I 2 C или другие коммуникационные интерфейсы. У отдельных микросхем есть даже программируемый параллельный интерфейс, который, продолжая поддерживать пропускную способность высокоскоростного режима USB, может быть настроен для удовлетворения любых специфических требований сопряжения МК аксессуара.
Обмен данными для аксессуаров с ограниченными ресурсами упрощает программируемый полноскоростной USB хост-контроллер, содержащий высокоскоростной последовательный интерфейс с конфигурируемой скоростью передачи данных, SPI (ведущий/ведомый) и параллельный интерфейс. Кроме того, интерфейс внешней памяти и EEPROM c интерфейсом I 2 C предоставляют ресурс для внешнего хранения кода программы, чем еще больше облегчают добавление поддержки AOA к существующей разработке. Альтернативный вариант хост-контроллера может иметь только прямой порт данных и микропроцессорный интерфейс со стандартными МК.
Следующим шагом после выбора протокола обмена данными и интерфейсного хост-контроллера является реализация логики сопряжения и управления. Как обсуждалось ранее, существует два вида микросхем: с фиксированным функционалом и программируемые. При использовании простых микросхем с заданным функционалом микроконтроллер должен управлять каждым событием, происходящим на шине USB. Даже такие события, как подключение USB-устройства, будут сообщать о себе, вызывая прерывание, либо должны отслеживаться посредством чтения регистров состояния. Для использования простых микросхем с функционалом SIE в код микроконтроллера аксессуара будет необходимо добавить следующие функции:
- Элементарные функции:
чтение регистра, запись в регистр, запись нескольких байт в заданное место (например, запись в FIFO) и чтение байт данных из указанного места (чтение из FIFO). - Функции, использующие элементарные функции для управления работой микросхемы хоста:
инициализация микросхемы хоста, обнаружение подключения устройства, обнаружение отключения устройства, сброс микросхемы, обработка ошибок при их возникновении, команда перевода USB в режим ожидания, команда продолжения работы USB, управление операциями чтения (фазы подготовки, данных и подтверждения), управление операциями записи, за исключением фазы данных, управление операцией записи с фазой данных, обработка входящих (IN) составных данных (метка IN, принятые данные, подтверждение) и аналогичная обработка исходящих (OUT) составных данных (протокол AOA поддерживает обмен данными только между составными узлами). - Функции, использующие описанные выше функции и реализующие функционал уровня протокола:
обнаружение PID_VID, установка интерфейса, получение интерфейса, отправка данных (через составной узел), прием данных и т. д.
Для программируемых микросхем хоста управляющие функции в МК аксессуара могут быть простыми внутренними командами, отправляемыми посредством интерфейса передачи данных.
Заключительным шагом является реализация протокола AOA в аксессуаре. Он, в первую очередь, состоит из четырех основных шагов, определенных в спецификации AOA и упомянутых ранее: ожидание и обнаружение подключенных устройств, оценка поддержки режима аксессуара устройством, попытка, при необходимости, запуска устройства в режиме аксессуара и установление соединения с устройством, если оно поддерживает протокол Android-аксессуара.
Ожидание и обнаружение подключенных устройств
На первом шаге аксессуар должен ожидать события, вызываемого подключением устройства (например, телефона на Android). Подключение устройства отмечается подтяжкой линий D+/D– шины USB. D+ подтягивается к высокому уровню, если подключено устройство в режиме full-speed или high-speed, а в случае низкоскоростного соединения к высокому уровню подтягивается линия D–. Другими словами, вы можете опрашивать состояние линии и ожидать перехода шины в состояние J или K.
Вторым шагом является обеспечение задержки в 100 мс. Как указано в спецификации USB «Это интервал устранения дребезга с минимальной продолжительностью 100 мс, который обеспечивается системным ПО USB. Он гарантирует стабильность электрического и механического подключения перед тем, как ПО предпримет попытку сброса присоединенного устройства. Отсчет интервала начинается, когда системное ПО USB будет оповещено об обнаружении подключения. Интервал сбрасывается в случае отключения. Противодребезговый интервал гарантирует, что питание на устройстве будет стабильно присутствовать в течение не менее чем 100 мс до того, как ему будут отправлены какие-либо запросы».
На третьем шаге микросхема USB-хоста аксессуара инициирует сброс Android-устройства. Под состоянием «сброса» подразумевается переход шины в состояние SE0. В течение этого времени, если на линии D+ обнаружена подтяжка, микросхема полноскоростного хоста должна производить так называемое «чириканье» (chirp sequence) для обнаружения высокоскоростного подключения Android-устройства. Если используется полноскоростной хост, он не будет выдавать «чириканья», и высокоскоростное устройство будет работать в режиме full-speed. Микросхема хоста обычно также следит за выполнением вспомогательных функций USB.
Четвертым шагом после сброса является предоставление подключенному устройству минимального времени восстановления после сброса 10 мс.
Определение наличия поддержки у устройства режима аксессуара
На пятом шаге должен быть послан запрос «Get Device Descriptor» («Получить дескриптор устройства») по адресу «0», а затем при помощи команды «Set Address» («Установить адрес») установлен адрес устройства в любое желаемое значение.
В качестве шестого шага на этот новый адрес посылаются все последующие USB запросы, чтобы убедиться, что устройство по этому адресу доступно. Послатются запросы «Get Device Descriptor» и «Get Configuration» («Получить конфигурацию»). Это необязательный шаг.
На седьмом этапе производится проверка, совпадает ли PID_VID устройства с PID_VID Google. После отправки запроса «Get Device Descriptor» из полученного описания выбираются данные по PID_VID устройства. Идентификатор продукта (PID) и идентификатор разработчика (VID) устройства обычно являются идентификаторами производителя устройства.
Если устройство поддерживает режим AOA и запущено в нем, оно будет отвечать посылкой VID и PID Google (VID==0x18D1 и PID==0x2D00||PID==0x2D01) вместо идентификаторов производителя устройства. Если устройство обнаружено с идентификаторами Google, аксессуар может сделать вывод о том, что найдено Android-устройство, поддерживающее AOA, и он может установить с ним обмен данными. В этом случае нужно пропустить шаги с 8 по 11 и перейти сразу к 12. Необходимо учитывать, что оба PID имеют различный смысл. Если устройство обозначено идентификатором производителя, продолжить с шага 5.
На восьмом шаге проверяется, поддерживает ли подключенное устройство режим AOA. Для этой проверки используется управляющий запрос со значениями, приведенными в Таблице 1.
Источник
