Fixed
Status Update
No update yet.
Comments
[Deleted User] <[Deleted User]>
Here's a really detailed StackOverflow answer that seems to point out some things to look at in relation to this behaviour:
http://stackoverflow.com/a/14293528/238753
en...@google.com
ma...@google.com
ma...@google.com
Thank you for your feedback. We assure you that we are doing our best to address the issue reported, however our product team has shifted work priority that doesn't include this issue. For now, we will be closing the issue as won't fix obsolete. If this issue currently still exists, we request that you log a new issue along with latest bug report here https://goo.gl/TbMiIO .
ma...@google.com
Tested and confirmed that this bug affects Android 4.4 - 5.1 but was fixed in Android 6.0.
I've attached an updated sample project since the original one needed some tweaks to get it building.
I've attached an updated sample project since the original one needed some tweaks to get it building.
us...@gmail.com
Alex's work around will work, until... if the video decoder says the video has an encoding problem. VideoView tries to pop up a AlertDialog using application context. Than a crash happens.
The only work around I can think is to keep creating video view using activity context, and in activity.onDestroy, set AudioManager's mContext to application context using reflection.
Note: have to get the AudioManager using activity.getSystemService(Context.AUDIO_SERVICE) rather than activity.getApplicationContext.getSystemService(Context.AUDIO_SERVICE), since AudioManager is an member variable of Context (you will get wrong instance of AudioManager if you get it from application context).
At last, you may wonder why a member variable (AudioManager) is preventing the class (Activity) to being garbage collected. From the memory analyzer, it shows AudioManager is owned by native stack. So AudioManager somehow did not clean itself properly.
The only work around I can think is to keep creating video view using activity context, and in activity.onDestroy, set AudioManager's mContext to application context using reflection.
Note: have to get the AudioManager using activity.getSystemService(Context.AUDIO_SERVICE) rather than activity.getApplicationContext.getSystemService(Context.AUDIO_SERVICE), since AudioManager is an member variable of Context (you will get wrong instance of AudioManager if you get it from application context).
At last, you may wonder why a member variable (AudioManager) is preventing the class (Activity) to being garbage collected. From the memory analyzer, it shows AudioManager is owned by native stack. So AudioManager somehow did not clean itself properly.
ak...@gmail.com
Another caveat for those using Alex's workaround: Using `this.getApplication()` instead of `this` for the context seems to cause crashes.
See:http://stackoverflow.com/questions/5796611/
See:
ak...@gmail.com
Oddly enough these crashes don't occur on devices with Lollipop (and presumably above).
[Deleted User] <[Deleted User]>
would disabling alerts via setting error listener on videoview and returning true fix the crashes?
ab...@gmail.com
[Comment deleted]
Description
When an Activity has a VideoView and has called videoView.setVideoUri(), then that Activity will never be GC'ed.
1) Launch an activity which contains one videoView and calls its method setVideoUri() with a valid Uri
2) Run the command:
adb shell dumpsys meminfo
the current Activity count is x
3) Exit the activity
4) Run the command
adb shell dumpsys meminfo
Expected:
the current Activity count is x-1
Actual
the current Activity count is x
This Activity count will keep incrementing each time you open the Activity...
Repeat the previous step after commenting out the call to setVideoUri => you get the expected behaviour.
The root cause if very likely in the AudioManager, which is described (including its workaround) here:
Unfortunately, I can't think of any workaround when using a VideoView in an Activity.