Новые службы плагинов OEM-автомобилей в Android 14 позволяют настраивать некоторые компоненты автомобиля. Для аудио в частности введены три новых службы плагинов, которые позволяют OEM-производителям гибко настраивать управление аудио на устройствах AAOS:
- Управление аудиофокусом
- Управление громкостью звука и отключением звука
- Управление приглушением звука
Архитектура сервиса автомобильного плагина
На рисунке ниже представлен обзор услуг по обслуживанию автомобилей и их связь с обслуживанием автомобилей OEM. Подобно процессам приложений и процессу обслуживания автомобилей, процесс обслуживания автомобилей OEM занимает свое собственное пространство процесса.
Car service запускает OEM car service, находя компонент, определенный в config_oemCarService . Если конфигурация пуста, OEM service не существует и служба не запускается. Компонент должен расширять OemCarService . Car audio service должен перезаписать API для получения OEM car audio service:
public final class OemCarServiceImp extends OemCarService {
@Override
public OemCarAudioFocusService getOemAudioFocusService();
@Override
public OemCarAudioDuckingService getOemAudioDuckingService();
@Override
public OemCarAudioVolumeService getOemAudioVolumeService();
}
Например , см. эталонное тестовое приложение, определенное в packages/services/Car/tests/OemCarServiceTestApp .
Несмотря на то, что служба запущена службой car, она не наследует автоматически разрешения, доступные службе car audio. Таким образом, любые разрешения, требуемые службами 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. Это может повлиять на способность службы автомобильной аудиосистемы 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-сервиса автомобильного аудио.
Руководство по оценке фокуса
В AAOS аудиофокус используется для управления воспроизведением звука и определения того, какое приложение должно придерживаться, чтобы обеспечить пользователю оптимальный опыт. Таким образом, служба плагина 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, сравнивается с текущим состоянием звука:
Атрибут аудио в настоящее время отключен:
- В списке, продолжает игнорироваться
- Нет в списке, пригнувшись, отключено
Атрибут аудио в настоящее время не приглушается:
- В списке, нырнул
- Нет в списке, пригнувшись, отключено
Затем служба автомобильного аудио определяет, к каким аудиовыходным устройствам относятся аудиоатрибуты, и добавляет их в список приглушаемых аудиовыходных устройств или список неприглушаемых аудиоустройств соответственно. В конечном итоге это отправляется в AudioControl HAL для выполнения требуемого приглушения на аппаратном уровне.
На рисунке ниже показана упрощенная схема последовательности управления приглушением звука для запроса фокуса при использовании службы приглушения OEM:
Последовательность начинается, когда приложение запрашивает Manage audio focus через API публичного менеджера аудио. Запрос пересылается в службу автомобильного аудио для определения результатов. Когда принимается решение о фокусе аудио, служба автомобильного аудио оценивает приглушение звука, вызывая OemCarAudioDuckingService , чтобы оценить, какие атрибуты звука следует приглушать. После возврата результатов из API evaluateAttributesToDuck вычисляются аудиоустройства для приглушения, и, наконец, информация отправляется в AudioControl для применения приглушения к аудиооборудованию.
Реализация эталонного сервиса OEM-автозвука
AAOS предоставляет эталонную реализацию сервиса OEM car в packages/services/Car/tests/OemCarServiceTestApp , который реализует OemCarService , а также OemCarAudioFocusService , OemCarAudioDuckingService и OemCarAudioVolumeService . Для последнего каждый сервис использует XML-файл для загрузки статического поведения. Например, OemCarAudioFocusServiceImp загружает oem_focus_config.xml , который содержит матрицу взаимодействия. Матрица используется для оценки запроса фокуса при вызове evaluateAudioFocusRequest .
Отладка эталонного тестового приложения
Тестовое приложение OEM car service является частью исходного кода 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 — на неготовность.