Начиная с Android 17, аудиофреймворк накладывает ограничения на фоновые аудиовзаимодействия, включая воспроизведение аудио, запросы аудиофокуса и API изменения громкости, чтобы гарантировать, что эти изменения запускаются пользователем намеренно.
Все приложения, работающие на Android 17 и имеющие такие фоновые аудиовзаимодействия, должны иметь видимое действие или запускать активную службу, не относящуюся к типу SHORT_SERVICE. Это требование действует независимо от того, предназначен ли продукт для API уровня 37.
Если приложение предназначено для Android 17 (уровень API 37), действует дополнительное ограничение. Если приложение работает в фоновом режиме, в нем должна быть запущена активная служба с возможностями while-in-use (WIU). (Активная служба получает возможности WIU, если она запускается в ответ на действие пользователя или когда приложение видно пользователю.) Однако требование к возможностям WIU не применяется, если приложению предоставлено разрешение на операции в точное время и оно вносит изменения в аудиопотоки с атрибутом USAGE_ALARM.
Если приложение пытается вызвать API аудио, когда оно находится в недопустимом жизненном цикле, API воспроизведения аудио и изменения громкости не срабатывают без выдачи исключения или сообщения об ошибке. API аудиофокуса возвращает код ошибки AUDIOFOCUS_REQUEST_FAILED.
Почему мы вносим изменения
Эти ограничения введены, чтобы уменьшить количество ошибок, связанных с непреднамеренным воспроизведением аудио в фоновом режиме. Вот несколько примеров:
- Приложения, воспроизводящие аудио без активной службы, могут быть заморожены. Когда приложение в конечном итоге размораживается, оно неожиданно возобновляет воспроизведение аудио, возможно, через несколько часов.
- Приложения, воспроизводящие аудио без активной службы, сталкивались с различными ограничениями на запуск, что приводило к прерывистому воспроизведению.
- Воспроизведение не связано с жизненным циклом объекта activity, что может привести к утечке сеанса воспроизведения или событий фокуса, которые продолжаются без возможности остановить воспроизведение.
Мы рекомендуем разработчикам протестировать свои приложения и оставить отзыв, если изменение поведения негативно повлияло на какие-либо намеренные сценарии использования аудио. Если вы столкнетесь с проблемами, сообщите о них через систему отслеживания ошибок совместимости приложений с Android 17.
Определите, на какие сценарии использования фонового аудио повлияет изменение
Проверьте, как в вашем приложении реализовано воспроизведение аудио, и определите, должно ли оно работать в фоновом режиме даже при определенных условиях.
Если ваше приложение воспроизводит аудио или использует API для работы с аудио только во время действий, видимых пользователю, в том числе в режиме картинка в картинке, то изменения его не затронут.
Если в вашем приложении есть функция VoIP, например видеовызовы, то оно уже должно соответствовать требованиям к воспроизведению (обычно это достигается за счет использования рекомендованных API для телекоммуникаций), чтобы успешно записывать аудио. Поэтому изменения вряд ли затронут ваше приложение.
Если в вашем приложении воспроизведение аудио продолжается, когда экран выключен или когда действие не видно (чаще всего это происходит в приложениях для потоковой передачи музыки или подкастов), то считается, что в нем есть функция фонового воспроизведения аудио и оно должно соответствовать новым требованиям.
Сценарии, в которых фоновое воспроизведение аудио может быть затронуто
Если ваше приложение не следует модели продолжения аудиовзаимодействия, инициированного, когда приложение было открыто, или в ответ на явный триггер пользователя, скорее всего, функциональность вашего приложения будет подавлена без уведомления.
Например, если приложение запускает активную службу в ответ на BOOT_COMPLETE и пытается взаимодействовать с аудио, это действие будет заблокировано.
Рекомендации по работе с фоновым аудио, которые помогут снизить влияние на эффективность
Используйте компонент
MediaSessionServiceбиблиотеки Jetpack media3, чтобы управлять фоновым воспроизведением аудио.В этом случае на ваше приложение вряд ли повлияет усиление защиты в фоновом режиме, поскольку библиотека помогает управлять жизненным циклом воспроизведения.
Если вы не используете библиотеку media3, вам нужно будет вручную запустить службу переднего плана
mediaPlayback. Если возможно воспроизведение аудио в фоновом режиме, всегда запускайте активную службу, пока приложение находится в активном режиме.Например, если ваше приложение – потоковый видеосервис, который обычно работает только в активном режиме, но позволяет продолжать воспроизведение при выключенном экране, то при срабатывании триггера воспроизведения, инициированного пользователем, приложение все равно должно запустить активную службу.
Это гарантирует, что активная служба будет запущена с возможностями WIU.
Оставлять
mediaPlaybackFGS активным во время временных сбоев продолжительностью менее 10 минут.Если в приложении произошел временный сбой, например проблема с буферизацией из-за сетевой активности, или ожидаемое временное прерывание, например
AUDIOFOCUS_LOSS_TRANSIENT, воспроизведение должно продолжиться. Поэтому служба переднего плана должна оставаться активной.Останавливайте активную службу в конце воспроизведения и возобновляйте его, только если пользователь явно это запросил.
Если получен постоянный сигнал о завершении воспроизведения (например, контент закончился, а автовоспроизведение отключено, возникла ошибка
AUDIOFOCUS_LOSS, поступил сигнал о паузе от UMO или событие мультимедийной клавиши) или произошел неустранимый сбой, приложение должно прекратить аудиовзаимодействие, остановить активную службу и завершить сеанс воспроизведения. Все эти действия соответствуют представлению пользователя о "завершении" желаемого взаимодействия с фоновым аудио. После этого приложение больше не сможет взаимодействовать с аудио в фоновом режиме.Если пользователь возобновит воспроизведение, например в интерфейсе приложения или с помощью кнопки воспроизведения в универсальном медиаобъекте, намерение начать воспроизведение аудио должно вернуться, что приведет к запуску новой активной службы.
Протестируйте воспроизведение аудио с помощью команд adb shell.
Тестирование изменений
Чтобы проверить, соответствует ли приложение требованиям, запустите его на устройстве с Android 17 или более поздней версии (начиная с Beta 3) и выполните следующую команду ADB:
adb shell cmd audio set-enable-hardening <enable|disable|throw>
У этой команды есть следующие параметры:
enable– включить все ограничения по усилению защиты аудио для всех приложений. Требование к активным службам WIU применяется независимо от того, предназначено ли приложение для Android 17 (уровень API 37). Кроме того, требование применяется, даже если приложение вносит изменения в потоки будильника и имеет разрешение на операции в точное время.disable– отключает все ограничения на усиление звука.throw– включает все ограничения по усилению защиты аудио для всех приложений, напримерenable. Кроме того, этот флаг включает явные ошибки, вызываяIllegalStateExceptionдля взаимодействий с громкостью и фокусом. При воспроизведении аудио метод записи постоянно возвращает код ошибки. В режимах воспроизведения без явных записей приложение аварийно завершает работу.
Используйте adb dumpsys audio или logcat, чтобы определить, возникали ли в приложении скрытые сбои из-за применения мер по защите аудио. Если да, то вы увидите запись с префиксом AudioHardening и названием пакета. Если сообщение содержит level: full, значит в приложении запущена активная служба, но у нее нет разрешения на доступ к данным о местоположении во время использования. Если сообщение содержит level: partial, значит в приложении не запущена активная служба.
Что такое служба переднего плана с возможностью использования во время работы
Как правило, активные службы должны запускаться, когда приложение работает в активном режиме, чтобы расширить возможности операций, инициированных пользователем. В некоторых случаях приложениям разрешено запускать активные службы в фоновом режиме. Однако таким активным службам обычно не предоставляются разрешения на использование во время работы.
WIU действует как шлюз безопасности, не позволяя службам переднего плана, запущенным в фоновом режиме, выполнять определенные действия, когда пользователь может не знать о работе приложения. Приложение не сможет получить доступ к конфиденциальным данным, например местоположению, камере или микрофону. Начиная с Android 17, также блокируются API аудио, которым обычно требуется видимый контекст интерфейса.
Вот удобная справка:
- Стандартные активные службы. Службы, запущенные, когда приложение видно или ему предоставлено разрешение на запуск фоновых действий, получают доступ к WIU.
- Службы, запущенные в фоновом режиме (BFSL): большинство не предоставляет доступ к WIU. Основные исключения, при которых предоставляется WIU, – это взаимодействия, связанные с явным намерением пользователя, например нажатия на уведомления, взаимодействия с виджетами или события мультимедийных клавиш на внешнем устройстве.
- Активные службы, запущенные системой. Активные службы получают доступ к WIU, если они запущены делегированием системного сервера (например, из библиотеки Telecom Jetpack) или системными привязками, представляющими повышенное состояние активности для выполнения выделенной функции (например, для
VoiceInteractionService).
Подробнее об ограничениях на запуск активной службы из фонового режима…
Полный список затронутых Audio API
Аудиофункция |
Результат |
Затронутые API |
Воспроизведение аудио |
Воспроизведение без звука Нет исключений, нет сообщений об ошибках от API. |
(NDK) Также могут быть затронуты любые клиентские медиабиблиотеки, управляющие воспроизведением, например media3, Exoplayer и Oboe. |
Запрос аудиофокуса |
Возвраты: Не влияет на воспроизведение аудио в других приложениях, не получает фокус. |
|
API для управления громкостью и режимом звонка |
Не влияет на режим звонка или громкость (вызов метода игнорируется без уведомления). Нет исключений, нет сообщения об ошибке, предоставленного каким-либо API |
|