Package com.google.android.exoplayer2

Interface Player

  • All Known Subinterfaces:
    ExoPlayer
    All Known Implementing Classes:
    BasePlayer, CastPlayer, ForwardingPlayer, SimpleBasePlayer, SimpleExoPlayer, StubExoPlayer, StubPlayer
    @Deprecated
public interface Player
    Deprecated.
    com.google.android.exoplayer2 is deprecated. Please migrate to androidx.media3 (which contains the same ExoPlayer code). See the migration guide for more details, including a script to help with the migration.
    A media player interface defining high-level functionality, such as the ability to play, pause, seek and query properties of the currently playing media.

    Player features and usage

    Some important properties of media players that implement this interface are:

    • All methods must be called from a single application thread unless indicated otherwise. Callbacks in registered listeners are called on the same thread.
    • The available functionality can be limited. Player instances provide a set of availabe commands to signal feature support and users of the interface must only call methods if the corresponding Player.Command is available.
    • Users can register Player.Listener callbacks that get informed about state changes.
    • Player instances need to update the visible state immediately after each method call, even if the actual changes are handled on background threads or even other devices. This simplifies the usage for callers of methods as no asynchronous handling needs to be considered.
    • Player instances can provide playlist operations, like 'set', 'add', 'remove', 'move' or 'replace' of MediaItem instances. The player can also support repeat modes and shuffling within this playlist. The player provides a Timeline representing the structure of the playlist and all its items, which can be obtained by calling getCurrentTimeline()
    • Player instances can provide seeking within the currently playing item and to other items, using the various seek... methods.
    • Player instances can provide Tracks defining the currently available and selected tracks, which can be obtained by calling getCurrentTracks(). Users can also modify track selection behavior by setting TrackSelectionParameters with setTrackSelectionParameters(com.google.android.exoplayer2.trackselection.TrackSelectionParameters).
    • Player instances can provide MediaMetadata about the currently playing item, which can be obtained by calling getMediaMetadata().
    • Player instances can provide information about ads in its media structure, for example via isPlayingAd().
    • Player instances can accept different types of video outputs, like SurfaceView or TextureView for video rendering.
    • Player instances can handle playback speed, audio attributes, and audio volume.
    • Player instances can provide information about the playback device, which may be remote, and allow to change the device's volume.

    API stability guarantees

    The majority of the Player interface and its related classes are part of the stable API that guarantees backwards-compatibility for users of the API. Only more advances use cases may need to rely on UnstableApi classes and methods that are subject to incompatible changes or even removal in a future release. Implementors of the Player interface are not covered by these API stability guarantees.

    Player state

    Users can listen to state changes by adding a Player.Listener with addListener(com.google.android.exoplayer2.Player.Listener).

    The main elements of the overall player state are:

    Note that there are no callbacks for normal playback progression, only for transitions between media items and other position discontinuities. Code that needs to monitor playback progress (for example, an UI progress bar) should query the current position in appropriate intervals.

    Implementing the Player interface

    Implementing the Player interface is complex, as the interface includes many convenience methods that need to provide a consistent state and behavior, requires correct handling of listeners and available commands, and expects immediate state changes even if methods are internally handled asynchronously. For this reason, implementations are advised to inherit SimpleBasePlayer that handles all of these complexities and provides a simpler integration point for implementors of the interface.