Эта страница переведена с помощью Cloud Translation API.

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

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

Звуковое управление фокусом
Управление громкостью звука и отключением звука
Управление приглушением звука

Архитектура сервиса автомобильного плагина

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

Автосервис запускает OEM автосервис, находя компонент, определенный в config_oemCarService . Если конфигурация пуста, служба 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 .

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

Автоаудиосервис с OEM-архитектурой обслуживания

В AAOS служба автозвука управляет следующими действиями:

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

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

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

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

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

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

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

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

Определения услуг OEM-автозвука

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 в основном используется для информирования службы OEM об изменениях фокуса, которые могут повлиять на поведение службы автомобильной аудиосистемы OEM.

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

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

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

Навигация
Вызов
Музыка
Объявление
Голосовая команда
Вызов звонка
Системный звук
Безопасность
Тревога
Уведомление
Статус автомобиля
Чрезвычайная ситуация

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

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

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

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

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

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

OEM-сервис громкости автомобильного аудио имеет единственный метод, который принимает 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 о том, какие аудиоустройства следует приглушать. Когда фокус меняется, все активные держатели фокуса оцениваются, чтобы определить, какие из них следует пригнуть, на основе этого набора правил статического прикрытия:

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

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

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

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

Атрибут Audio в настоящее время скрыт:
- В списке, продолжает уклоняться
- Нет в списке, пригибание отключено
Атрибут Audio в настоящее время не скрыт:
- В списке, уклонился
- Нет в списке, пригибание отключено

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

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

Последовательность начинается, когда приложение запрашивает управление фокусом звука через общедоступные 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. OEM-производители могут вносить изменения в соответствии со своими потребностями. Для отладки используйте конфигурацию 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 для OEM-сервиса:

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 указывает, что она не готова.