Request media audio focus when playing a voice message

[hayaksi1]

Content

DefaultAudioFocus groups voice message playback with Element Call and voice message recording, so it asks for audio focus with USAGE_VOICE_COMMUNICATION (and STREAM_VOICE_CALL on the pre-O path). The player that actually renders the audio uses the default media attributes, so what the app declares to the audio policy layer and what it renders disagree.

Audio routing decisions are made from the declared usage. A car head unit that sees a voice-communication focus request switches to its call audio context, which routes the media output away while the player keeps running — the reporter's symptom of playback disappearing mid-message in Android Auto.

Declare USAGE_MEDIA / STREAM_MUSIC for voice message playback, matching what the player renders and what the media viewer already declares. Recording keeps USAGE_VOICE_COMMUNICATION, which is correct: it drives the capture path and the exclusive transient focus request next to it. Element Call is unchanged.

The ducking policy is deliberately left alone, so playback still pauses rather than ducking.

Motivation and context

Part of #6276.

Tests

New libraries/audio/impl/.../DefaultAudioFocusTest.kt asserts the usage each requester ends up declaring, via the shadow audio manager: media for voice message playback and the media viewer, voice communication for recording and Element Call. This required adding the common test dependencies to the module, which had no test source set. Run with ./gradlew :libraries:audio:impl:testDebugUnitTest.

The routing behaviour itself needs a car head unit and could not be reproduced here; the change is argued from the declared-versus-rendered mismatch in the code.

Tested devices

• Physical
• Emulator
• OS version(s):

Checklist

• I am aware of the etiquette.
• This PR was made with the help of AI:
  • Yes. In this case, please request a review by Copilot.
  • No.
• Changes have been tested on an Android device or Android emulator with API 24
• UI change has been tested on both light and dark themes
• Accessibility has been taken into account. See https://github.com/element-hq/element-x-android/blob/develop/CONTRIBUTING.md#accessibility
• Pull request is based on the develop branch
• Pull request title will be used in the release note, it clearly defines what will change for the user
• Pull request includes screenshots or videos if containing UI changes
• You've made a self review of your PR

[github-actions]

Thank you for your contribution! Here are a few things to check in the PR to ensure it's reviewed as quickly as possible:

• If your pull request adds a feature or modifies the UI, this should have an equivalent pull request in the Element X iOS repo unless it only affects an Android-only behaviour or is behind a disabled feature flag, since we need parity in both clients to consider a feature done. It will also need to be approved by our product and design teams before being merged, so it's usually a good idea to discuss the changes in a Github issue first and then start working on them once the approach has been validated.
• Your branch should be based on origin/develop, at least when it was created.
• The title of the PR will be used for release notes, so it needs to describe the change visible to the user.
• The test pass locally running ./gradlew test.
• The code quality check suite pass locally running ./gradlew runQualityChecks.
• If you modified anything related to the UI, including previews, you'll have to run the Record screenshots GH action in your forked repo: that will generate compatible new screenshots. However, given Github Actions limitations, it will prevent the CI from running temporarily, until you upload a new commit after that one. To do so, just pull the latest changes and push an empty commit.