IssueTracker

Which device? All devices supported in AOSP run either 4.1 or 4.3 at this point.

Device Samsung Galaxy with android 4.0.4

This report applies to an Android-based device, and the issue tracker where you reported it specializes in issues within the Open Source source code of the Android platform.

We are not able to provide support for individual devices. Please report this issue in the support forum for your device, which might be hosted by your device manufacturer or by the operator where you got your device.

Is there more information I could provide that would help to resolve this bug?

We're seeing this happen a lot in the market ANR reports. However, I just tried downloading the same app and haven't yet reproduced this. What version of the Droid X was used when you saw the problem. I'm running 2.3.3.

The Droid X that I have been testing with is running Android 2.2.1 on Verizon network. Is there an OS update for Droid X? An Android Central story [1] implies that there may have been a limited release to some devices April, but it wasn't official.

[1] http://www.androidcentral.com/new-android-233-gingerbread-build-droid-x-reportedly-pushing-over-air

Any idea on how to work with this issue without freezing the whole UI ?

My situation is MediaRecorder.release(); didn't response, but not every time.

Desire HD in android 2.2 seems still occurred this problem...
But my customer says they didn't face this when using Desire HD in android 2.3.3 .

Did this issue been fixed ?

[Comment deleted]

what my problem is      blow this code :

if (mMediaPlayer!=null) {
mMediaPlayer.stop();
mMediaPlayer.release(); }

it is no effect .

and the music is continue playing .

[Comment deleted]

I can report same issue with SIII and Xoom (with ICS) - this has really been around for a while now...

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

[Comment deleted]

Encountered this issue on Android 4.4. Still exists.

MK808b running 4.2.2
Reproduced (I think) in a different way - might help it get fixed - attempted to play a video which was too large (4K) and got this log message:
01-20 10:23:57.040: E/avcdec(19501): ERROR: not support too large frame!
but mediaplayer reports no errors or information messages, never completes, returns true for isPlaying, and displays nothing on the surface.

If I then call stop or release on the mediaplayer object the call never returns.

P.S. Google search gives me:
No results found for "not support too large frame"
A unique error message! Do I get a cookie?

I believe some kind of bad mobile network condition will often cause the ANR when reset MediaPlayer.

[Comment deleted]

This also happens when using VideoView

Can you explain how it happens in VideoView?

[Comment deleted]

start playing a video in videoview, before play try to play another video, then it is crashing.

I can't believe this bug still exists after literally years! Does anyone have a reliable workaround? I'm just going to try to throw the .release() call into a background task, but then I'm nervous that it will never be completed and the MediaPlayer will leak.

Yeah, it still exists on the all Android versions..
Android team? WTF?

Given this has reports from the last 2 months, it seems odd for this to be marked obsolete?  Is there a fix available on a given version?

Annoying bug. Still exists.

Alex can you report what version of android os you see this with?

I'm still seeing this on a Nexus 5 running (stock) Android 5.1.

For reference, the ANR trace starting with MediaPlayer.release():

