Сервис плагинов для автомобильной аудиосистемы

В Android 14 появились новые сервисы для автомобильных OEM-производителей, позволяющие настраивать некоторые компоненты автомобиля. В частности, для аудиосистемы представлены три новых сервиса, которые позволяют OEM-производителям гибко настраивать управление звуком на устройствах AAOS:

  • Регулировка фокусировки звука
  • Регулировка громкости звука и отключение звука
  • Управление подавлением звука

Архитектура сервиса подключения автомобиля

На рисунке ниже представлен общий обзор автомобильных сервисов и их взаимосвязи с сервисным обслуживанием автомобилей от производителя. Подобно процессам работы приложений и процессу обслуживания автомобилей, процесс сервисного обслуживания автомобилей от производителя занимает собственное пространство процессов.

изображение

Сервис автомобильной аудиосистемы запускает OEM-сервис, найдя компонент, определенный в config_oemCarService . Если config пуст, OEM-сервис не существует и не запускается. Компонент должен наследовать OemCarService . Сервис автомобильной аудиосистемы должен переопределить API для получения OEM-сервиса автомобильной аудиосистемы:

public final class OemCarServiceImp extends OemCarService {
    @Override
    public OemCarAudioFocusService getOemAudioFocusService();

    @Override
    public OemCarAudioDuckingService getOemAudioDuckingService();

    @Override
    public OemCarAudioVolumeService getOemAudioVolumeService();
}

Например , см. эталонное тестовое приложение, определенное в packages/services/Car/tests/OemCarServiceTestApp .

Несмотря на то, что служба запускается службой Car Service, она не наследует автоматически разрешения, доступные службе Car Audio Service. Поэтому любые разрешения, необходимые службам OEM, должны быть получены с помощью соответствующего механизма. Например, см. packages/services/Car/data/etc/com.android.car.oemcarservice.testapp.xml .

Автосервис по ремонту и обслуживанию автомобильной аудиотехники с архитектурой сервиса от производителя оборудования.

В AAOS управление этими действиями осуществляется службой автомобильной аудиосистемы:

  • Маршрутизация звука
  • Аудиофокус
  • приглушение звука
  • Громкость и отключение звука

До Android 14 это поведение было в значительной степени статичным и могло быть изменено только через настройки, хотя и в очень ограниченном количестве случаев. В Android 14 был представлен механизм взаимодействия автомобильной аудиосистемы с компонентом, определенным производителем оборудования, который управляет:

  • Аудиофокус
  • приглушение звука
  • Громкость и отключение звука

На рисунке ниже показана упрощенная архитектура для сервиса автомобильной аудиосистемы и сервиса OEM-производителя автомобиля. Сервис автомобильной аудиосистемы определяет различные обработчики, которые могут вызывать сервис OEM-производителя автомобильной аудиосистемы для управления поведением звука. Последний происходит только в том случае, если определен соответствующий компонент сервиса OEM-производителя автомобильной аудиосистемы. В противном случае сервис автомобильной аудиосистемы использует поведение по умолчанию.

изображение

Для обеспечения постоянной синхронизации между службой автомобильной аудиосистемы и службой автомобильной аудиосистемы от производителя, при каждом вызове служба автомобильной аудиосистемы передает необходимые части текущего состояния аудиостека службе автомобильной аудиосистемы от производителя. Например, когда служба автомобильной аудиосистемы перехватывает запрос на оценку фокуса аудиосистемы, она передает текущее состояние стека службе автомобильной аудиосистемы от производителя. Текущее состояние включает в себя текущего держателя фокуса и текущих потерявших фокус. Потерявшие фокус — это запросы на фокус, которые все еще являются частью стека, но временно потеряли фокус.

Автозвуковая система должна управлять всей аудиоактивностью в автомобиле. Если автозвуковая система не управляет некоторыми аспектами работы аудио, то информация, предоставляемая автозвуковой системе производителя автомобиля, будет неполной. Например, если производитель автомобиля переопределяет обработку фокусировки звука в автозвуковой системе, регистрируя собственную политику фокусировки звука, то автозвуковая система не сможет предоставить полную информацию автозвуковой системе производителя автомобиля. Это может повлиять на способность автозвуковой системы производителя автомобиля принимать решения, поскольку ей может не хватать информации, невидимой для автозвуковой системы.

Для выполнения действий сервис автомобильной аудиосистемы обращается к сервисам производителя автомобиля. Эти обращения осуществляются между процессами, что требует межпроцессного взаимодействия (IPC). IPC увеличивает задержку каждого обращения. Важно минимизировать задержку в сервисе производителя.

Поскольку вызовы сервиса автомобильной аудиосистемы к сервису производителя оборудования являются блокирующими, сервис производителя оборудования не должен вызывать сервис автомобильной аудиосистемы при прямой оценке API. Вместо этого сервис автомобильной аудиосистемы предоставляет необходимую информацию, так что вызовы между двумя процессами должны осуществляться только в одном направлении.

