In "initializePlayer", the player should be prepared before setting the playback state values

[rabyunghwa]

In initializePlayer:

private void initializePlayer() {
    [...]
    player.setPlayWhenReady(playWhenReady);
    player.seekTo(currentWindow, playbackPosition);
    player.prepare(mediaSource, false, false);
}

the player should be prepared before setting the playback position and playWhenReady state values.

[dturner]

Thanks for filing this. Are you seeing unexpected behaviour in the codelab because of preparing the player after setting state?

The reason I ask is because the method signature for prepare is

public void prepare(MediaSource mediaSource,
                    boolean resetPosition,
                    boolean resetState)

Both resetPosition and resetState are set to false so any player state shouldn't be reset by the prepare operation.

[rabyunghwa]

Hello! It seems that after the device is rotated, the player's playback state cannot be properly restored if the player is prepared after the playback state values are set.

[dturner]

I tested it on a Pixel 2 running Android 11 beta 2 and the playback position and state are preserved between orientation changes:

Is it the position, state or both which aren't preserved for you? Also, what device and Android build are you testing on?

[rabyunghwa]

Hello!

I didn't realize that in the manifest file, android:configChanges="keyboard|keyboardHidden|orientation|screenSize|screenLayout|smallestScreenSize|uiMode" was set.

Well, if the app process was shut down due to resource constraints, then the player state wouldn't be properly restored (Nexus 5X, API 29):

Sometimes it wouldn't work even if I saved the values in onSaveInstanceState. Sometimes it would work, though. Not sure if this is a platform bug or ExoPlayer-specific issue.

[dturner]

Thanks for the info.

Well, if the app process was shut down due to resource constraints, then the player state wouldn't be properly restored

Yes, that's true but I would assume that's because the fields (playWhenReady etc) would be reinitialized after the Activity is recreated.

I still don't understand how the ordering of prepare changes that behaviour though. Or are you saying it doesn't change the behaviour and that we have a separate issue with onSaveInstanceState?

[rabyunghwa]

Actually I experimented with this several times before and I was able to fix the issue by changing the ordering. I'll follow up with a working sample that can demonstrate this.

[rabyunghwa]

Hello!

Here is the sample project.

There seems to be a platform bug of the passed in savedInstanceState bundle being null for the first process shutdown after app launch (which is another issue). Anyways, afterwards, the player's playback state just wouldn't be restored if the player was prepared after setting the state values, as shown in the video below:

And the issue can be resolved by changing the ordering, as shown in the video below:

[dturner]

In your PlayerFragment you have the line: player.prepare(mediaSource,true, true); which will reset both playback position and state.

In the codelab this line is player.prepare(mediaSource, false, false);

Could that account for the behaviour you're seeing?

[rabyunghwa]

Missed that! Thanks! Regarding that platform bug, where can I seek help?

[dturner]

I'm pleased that you found the source of your problem. In future, please ensure that any issues are reproducible in the codelab rather than your own project.

For Android platform related issues you can file bugs here. I'd suggest using the "Framework" component for the issue you describe.