Obsolete
Status Update
No update yet.
Comments
do...@gmail.com
Which device? All devices supported in AOSP run either 4.1 or 4.3 at this point.
do...@gmail.com
Device Samsung Galaxy with android 4.0.4
cc...@android.com
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.
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.
bo...@gmail.com
Unfortunately you did not look at the enclosed sample project, as android:hardwareAccelerated="true" *is* indeed present.
The problems are:
- Clicking on the play button has no effect <- I can still reproduce on a 4.0.4 Galaxy Nexus
- Clicking on the Full screen button, crashes <- I can not reproduce the crash on a 4.0.4 Galaxy Nexus, instead the button has no effect, which is also a problem, but not as bad as a crash I guess
Therefore, please re-open this issue.
The problems are:
- Clicking on the play button has no effect <- I can still reproduce on a 4.0.4 Galaxy Nexus
- Clicking on the Full screen button, crashes <- I can not reproduce the crash on a 4.0.4 Galaxy Nexus, instead the button has no effect, which is also a problem, but not as bad as a crash I guess
Therefore, please re-open this issue.
cc...@android.com
My mistake, and sorry about not seeing your second message. I closed this when I was going through several other similar bugs, where video didn't work without HW acceleration.
I'll pass this on to the correct folks internally for fixing in a future release, but in the meantime, you're best bet is unfortunately to use the method of the above HTML5WebView.
We'll try and get it fixed in a future release so that you don't need to do that extra work, but in the meantime I have verified that the HTML5WebView's method works on my devices running 4.1 and 4.2, and you should be relatively safe using that approach for the time being.
I'll pass this on to the correct folks internally for fixing in a future release, but in the meantime, you're best bet is unfortunately to use the method of the above HTML5WebView.
We'll try and get it fixed in a future release so that you don't need to do that extra work, but in the meantime I have verified that the HTML5WebView's method works on my devices running 4.1 and 4.2, and you should be relatively safe using that approach for the time being.
jo...@gmail.com
I have the same problem with playing the video using phonegap.while emulating I am getting the message as attached below.I was trying with this for past two weeks.Kindly help me.
da...@gmail.com
I'm seeing this in WebView as well where the video play controls are non-responsive. The only difference is that the full screen control is also non-responsive so I can't even repro the crash problem. And yes, I have hardware acceleration enabled for the activity that hosts the WebView instance. I am targeting API level 19 and this report is in an API 19 AVD (x86 and ARM). I tried using an AVD based on API level 21 but the repro was exactly the same.
I hooked up Chrome dev tools to my app and was looking at the network requests to see what might be up there. When trying to display the page with the MP4 video on it I see this in the network tab (see attached image).
I was debugging on the server side to see what, if anything, I was doing wrong that might cause the connection to be aborted like that. It seems that the connection is closed on the WebView end after sending the HTTP response header. Here is the header I was sending:
HTTP/1.1 200 OK
Content-Type: video/mp4
Date: Thu, 8 Oct 2015 22:39:25 GMT
Connection: keep-alive
Content-Length: 383631
I see nothing in that header that would tell me there was an issue. Playing around with it it seems that WebView aborts the connection immediately upon receiving this header if the content type is video/mp4. Switching it to something like text/plain allows the header to go through without aborting the connection (though obviously things go south after that since I am NOT sending plain text).
I noticed that the web browser that comes on the AVD image also repos the same problem. Any help or update on this would be appreciated.
I hooked up Chrome dev tools to my app and was looking at the network requests to see what might be up there. When trying to display the page with the MP4 video on it I see this in the network tab (see attached image).
I was debugging on the server side to see what, if anything, I was doing wrong that might cause the connection to be aborted like that. It seems that the connection is closed on the WebView end after sending the HTTP response header. Here is the header I was sending:
HTTP/1.1 200 OK
Content-Type: video/mp4
Date: Thu, 8 Oct 2015 22:39:25 GMT
Connection: keep-alive
Content-Length: 383631
I see nothing in that header that would tell me there was an issue. Playing around with it it seems that WebView aborts the connection immediately upon receiving this header if the content type is video/mp4. Switching it to something like text/plain allows the header to go through without aborting the connection (though obviously things go south after that since I am NOT sending plain text).
I noticed that the web browser that comes on the AVD image also repos the same problem. Any help or update on this would be appreciated.
da...@gmail.com
Enabling hardware acceleration at the application level didn't change the problem either.
sa...@google.com
Thank you for your feedback. We have tried our best to address the issue reported, however our product team has shifted work priority which doesn't include this issue. For now, we will be closing the issue as "Won't Fix (Obsolete)". If this issue still currently exists, we request that you log a new issue along with the latest bug report here: https://goo.gl/TbMiIO and reference this bug for context.
Description
- Load an html file into the WebView that contains a <video> tag
- For instance:
- The Player box appears, but clicking on the play button has no effect.
- Not only that, but clicking on the Full screen button, crashes with the following exception:
11-25 11:42:20.350 E/AndroidRuntime( 468): FATAL EXCEPTION: main
11-25 11:42:20.350 E/AndroidRuntime( 468): java.lang.NullPointerException
11-25 11:42:20.350 E/AndroidRuntime( 468): at android.webkit.HTML5VideoFullScreen.enterFullScreenVideoState(HTML5VideoFullScreen.java:253)
11-25 11:42:20.350 E/AndroidRuntime( 468): at android.webkit.HTML5VideoViewProxy$VideoPlayer.enterFullScreenVideo(HTML5VideoViewProxy.java:161)
11-25 11:42:20.350 E/AndroidRuntime( 468): at android.webkit.HTML5VideoViewProxy.enterFullScreenVideo(HTML5VideoViewProxy.java:667)
11-25 11:42:20.350 E/AndroidRuntime( 468): at android.webkit.WebView$PrivateHandler.handleMessage(WebView.java:8017)
11-25 11:42:20.350 E/AndroidRuntime( 468): at android.os.Handler.dispatchMessage(Handler.java:99)
11-25 11:42:20.350 E/AndroidRuntime( 468): at android.os.Looper.loop(Looper.java:132)
11-25 11:42:20.350 E/AndroidRuntime( 468): at android.app.ActivityThread.main(ActivityThread.java:4157)
11-25 11:42:20.350 E/AndroidRuntime( 468): at java.lang.reflect.Method.invokeNative(Native Method)
11-25 11:42:20.350 E/AndroidRuntime( 468): at java.lang.reflect.Method.invoke(Method.java:491)
11-25 11:42:20.350 E/AndroidRuntime( 468): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:841)
11-25 11:42:20.350 E/AndroidRuntime( 468): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:599)
11-25 11:42:20.350 E/AndroidRuntime( 468): at dalvik.system.NativeStart.main(Native Method)
Attached is a very simple project demonstrating the problem, and you can find the resulting apk here:
After asking a friend to try on a Galaxy Nexus (this cannot be tested in the emulator as video is not supported), it appears this bug still exists in 4.x.
Please also note that I've seen complicated workarounds that may or may not work, for instance here:
-
and here:
- (haven't tried it)
These workaround depend on implementation details that can and will break when the underlying WebView code changes or is customized by specific vendors. Also I think we'll all agree that this should work directly without doing anything special, just like any other html tag.