The player should properly expose audio focus state

Issue description

I’m trying to get AudioFocus behavior: duck (lower volume) on notifications and pause on incoming call (and play after call end). When i look at the code https://github.com/google/ExoPlayer/blob/release-v2/library/core/src/main/java/com/google/android/exoplayer2/audio/AudioFocusManager.java#L419 default ExoPlayer implementation should be working like this (or maybe i don’t understand it well). But unfortunetely - on incoming call volume is down to 0, but playback doesn’t stop.

Interestingly enough. CONTENT_TYPE_SPEECH is not working either. Playback isn’t stopped on both - notifications and incoming call.

Reproduction steps

I set audio attributes like this

setAudioAttributes(AudioAttributes.Builder()
    .setContentType(C.CONTENT_TYPE_MUSIC)
    .setUsage(C.USAGE_MEDIA)
    .build(), true)

In logs i can see that AUDIOFOCUS_LOSS_TRANSIENT was dispatched. It seems like PLAYER_COMMAND_WAIT_FOR_CALLBACK wasn’t handled properly.

D/AudioManager: dispatching onAudioFocusChange(-2) to [e-mail]$AudioFocusListener@d3f1561
D/AudioManager: dispatching onAudioFocusChange(1) to [e-mail]$AudioFocusListener@d3f1561

EDIT: when i digged deeper i found that on SimpleExoPlayer ComponentListener to PlayerCommand is ignoring PLAYER_COMMAND_WAIT_FOR_CALLBACK completely

private void updatePlayWhenReady(
      boolean playWhenReady, @AudioFocusManager.PlayerCommand int playerCommand) {
    player.setPlayWhenReady(
        playWhenReady && playerCommand != AudioFocusManager.PLAYER_COMMAND_DO_NOT_PLAY,
        playerCommand != AudioFocusManager.PLAYER_COMMAND_PLAY_WHEN_READY);
  }

Version of ExoPlayer being used

2.10.3

Device(s) and version(s) of Android being used

Samsung Galaxy S7 Edge, Android 8.0; Huawei Mate 20 lite, Android 8.1; Samsung Galaxy A7 (2018), Android 9

Also emulators of Pixel 2 devices using Android 8, 9 and Q (9+)

[tonihei]

I think this condition needs updating to use isPlaying

Yes indeed. There are some more usages in our code base that should use isPlaying instead of the previous method of determining “is playing”. Will update accordingly.

When paused, mediaController.playbackState.playbackSpeed value is 0.0. Is it really necessary? i used this to calculate totalTime of a song, doing mediaController.metadata.getLong(MediaMetadataCompat.METADATA_KEY_DURATION) / playbackSpeed

That’s actually working as intended. See the documentation here that explicitly says that this method returns 0 when paused. If you’d like to check the user-defined target playback speed, you can access the extra MediaSessionConnector.EXTRAS_SPEED.

[Flyktsodan]

I agree that STATE_WAITING or getting a STATE_PAUSED from MediaSession is very important. Noticed it’s tagged as an “enhancement” but feels more like a critical bugg.

Not only does the UX gets really strange here that the user will see the wrong position in the UI after a call (pausing the player resets it to the correct one). But in our case we also report the position to the backend. Meaning the user can end up in the wrong place next time playback starts because we report what we get from MediaSession.