Определения сервисных требований OEM-производителей автомобильных аудиосистем

Сервис по настройке автомобильной аудиосистемы OEM

Сервис автомобильной аудиосистемы управляет запросами на фокусировку звука от приложений, регистрируя слушатель политики фокусировки звука. Сервис автомобильной аудиосистемы имеет механизм управления поведением фокусировки на основе статической матрицы взаимодействий . Матрица определяет три различных типа взаимодействий:

  • Одновременное взаимодействие. Участники, обладающие фокусом, могут сохранять фокус одновременно.

  • Эксклюзивные взаимодействия. Входящий запрос на фокусировку отнимает фокус у текущего пользователя.

  • Отклонить взаимодействие. Входящий запрос на фокусировку отклонен на основании текущего держателя фокуса.

Хотя этого достаточно для некоторых сценариев использования в автомобильной сфере, это не удовлетворяет всем потребностям во взаимодействии, которые могут различаться в зависимости от требований производителя оборудования. Для решения этой проблемы мы представляем сервис OemCarAudioFocusService :

public interface OEmCarAudioFocusService {
    OemCarAuddioFocusResults evaluateAudioFocusRequest(
        OemCarAudioFocusEvaluationRequest request);
    
    void notifyAudioFocusChange(
        List<AudioFocusEntry> holder,
        List<AudioFocusEntry> losers, int zoneId);
}

API-функция evaluateAudioFocusRequest вызывается из службы автомобильной аудиосистемы всякий раз, когда поступает запрос на определение фокуса на аудиосигнале, который необходимо оценить. Это двусторонний API-интерфейс, который блокируется до получения результатов. Запрос содержит информацию о текущем состоянии аудиостека:

Эта информация может быть использована для сравнения newFocusRequest с текущими держателями фокуса в focusHolders и текущими потерями фокуса в focusLosers . API должен возвращать результаты:

class OemCarAudioFocusResult {
    int audioZoneId;
    int audioFocusEvaluationResults;
    AudioFocusEntry focusResult;
    List<AudioFocusEntry> newLosers;
    List<AudioFocusEntry> newlyBlocked;
}

Здесь содержится информация о фактических результатах оценки в audioFocusEvaluationResults , которая указывает, был ли текущий запрос удовлетворен, отложен или отклонен. Любые изменения в текущем стеке фокуса должны быть зафиксированы в записях newLosers и newlyBlocked в зависимости от характера изменения стека.

В таблице newLosers содержатся записи, которые ранее удерживали фокус, но теперь должны его потерять, навсегда или временно. Записи, потерявшие фокус навсегда, будут удалены из стека фокусировки аудиофайлов, а записи, потерявшие фокус на временной основе, будут перемещены в текущий стек потери фокусировки до тех пор, пока они не восстановят фокус или не будут удалены исходным запросившим фокус. В любом случае, обработчик запросов получит соответствующее сообщение о потере фокуса.

Список newlyBlocked содержит записи, которые ранее находились в списке проигравших фокус, но теперь заблокированы новой записью. Блокировка может быть постоянной или временной. При постоянной блокировке фокуса запись будет удалена из стека, а потеря фокуса будет отправлена ​​слушателям фокуса. При временной потере фокуса запись останется в стеке проигравших фокус, но в ее список блокировщиков будет добавлен новый блокировщик фокуса; потеря фокуса не будет отправлена, так как она была отправлена ​​ранее при первой блокировке. Запрос будет окончательно разблокирован, когда будут удалены все текущие блокировщики, или он будет удален из стека, если фокус будет отменен.

Второй API-интерфейс, notifyAudioFocusChange , является односторонним и вызывается при каждом запросе на изменение фокуса аудиосистемы или при его отмене. Этот API в основном используется для информирования сервиса производителя о изменениях фокуса, которые могут повлиять на работу автомобильной аудиосистемы производителя.

Руководство по проведению фокус-оценки

В AAOS фокусировка на воспроизведении звука используется для управления воспроизведением аудио и определения того, какому приложению следует отдавать приоритет для обеспечения оптимального пользовательского опыта. Таким образом, при обработке запроса на фокусировку на воспроизведении звука сервис плагина OEM должен учитывать следующее:

  • При отсутствии постоянного высокоприоритетного аудиофокуса (например, телефонного звонка, экстренной ситуации или сообщения о безопасности) приложения должны иметь возможность получать аудиофокус либо временно, либо постоянно.

  • В период активного внимания со стороны СМИ приложения, запрашивающие:

    • Функция фокусировки при использовании вызовов должна иметь возможность получать фокус либо одновременно, либо единолично.

    • Функция фокусировки при использовании навигации должна иметь возможность получать фокус либо одновременно, либо единолично.

    • Функция фокусировки на помощнике должна позволять получать фокус либо одновременно, либо исключительно.

  • В то время как активны приложения с высоким приоритетом аудиосвязи (например, телефонный звонок, оповещение о чрезвычайной ситуации или сообщение о безопасности), любой входящий запрос на отложенную аудиосвязь должен быть либо удовлетворен, либо отложен по мере необходимости.

