When a user performs a configuration change while watching a video, e.g. an orientation change, the best user experience is for the video to seamlessly transition from that old configuration to the new one. By that I mean the video should not have to reload and re-buffer any content that would otherwise have continued to play without the configuration change taking place.

Additionally when a user backgrounds an app currently playing a video, e.g. by hitting the home or recents key, that video should stop playing. When the user returns to the app, the video should resume the state that it had before being backgrounded.

When using ExoPlayer to host your videos neither of these experiences are done for you out of the box:

A configuration change destroys and then recreates your Activity/Fragment and with it any ExoPlayer instance they are composed of. That means no seamless transition across configuration changes — the content has to be reconstructed and re-buffered.

Backgrounding an app that had an ExoPlayer instance playing content will actually not stop it from continuing to play in the background.

The official ExoPlayer demo app solves the configuration change problem by declaring in its manifest that the Activity which hosts the ExoPlayer instance will handle configuration changes. The line looks like this:

android:configChanges=”keyboard|keyboardHidden|orientation|screenSize|screenLayout|smallestScreenSize|uiMode”

This is an undesirable solution for several reasons — you can read about why, here.

To handle the starting/stopping of an ExoPlayer instance when an app goes into the background, the demo app taps into Activity’s lifecycle methods to purge and reload the ExoPlayer resource. This is fine, but adds a fair amount of bloat to your UI components (i.e. Activity/Fragment) which ideally wouldn’t be there.