title: Android MediaPlayer behavior (event order guarantees)
body: <p>Assume two threads: my thread, and the MediaPlayer thread (which sends
  messages to me through a looper). My game thread reacts to user input:
  if the user pauses gameplay, I call MediaPlayer.pause() as well.</p>
  
  <p>Consider the following order of events:</p>
  
  <ol>
  <li>A MediaPlayer audio stream reaches its end, so it enqueues an
  OnCompletion message to me</li>
  <li>My thread: MediaPlayer.pause() called due to user action</li>
  <li>I receive the OnCompletion call (too late, pause() was already
  called above)</li>
  </ol>
  
  <p>The problem with this is that MediaPlayer.pause() is only allowed in
  PAUSED and STARTED state, but due to Step 1, the MediaPlayer will
  already be in PlaybackCompleted state when pause() is called. I see
  two solutions:</p>
  
  <ol>
  <li>Catching exception</li>
  <li>asking MediaPlayer.isPlaying() before calling pause()</li>
  </ol>
  
  <p>But the second solution has a problem in the following scenario:</p>
  
  <ol>
  <li>Game started, MediaPlayer.start() called, but mediaplayer state is
  <em>not yet</em> STARTED</li>
  <li>User leaves gameplay, calling the code: if(isPlaying()) pause();</li>
  <li>MediaPlayer enters STARTED state (now isPlaying would return true,
  but too late)</li>
  </ol>
  
  <p>The problem here is that isPlaying() will still return false (as the
  docs say too), so the MediaPlayer will still start due to step 3.</p>
  
  <p>Is there a solution which is correct and avoids exceptions in both cases? (Or are there any mistakes in my above train of thought?) </p>
  
  <hr>
  
  <p><strong>Update</strong></p>
  
  <p>Reacting to Geobits' answer (I do it here because I'll quote from Android doc):</p>
  
  <p>Yes, I'm also doing local playback, tested it a lot just like you, and everything looked fine. But the documentation is a bit self-contradicting. The first part (this is OK):</p>
  
  <blockquote>
    <p>Calling start() to resume playback for a paused MediaPlayer object,
    and the resumed playback position is the same as where it was paused.
    When <strong>the call to start() returns, the paused MediaPlayer object goes
    back to the Started state</strong>.</p>
  </blockquote>
  
  <p>And another quote from the same page:</p>
  
  <blockquote>
    <p>Playback can be paused and stopped, and the current playback position
    can be adjusted. Playback can be paused via pause(). When the call to
    pause() returns, the MediaPlayer object enters the Paused state. Note
    that the transition from the Started state to the Paused state <strong>and
    vice versa</strong> happens asynchronously in the player engine. <strong>It may take
    some time before the state is updated in calls to isPlaying()</strong>, and it
    can be a number of seconds in the case of streamed content.</p>
  </blockquote>
  
  <p>This latter one says that also when <em>starting</em> a paused player, the state change may take time ("vice versa"). So far so good, because it only applies to the internal player engine, but then comes the crazy part: <em>"It may take some time before the state is updated in calls to isPlaying()"</em>. This implies that isPlaying() <strong>isn't returning the OBSERVABLE state</strong>, instead it depends on the internal state. This is confusing.</p>