"main" prio=5 tid=1 Native
  | group="main" sCount=1 dsCount=0 obj=0x737a8000 self=0xb4827800
  | sysTid=7061 nice=0 cgrp=default sched=0/0 handle=0xb6f60bec
  | state=S schedstat=( 1621291725 1359070640 9931 ) utm=118 stm=44 core=2 HZ=100
  | stack=0xbe0cf000-0xbe0d1000 stackSize=8MB
  | held mutexes=
  kernel: (couldn't read /proc/self/task/7061/stack)
  native: #00 pc 0003adc0  /system/lib/libc.so (__ioctl+8)
  native: #01 pc 000522a5  /system/lib/libc.so (ioctl+14)
  native: #02 pc 0001f38f  /system/lib/libbinder.so (android::IPCThreadState::talkWithDriver(bool)+138)
  native: #03 pc 0001f99b  /system/lib/libbinder.so (android::IPCThreadState::waitForResponse(android::Parcel*, int*)+42)
  native: #04 pc 0001fb3d  /system/lib/libbinder.so (android::IPCThreadState::transact(int, unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+124)
  native: #05 pc 0001ad23  /system/lib/libbinder.so (android::BpBinder::transact(unsigned int, android::Parcel const&, android::Parcel*, unsigned int)+30)
  native: #06 pc 0005dbb7  /system/lib/libmedia.so (???)
  native: #07 pc 0005ab9b  /system/lib/libmedia.so (android::MediaPlayer::disconnect()+46)
  native: #08 pc 0001edbd  /system/lib/libmedia_jni.so (???)
  native: #09 pc 000003df  /data/dalvik-cache/arm/system@framework@boot.oat (Java_android_media_MediaPlayer__1release__+82)
  at android.media.MediaPlayer._release(Native method)
  at android.media.MediaPlayer.release(MediaPlayer.java:1482)

I am also seeing this behavior.  Similar trace to bmoreno.. on various devices running 4.1, 4.2.2, and 5.1.

[Comment deleted]

I am also facing same behavior. Anyone fixed this issue?

Nexus 9, Samsung Galaxy A both both acting the same i.e. media player not releasing. Why does the android team not fix this?

Same problem on Nexus 9 running Android 5.1.1 and Nexus 5 running Android 6.0.

Still the same problem,can android team fix this bug since it exists for years.WTF

This bug still exists.

Test Environment:
Device: HTC Desire X
Api: 16
Network: Good WiFi or through Computer
Case: Streaming any Youtube Video no matter what Quality/Length
Error: Complete UI Freeze or Mediaplayer hangs and that's why VideoView hangs too but the rest of app responses, meaning it is either UI Freeze or MP hangs
Error Reproduction: Load Youtube Video > Play Video > Move Seekbar > Video Buffering > Load new Video > BAM! > see Error above, meaning it only happens when the Video is buffering and you load/play new Video (or Audio) while the buffering is in progress
Mediaplayer Calls before playing a new Video/Audio: Reset (this calls are called on AsyncTask doinbg) = mp.stop > mp.reset > mp.release > mp = null   -   Init (this calls are called on AsyncTask doinbg EXCEPT MP.PREPAREASYNC which is called on AsyncTask Post and EXCEPT MP.START which is called in onPrepared) = mp = new mediaplayer > mp.setwakemode > mp.setalltheListeners > mp.setAudioStreamType (AudioManager.STREAM_MUSIC) > mp.setDataSource (url to video or audio) > mp.prepareAsync > mp.start (which is in the onPrepared)

Description:
I added some logs to my code to see where exactly the UI-Freeze/MP-Hanging occurs: It happens either on mp.stop (which causes UI Freeze (+ANR) and hangs on that method and NO ERROR LOGS AT ALL in my Logcat even if I surround mp.stop with try/catch general Exception and using StrictMode) or mp.reset/mp.release (which causes just MP Hanging but app is responsive) which gives me always a Mediaplayer Error (100, 0). You see, even if mp.stop/mp.reset/mp.release is called on a seperate Thread and surrounded with try/catch, UI-Freeze/MP-Hanging still occurs. Can't prevent it from happening. Either way, this bug is nasty :)

Please fix it.

to the best of my limited understanding of how Android development goes,
this bug will not be fixed .

Android has created new playback APIs in that are available in lollipop and
will not fix bugs on the old APIs, even though millions of devices running
the old OSes still exist.

Since it's not going to be fixed (or doesnt look like it), any work arounds exist to make do?

Thanks!

The word around I used was to make the call on a new thread, and don't put any critical work after the call in that thread, so in the worst case you just have one extra thread overhead.

[Comment deleted]

If you're like me then you may have encountered this behavior for ANOTHER reason unrelated to UI freezes. Some versions of Android (4.1.1 / Jelly Bean) are more aggressive about putting the device to sleep. MediaPlayer may request to stay awake and does so WHILE playing but then when you call reset() or release() they may block indefinitely. The device has gone to sleep! This is because those calls effectively release the WakeLock that the MediaPlayer had requested for playback.

My solution was to create and manage a separate wake lock whenever the player started like so:

PowerManager powerManager = (PowerManager) getSystemService(POWER_SERVICE);
WakeLock wakeLock = powerManager.newWakeLock(PowerManager.PARTIAL_WAKE_LOCK, "MyTag");
wakeLock.acquire();

Then when all songs have finished playing ...

wakeLock.release();

Note, this is a hard issue to test and somewhat rare to run into unless your device is on Airplane Mode and has few apps running (which my test device did).

It's absolutely ridiculous that this bug still exists 7 1/2 years later, with no workaround. If you happen to need to play media in a WebView on older devices, the WebView will handle the MediaPlayer instance itself, giving you no control over it, and no recourse but to tell your users "Yep, sometimes my app will completely freeze on your device. Nothing we can do, tough luck!"

android 4.4 occasional problem

we are planning on sending half a million android 19 devices out to our customers.  We have no choice regarding android version.  MediaPlayer consistently freeezes the main thread if playback is interrupted during a live stream (e.g. camera disconnects from wifi or loses power... the first being a common occurrence).  We do NOT have this problem on Gingerbread.  What is the alternative?  We need to support RTSP.  Why is this bug obsolete?  

I meet this bug 。 how can i do ？ noting？ thanks。

Hi, I managed to get around this issue, by using ExoPlayer (https://github.com/google/ExoPlayer)

İ am issuing this problem even in 2021.:(

So any solution?

İ am issuing this problem even in 2022 :(

Android kitkat 4.4 İ am issuing this problem even in 2023 :(