Начиная с 27 марта 2025 г. мы рекомендуем использовать android-latest-release вместо aosp-main для создания и участия в AOSP. Дополнительные сведения см. в разделе Изменения в AOSP .

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

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

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

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