MediaPlayer instance: stop behaves like a pause

后端 未结 2 1685
忘掉有多难
忘掉有多难 2021-01-13 11:00

I wrote a small music playback control test application. I have a play, pause, stop and rewind button. My issue is that that player.stop(); is behaving the same exact w

相关标签:
2条回答
  • 2021-01-13 11:27

    doesn't the state diagram http://developer.android.com/reference/android/media/MediaPlayer.html states that stop means "stay in stopped state" ?

    Calling stop() stops playback and causes a MediaPlayer in the Started, Paused, Prepared or PlaybackCompleted state to enter the Stopped state.

    Once in the Stopped state, playback cannot be started until prepare() or prepareAsync() are called to set the MediaPlayer object to the Prepared state again. Calling stop() has no effect on a MediaPlayer object that is already in the Stopped state.

    There's no affirmation that stop() should change the CurrentPosition.

    There's no affirmation that calling the prepare() should change the CurrentPosition.

    So, to go to the beginning of the music, you should mannualy set its position.

    But I agree with you. Since the pause() method states it will resume playing from the current position, I'd expect it get back to the beginning when stop() is called.

    And it has some impact when you need to call the prepare()

    For example, the call to prepare() can take a long time to execute, because it might involve fetching and decoding media data.

    so stop() needs to call prepare() that can make it take longer, while pause() has less impact: you can call the start() right after.

    0 讨论(0)
  • 2021-01-13 11:32

    I think this might be a bug, because the API documentation for the MediaPlayer start method suggests the behavior that you expect:

    public void start ()

    Starts or resumes playback. If playback had previously been paused, playback will continue from where it was paused. If playback had been stopped, or never started before, playback will start at the beginning.

    For the time being, explicitly calling seekTo(0) once the player is prepared seems to be a reasonable workaround.

    0 讨论(0)
提交回复
热议问题