Regardless of the
Player implementation that you're using, you will likely want
to show UI elements to control playback and the player behavior. Similar to
what happens in the recorder module, we offer a default UI implementation
If you are using
PlayerControls view will be automatically
added to the hierarchy and it is managed by the fragment itself, so there's nothing you should do.
When creating the fragment, you also have the option to pass a more generic layout
resource that contains your overlays. If the view contains a
PlayerControls instance anywhere
in the hierarchy, the player will find it and set it up.
By default, the
overlay() layout contains a single
PlayerControls view. Your overlays can contain
a richer hierarchy or you can leverage a layout file to customize controls with the XML attributes listed below.
You can also pass
null to disable the default controls.
When using other
Player implementations, the controls can be added to your view hierarchy as an
overlay to the player. For example, in case of
PlayerView, you can simply using a frame layout:
At runtime, the controls should be bound to the player using
this is done, the controls class will start listening to player events and update
the interface accordingly.
PlayerControls class offers many APIs to control the controls appearance,
both through XML attributes and programmatically.
|If true, a toast is shown whenever we detect a playback error.|
|If true, a loading spinner is shown when the video is being loaded or buffered.|
|If true, the "next video" and "previous video" buttons are shown. See navigation.|
|If true, the play / pause button will be shown.|
|If true, the mute / unmute button will be shown.|
|If true, the horizontal progress bar will be shown, including a text view with the current time.|
|If true, a text view with the video duration will be shown.|
|Controls the drawable for the play state. Set to @empty to avoid showing a drawable at all.|
|Controls the drawable for the pause state. Set to @empty to avoid showing a drawable at all.|
|Controls the drawable for the mute control. Set to @empty to avoid showing a drawable at all.|
|Controls the drawable for the unmute control. Set to @empty to avoid showing a drawable at all.|
You can also have full control over the UI by passing your own layout resource to
The controls view is able to react to simple touch events and perform player actions accordingly.
You can configure the touch behavior with the
doubleTapAction APIs, both in
XML and programmatically.