summaryrefslogtreecommitdiff
path: root/core/java/android/webkit/HTML5Audio.java
Commit message (Collapse)AuthorAgeFilesLines
* Delete the old WebView.Torne (Richard Coles)2013-10-151-358/+0
| | | | | | | | | Delete all the Java classes used only by the old WebView implementation, and also sections of common classes that were only needed for the old WebView. Bug: 10427705 Change-Id: I02549a71104b35d86d99058c71f43e054730ec7d
* HTML5Audio should handle content URIztenghui2013-04-081-1/+8
| | | | Change-Id: Ib7ef4ad5fdd5b6b051ae32b0968a9bddef5c65ba
* Audio continue to played even if paused manuallyRoger Chen2013-03-051-11/+18
| | | | | | | | | | | | | | Currently, audio will resume playing after a phone call or notification even if the user had manually paused playback. This patch addresses that by introducing a new player state to distinguish the user pausing playback and the browser losing audio focus for some other reason. Audio will only resume if the browser temporarily lost audio focus and not when the user has manually paused playback. Change-Id: I9e8beaedb0fcc5afe920068297ed9c387eab2ac8 Signed-off-by: Roger Chen <cxr514033970@gmail.com>
* Better support for HTML5 audio loop.Teng-Hui Zhu2012-05-241-13/+15
| | | | | | | | | | | | | | | | Loop is trigger by a seek to 0 when ended on native side but there is no play call. So on java side, we detect this and call into native side to trigger a play after completion. This fixed the UI problem and keep in sync with the native mode. Beyond that, we don't need to reload for looping and we don't have the seek to play artifacts. bug:5461143 webkit change: https://android-git.corp.google.com/g/#/c/193750/ Change-Id: I779f3e1fbc789832a1a99d1f17823db6b57b35df
* Rename getWebView() to getWebViewClassicJonathan Dixon2012-03-211-1/+1
| | | | | | | | | | | | Interdepends on https://android-git.corp.google.com/g/170037 Tidys up a TODO from my webview proxy patch. This allows me to re-introduce getWebView(), but now returning the actual WebView instance which is needed by my upcoming change to WebKit linked above. Also moves sendPluginDrawMsg() to WebViewCore for convenience in the MediaTexture code that calls this. Change-Id: I57b72504a792de58d15f386abf4a9d821449ab0a
* Refactor WebView to be a thin proxy classJonathan Dixon2012-03-021-1/+1
| | | | | | | | | | | | | | | | Splits interface and implementation; all client calls are forwarded to an abstract WebViewProvider interface, and the existing implementation moved into the WebViewClassic implementor of this interface. Originally taken from a snapshot from the development branch, by: git diff HEAD 9a4c328a54cc05e5 | git apply - but then rebased to keep up to date with master Interdepends on webkit and Browser changes: https://android-git.corp.google.com/g/158979 https://android-git.corp.google.com/g/167911 Change-Id: I91403f32654ff308934e95c832d17b292a7d9b2e
* Fix looping HTML5 Audio.Ben Murdoch2012-02-241-3/+19
| | | | | | | | | | | | | | | | | | | When an <audio> tag has the loop=true attribute, Webkit tells us to seek back to 0 before we are supposed to have stopped the stream. But by the time that the message gets back to the Android MediaPlayer java side, it's already stopped. So after seeking, we play() again if the player is in the COMPLETED state. Change the code to do this and handle the case that we call play on a COMPLETED stream (resetting internal state, etc). Note that this has the side effect that we will start playing the stream after any seek on a COMPLETED stream - e.g. dragging the slider thumb on the progress track after the stream is finished. Bug: 5461143 Change-Id: I6cf4d46d9a1985caf9f9ab85dbcf65535c8dcd77
* getDuration can be only called after prepared.Teng-Hui Zhu2012-01-041-1/+5
| | | | | bug:5816130 Change-Id: I4f264ef612995bc4f7bc3e378893ed9491423fdc
* Check MediaPlayer state, do not teardown() from UI thread.Ben Murdoch2011-10-141-14/+19
| | | | | | | | | | | | | The teardown() function should only be called from the native thread when WebCore is happy for us to release the media player. When we lose audio focus, simply stop playback. Also be careful not to check the playing state of the MediaPlayer if we are in the error state. Bug: 5461143 Change-Id: Iba03bdad5c39b104b3071129430d7ef2177e9358
* Handle audio focus in HTML5 audioMichael Kolb2011-10-071-8/+46
| | | | | | | | Bug: 5416191 Video will follow later Change-Id: I51da05aa0e3c8c0f33151df84d84a65cb7003080
* Fix HTML5Audio to call WebView.isPrivateBrowsingEnabled() on the UI threadSteve Block2011-09-281-5/+41
| | | | | Bug: 5384494 Change-Id: I2587cf0e898f67becb9dbc2067fb1b0a6a37e124
* Fix for bug 3429537 Google voice (web version) does not play messages on HCKristian Monsen2011-08-161-2/+20
| | | | | | | | Sending cookies to the MediaPlayer Depends on external/webkit CL: https://android-git.corp.google.com/g/#/c/128457/ Change-Id: Ic4929a73eb6eb857a21fe7e745ae15e92420d3d8
* Don't try to output really long URLs HTML5Audio exception handler.Ben Murdoch2011-02-281-1/+2
| | | | | | | | | If we catch an IOException in HTML5Audio.setDataSource, do not try and output the URL if it's really long as this will likely lead to an OOM exception being thrown. Bug: 3486963 Change-Id: If10a489b03ec215e078490a81910b02d68190612
* Make audio tag cope with live streamsBen Murdoch2010-12-091-1/+1
| | | | | | | | | Live streams seem to take a little while to initialize, so it's feasible that we might get a play request before transitioned to the PREPARED state. In that case track that we should start playing when onPrepare completes. Change-Id: I66ed0ef3a0905a1c5d4206fb2e7bbcc05a593fc7
* Add the HTML5Audio class, to support the audio tag.Nicolas Roard2010-05-071-0/+224
The corresponding webkit C++ CL is https://android-git.corp.google.com/g/#change,41405 Change-Id: Ia4169c353cde8cd8ee5786b874ff466897e3553e
generated by cgit v1.2.3 (git 2.25.1) at 2026-01-10 07:08:41 +0000