Хотя приведенные выше рекомендации не являются исчерпывающими, они могут помочь гарантировать, что приложения, запрашивающие фокус, смогут его получить, когда нет активных звуков высокого приоритета. Даже при наличии активных звуков высокого приоритета, отложенные запросы на фокус должны учитываться, и приложения должны иметь возможность получить фокус, как только звук высокого приоритета прекратится.

Объем обслуживания автомобилей OEM

Служба автомобильной аудиосистемы управляет событиями нажатия клавиш регулировки громкости, либо отслеживая изменения громкости непосредственно от аудиосистемы, либо от службы автомобильного входа. В каждом случае поведение службы автомобильной аудиосистемы по умолчанию заключается в определении группы регулировки громкости на основе активных аудиоплееров и списка приоритетов контекста воспроизведения звука.

Мы предоставляем два списка приоритетов громкости. Первый список учитывает все аудиоконтексты в указанном порядке. Список представлен в порядке убывания, с наивысшим приоритетом вверху и самым низким внизу. Например, если одновременно активны звук навигации и музыка, то громкость навигации изменяется во время нажатия клавиши регулировки громкости.

  1. Навигация
  2. Вызов
  3. Музыка
  4. Объявление
  5. Голосовая команда
  6. Звонок
  7. Звук системы
  8. Безопасность
  9. Тревога
  10. Уведомление
  11. Состояние транспортного средства
  12. Чрезвычайная ситуация

Для упрощения управления событиями нажатия клавиш регулировки громкости, в системе автомобильной аудиосистемы используется второй приоритетный список контекста звука:

  1. Вызов
  2. СМИ
  3. Объявление
  4. Голосовая команда

Этот список также представлен в порядке убывания. Цель второго списка — позволить изменять более распространенные звуки с помощью событий нажатия клавиш. Редкие, например, звуки меньшей продолжительности, можно изменять только через пользовательский интерфейс настроек звука.

Фактическое значение громкости можно установить с помощью параметра audioVolumeAdjustmentContextsVersion . Значение параметра может быть равно 1 или 2 (по умолчанию — 2 ).

Для повышения гибкости управления громкостью в Android 14 представлена OemCarAudioVolumeService :

public interface OemCarAudioVolumeService {
    OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}

Сервис регулировки громкости автомобильной аудиосистемы от производителя имеет единственный метод, который принимает в качестве входных данных объект volumeAdjustment и объект OemCarAudioVolumeRequest :

class OemCarAudioVolumeRequest {
    int audioZoneId;
    int callState;
    List<AudioAttributes> activePlaybackAttributes;
    List<AudioAttributes> duckedAttributes;
    List<CarVolumeGroupInfo> volumeGroupState;
}

В поле activePlaybackAttributes запроса содержатся активные аудиоатрибуты. Поле duckedAttributes содержит все текущие приглушенные аудиоатрибуты. volumeGroupState содержит текущее состояние группы громкости. Запрос представляет текущее состояние аудиостека и может использоваться для определения того, какую группу громкости следует изменить. Результаты должны быть возвращены в OemCarVolumeChangeInfo :

class OemCarVolumeChangeInfo {
    boolean change;
    CarVolumeGroupInfo volumeGroupChanged;
}

