Во время воспроизведения аудио входящий звонок прерывает звук приложения. Как проверить корректную обработку такого прерывания?
Проверяйте не только факт остановки звука, но и реакцию приложения на событие изменения аудиодоступа: оно должно выполнить согласованную с продуктом политику — поставить воспроизведение на паузу, приглушить его или завершить, а после звонка корректно восстановить состояние. На iOS это проверяют через события прерывания аудиосессии, на Android — через обработку потери аудиофокуса.
Тест должен подтвердить отсутствие самопроизвольного наложения звука на звонок, корректное обновление элементов управления и предсказуемое поведение после завершения вызова. Ожидаемый результат нужно заранее определить для каждого типа контента: музыка, подкаст, видео или короткий звук могут иметь разную политику восстановления.
Мобильная ОС управляет общим аудиоресурсом устройства: его одновременно могут потребовать телефонный вызов, навигация, будильник, другой медиаплеер или системное уведомление. Поэтому приложение не должно считать аудиовыход полностью принадлежащим ему.
В iOS для этого используется модель аудиосессии с прерываниями, а в Android — модель аудиофокуса. Эти механизмы появились как способ согласовать конкурирующие источники звука при ограниченных ресурсах устройства и многозадачности.
Если приложение игнорирует прерывание, звук может продолжаться во время разговора, восстановиться поверх другого приложения или остаться в состоянии «воспроизведение» при фактической паузе. Пользователь также может потерять позицию в треке либо получить неверное состояние кнопки «Пауза».
Проверка только входящего звонка недостаточна: важны начало прерывания, его завершение, блокировка экрана и повторное открытие приложения. Ошибка часто проявляется только при переходе между состояниями, когда ОС временно отзывает аудиоресурс, а затем возвращает его.
Сначала зафиксируйте ожидаемую политику. Например, при входящем звонке медиаконтент ставится на паузу, текущая позиция сохраняется, после завершения звонка автоматически возобновляется только ранее активное воспроизведение, а звук, уже остановленный пользователем, не запускается снова.
Затем выполните контролируемый сценарий на физических устройствах iOS и Android:
На iOS приложение должно реагировать на начало и окончание прерывания аудиосессии. Само окончание прерывания не означает безусловное право немедленно продолжать звук: приложение должно учитывать состояние сессии и собственное прежнее состояние воспроизведения.
На Android проверяют получение изменений аудиофокуса. Важен тип потери фокуса: временная потеря может требовать паузы или приглушения, постоянная — остановки и освобождения ресурсов. Реакция должна быть идемпотентной: несколько близких событий не должны приводить к повторному запуску, скачку громкости или потере позиции.
Следует разделять системное прерывание и обычную ошибку проигрывателя. Для этого сопоставляют момент изменения звука с событием ОС, проверяют логи переходов состояния и воспроизводят сценарий с другим аудиоприложением. Если звук прекращается без события прерывания, вероятнее проблема проигрывателя, маршрутизации или аудиосессии, а не обработки звонка.
Ограничение теста: поведение может зависеть от версии ОС, производителя Android-устройства, типа аудиовыхода и настроек звонков. Поэтому результат нельзя обобщать по одному эмулятору; ключевые сценарии нужно проверить на физических устройствах разных версий ОС.
В приложении для подкастов после завершения звонка воспроизведение иногда начиналось заново, даже если пользователь поставил его на паузу до звонка. Рассматривались три варианта: полностью останавливать проигрыватель при любом прерывании, всегда автоматически возобновлять звук или сохранять состояние, существовавшее непосредственно перед прерыванием.
Полная остановка была простой, но ухудшала пользовательский опыт и усложняла восстановление позиции. Безусловное возобновление было удобным для активного подкаста, но могло неожиданно включить звук после ручной паузы. Выбрали третий вариант: сохранять признак активного воспроизведения до прерывания, ставить звук на паузу при потере аудиоресурса и возобновлять его только при подтверждённом возврате ресурса, если до звонка воспроизведение действительно шло.
Дополнительно проверили звонок при заблокированном экране и повторное короткое прерывание. В результате исчезли самопроизвольные запуски, а позиция подкаста сохранялась независимо от платформы.
Нет. Наиболее важна пара переходов: начало прерывания и возврат аудиоресурса. После завершения звонка приложение может не получить ресурс сразу, получить его с изменённым маршрутом или не получить вовсе. Поэтому нужно проверять промежуточное состояние, повторное получение фокуса и отсутствие преждевременного возобновления.
Потеря фокуса не доказывает, что пользователь хочет продолжить прослушивание. Он мог вручную остановить контент во время звонка, закрыть экран или переключиться на другой источник звука. Корректнее сохранять состояние до прерывания и возобновлять только то воспроизведение, которое было активно перед событием, если продуктовая политика допускает автоматическое продолжение.
Эмулятор не всегда воспроизводит реальные телефонные прерывания, аппаратные аудиомаршруты и особенности производителя. На физическом устройстве можно проверить звонок при заблокированном экране, переключение между динамиком, гарнитурой или Bluetooth, а также конкуренцию с другим аудиоприложением. Эмулятор полезен для базовой автоматизации, но не заменяет физические устройства для проверки аудиосценариев.