| 6f62ef32e2dd4e7935f5a2d201ad5f3b78b4a203 |
|
24-May-2012 |
Teng-Hui Zhu <ztenghui@google.com> |
Better support for HTML5 audio loop.
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
/frameworks/base/core/java/android/webkit/HTML5Audio.java
|
| a6c4d8e018e39ff94263ce8f2a31b768104d1bb6 |
|
08-Mar-2012 |
Jonathan Dixon <joth@google.com> |
Rename getWebView() to getWebViewClassic
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
/frameworks/base/core/java/android/webkit/HTML5Audio.java
|
| 3c90952036a5ff7ddb2946c643f1a0bf1c31d53a |
|
28-Feb-2012 |
Jonathan Dixon <joth@google.com> |
Refactor WebView to be a thin proxy class
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
/frameworks/base/core/java/android/webkit/HTML5Audio.java
|
| 0168bef13ff08e100845c7a4b26e37fcc6b5f8af |
|
23-Feb-2012 |
Ben Murdoch <benm@google.com> |
Fix looping HTML5 Audio.
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
/frameworks/base/core/java/android/webkit/HTML5Audio.java
|
| 0d1d30b330de30e7a1ca64ecc1c2d3cfc20a2f36 |
|
05-Jan-2012 |
Teng-Hui Zhu <ztenghui@google.com> |
getDuration can be only called after prepared.
bug:5816130
Change-Id: I4f264ef612995bc4f7bc3e378893ed9491423fdc
/frameworks/base/core/java/android/webkit/HTML5Audio.java
|
| 817d6d5e8efa30082ce4b31d7da73cee20fc664a |
|
14-Oct-2011 |
Ben Murdoch <benm@google.com> |
Check MediaPlayer state, do not teardown() from UI thread.
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
/frameworks/base/core/java/android/webkit/HTML5Audio.java
|
| 889453b892d46b8ba1a3714e3fb1a4d94c7ea6a4 |
|
07-Oct-2011 |
Michael Kolb <kolby@google.com> |
Handle audio focus in HTML5 audio
Bug: 5416191
Video will follow later
Change-Id: I51da05aa0e3c8c0f33151df84d84a65cb7003080
/frameworks/base/core/java/android/webkit/HTML5Audio.java
|
| 85aa944888089852cf144c18f8fb6869e1a39d32 |
|
28-Sep-2011 |
Steve Block <steveblock@google.com> |
Fix HTML5Audio to call WebView.isPrivateBrowsingEnabled() on the UI thread
Bug: 5384494
Change-Id: I2587cf0e898f67becb9dbc2067fb1b0a6a37e124
/frameworks/base/core/java/android/webkit/HTML5Audio.java
|
| 9a1b3c9c99e5853a655c88ea785e6cf00820bdd6 |
|
12-Aug-2011 |
Kristian Monsen <kristianm@google.com> |
Fix for bug 3429537 Google voice (web version) does not play messages on HC
Sending cookies to the MediaPlayer
Depends on external/webkit CL: https://android-git.corp.google.com/g/#/c/128457/
Change-Id: Ic4929a73eb6eb857a21fe7e745ae15e92420d3d8
/frameworks/base/core/java/android/webkit/HTML5Audio.java
|
| 35381518d0511d1860adea0183f425cdfb4245d4 |
|
28-Feb-2011 |
Ben Murdoch <benm@google.com> |
Don't try to output really long URLs HTML5Audio exception handler.
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
/frameworks/base/core/java/android/webkit/HTML5Audio.java
|
| 9059f44feedbbde4f486c9448b4818ba54f50538 |
|
09-Dec-2010 |
Ben Murdoch <benm@google.com> |
Make audio tag cope with live streams
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
/frameworks/base/core/java/android/webkit/HTML5Audio.java
|
| 4b71913ea717da4cca55cc2f91a7c16491d7ff89 |
|
08-Feb-2010 |
Nicolas Roard <nicolas@android.com> |
Add the HTML5Audio class, to support the audio tag.
The corresponding webkit C++ CL is https://android-git.corp.google.com/g/#change,41405
Change-Id: Ia4169c353cde8cd8ee5786b874ff466897e3553e
/frameworks/base/core/java/android/webkit/HTML5Audio.java
|