MediaPlayer instance: stop behaves like a pause

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 way as player.pause(); I am calling player.prepare() right after player.stop() so that i can have the player instance ready for start() operation.

I do not see any errors [IOexceptions or IllegalStateExceptions] being raised while calling the prepare() after i do a stop(). Also, i am not calling any seekTo(0) after stop(). So, i am not setting the position back to the beginning of the song.

I am using a Nexus Google One phone running 2.3.4.

Any idea if i am doing 开发者_运维知识库something stupid or if what i am observing is actually how the state machine was built.

TIA.

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.

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.