Логическое значение ` change указывает, изменилось ли значение какого-либо параметра громкости; true означает, что изменение произошло и группу громкости следует обновить. Параметр volumeGroupChanged указывает фактическую группу громкости, которую следует изменить. Эта группа должна быть изменена в соответствии с исходным параметром volumeAdjustment , переданным в API. Например, если результаты показывают, что группу громкости навигации следует отключить, то логическое значение будет true , и возвращаемая группа громкости должна быть группой громкости для навигации.

OEM-сервис по тюнингу автомобилей

Сервис автомобильной аудиосистемы управляет приглушением звука, отслеживая изменения фокуса звука и отправляя сигнал в AudioControl HAL о том, какие аудиоустройства следует приглушить. При изменении фокуса оцениваются все активные устройства, чтобы определить, какие из них следует приглушить, на основе следующего набора статических правил приглушения:

  • Звуки экстренных служб заглушают все, кроме звуков вызова.
  • В целях безопасности игнорируется всё, кроме звуков аварийной ситуации.
  • Навигационная система приглушает все звуки, кроме звуков безопасности и аварийных сигналов.
  • Прислушивайтесь ко всем звукам, кроме сигналов безопасности, аварийных сигналов и навигации.
  • Голос уток издает звонкие звуки
  • Музыку и объявления следует игнорировать абсолютно везде.

Эти правила не являются исчерпывающими, и производители автомобилей по-прежнему несут ответственность за определение того, как следует приглушать звуки, основываясь на этих рекомендациях. Производители автомобилей могут более активно контролировать эти рекомендации в зависимости от имеющихся требований. Сервис OemCarDuckingService был представлен в Android 14:

class OemCarAudioDuckingService {
List<AudioAttributes>   evaluateAttributesToDuck(
        OemCarAudioVolumeRequest request);
}

Этот API вызывается из службы автомобильной аудиосистемы при изменении фокуса на аудиосигнале. Он повторно использует объект OemCarAudioVolumeRequest представленный в службе регулировки громкости OEM-автомобиля , и содержит необходимую информацию для принятия решения о том, какие атрибуты следует приглушить. Список атрибутов аудиосигнала, которые следует приглушить, полученный из API, сравнивается с текущим состоянием аудио:

  • В данный момент аудиоатрибут отключен:

    • В списке по-прежнему уклоняются от ответа.
    • Нет в списке, функция подавления звука отключена.
  • В данный момент аудиоатрибут не приглушен:

    • В списке, уклонился
    • Нет в списке, функция подавления звука отключена.

Затем служба автомобильной аудиосистемы определяет, к каким аудиовыходам относятся аудиоатрибуты, и добавляет их в список устройств с подавленным или подавленным звуком соответственно. В конечном итоге эта информация передается в AudioControl HAL для выполнения необходимого подавления звука на аппаратном уровне.

На рисунке ниже представлена ​​упрощенная схема последовательности управления подавлением звука при запросе фокусировки в случае использования сервиса подавления звука от производителя:

изображение

Процесс начинается с запроса на управление фокусом звука через общедоступные API-интерфейсы управления звуком. Запрос перенаправляется в службу автомобильной аудиосистемы для определения результатов. После определения фокуса звука служба автомобильной аудиосистемы оценивает необходимость приглушения звука, вызывая OemCarAudioDuckingService , чтобы определить, какие атрибуты звука следует приглушить. После получения результатов от API evaluateAttributesToDuck вычисляются аудиоустройства, которые следует приглушить, и, наконец, информация отправляется в AudioControl для применения приглушения к аудиооборудованию.

Эталонная реализация сервиса автомобильной аудиосистемы от производителя (OEM)

AAOS предоставляет эталонную реализацию сервиса OEM-автомобилей в packages/services/Car/tests/OemCarServiceTestApp , которая реализует OemCarService , а также OemCarAudioFocusService , OemCarAudioDuckingService и OemCarAudioVolumeService . Для последнего сервиса каждый использует XML-файл для загрузки статического поведения. Например, OemCarAudioFocusServiceImp загружает oem_focus_config.xml , который содержит матрицу взаимодействия. Матрица используется для оценки запроса фокусировки при вызове evaluateAudioFocusRequest .

Отладка тестового приложения (см. пример).

Приложение для тестирования автомобильных сервисов от производителей оригинального оборудования (OEM) является частью исходного кода AOSP. Производители могут вносить изменения в соответствии со своими потребностями. Для отладки используйте конфигурацию config_oemCarService , чтобы включить тестовое приложение.

<!-- This is the component name for the OEM customization service. OEM can choose to implement
this service to customize car service behavior for different policies. If OEMs choose to
implement it, they have to implement a service extending OemCarService exposed by car-lib,
and implement the required component services.
If the component name is invalid, CarService would not connect to any OEM service.
Component name can not be a third party package. It should be pre-installed -->
<string name="config_oemCarService" translatable="false">
com.android.car.oemcarservice.testapp/.OemCarServiceImpl
</string>

Для проверки работоспособности службы OEM-автомобиля используйте команду `car service dump для этой службы:

adb shell dumpsys car_service --oem-service

Результаты могут быть похожи на приведенные ниже:

***CarOemProxyService dump***
  mIsFeatureEnabled: true
  mIsOemServiceBound: true
  mIsOemServiceReady: true
  mIsOemServiceConnected: true
  mInitComplete: true
  OEM_CAR_SERVICE_CONNECTED_TIMEOUT_MS: 5000
  OEM_CAR_SERVICE_READY_TIMEOUT_MS: 5000
  mComponentName: com.android.car.oemcarservice.testapp/.OemCarServiceImpl

Каждое логическое значение в каждом пакете информации dump определяет состояние функции и службы. Например, информация о дампе mIsOemServiceReady указывает, готова ли служба к использованию, где true означает готовность, а false — неготовность.