How to play widevine drm content in android webview - android

I want to play widevine drm content in webview android using html5 code.
I tried a lot not succeeded, does widevine not supported in webview?
please give a way to play widevine in webview android and let me know if widevine does not support in widevine and why?
Any help and suggestion would be appreciated.

Unfortunately, the webview shipped with Android devices differs between devices and between Android versions.
There is an excellent overview here:
http://slides.com/html5test/the-android-browser#/42
You can test whether your device supports it by using an open source HTML5 player like Shaka in your webview and trying some of their demo content.
Shakaplayer includes a basic tutorial showing how to include the player in a webpage:
https://shaka-player-demo.appspot.com/docs/api/tutorial-basic-usage.html
You can also use a test app like the HTML5test Webview app - checking the streaming section to make sure MSE and DRM are both ticked:
https://play.google.com/store/apps/details?id=com.html5test.webview&hl=en

Widevine is supported on Android WebView. The following test page, can be loaded on the WebView to confirm that.
There is a drm key in the response:
"drm": {
"com.widevine.alpha": {
"persistentState": false
}
}
However, to ensure that Widevine is properly activated you need to make sure that you are loading the content within a secure context. You can read about secure contexts here. Quoting:
A secure context is a Window or Worker for which certain minimum standards of authentication and confidentiality are met. Many Web APIs and features are accessible only in a secure context. The primary goal of secure contexts is to prevent MITM attackers from accessing powerful APIs that could further compromise the victim of an attack.
In particular, don't use the loadData method as that wouldn't give you a secure context. Quoting the relevant part of the documentation:
Content loaded using this method will have a window.origin value of "null". This must not be considered to be a trusted origin by the application or by any JavaScript code running inside the WebView (for example, event sources in DOM event handlers or web messages), because malicious content can also create frames with a null origin. If you need to identify the main frame's origin in a trustworthy way, you should use loadDataWithBaseURL() with a valid HTTP or HTTPS base URL to set the origin.
Instead it is recommended to use loadDataWithBaseURL().
Finally, note that Widevine comes with 3 different levels of certification (L1, L2 and L3). L1 being the highest, using the Trusted Execution Environment. AFAIK, L1 may still not be supported yet
on WebViews as shown by this code review comment:
Unless there's some other hidden magic, I believe so. We'll enable L1 on WebView when AndroidOverlay is supported on WebView.
Note that this comment dates from 2017, so not sure whether it is still relevant. The point is that another reason why this wouldn't work is if decrypting the code requires L1 level and either your device or the WebView don't support it.
Hope that helps.

Related

Intercept *all* requests from Android WebView

The title says it all. I would like to know about everything what the WebView is asking for. Some weird limitations like not knowing about XHR POST are not acceptable. In other words, something like iOS have in NSURLProtocol. That one is application-wide hook. I don't need such level of control, WebView-instance-specific hook would be good enough. Now, i know that nothing like that exists on Android out of the box. I know about shouldOverrideUrlLoading and shouldInterceptRequest, but it's largely unusable. I need to know about requests (method, HTTP version, headers, you know) not just merely the URL strings. Moreover the intercepting is awkwardly synchronous. What happens if shouldInterceptRequest call is blocked because i need to ask a different server for related resource? It appears to me being designed just for a local resource caching.
On the other hand, i am willing to throw anything at the problem. Some kind of native library, hooking into low level internals? Extending Chromium interfaces with help of an existing project (pwnall, mogoweb)? Reflecting into the existing webkit class privates? Application-specific proxy? Any insights appreciated. I have read through two dozens of existing SO questions. They all either suggest a partial hack (like working around XHR POST deficiency with JavaScript) or it goes unresponded altogether, very often.
Try with inspeckage:
https://github.com/ac-pm/Inspeckage
It needs Xposed and root access to work. I've been able to see WebView requests from apps. Im figuring out how to recreate them with Python's requests module.
Hope that helps.
If I understand your goal - try:
WebView.setWebContentsDebuggingEnabled(true);
Open Chrome and go to url chrome://inspect/#devices
for details:
https://developers.google.com/web/tools/chrome-devtools/remote-debugging
https://developers.google.com/web/tools/chrome-devtools/remote-debugging/webviews

Trigger.io Local Resource Access on Android 4.4

I have a very simple HTML5 app written with trigger.io that fails running under Android 4.4 with errors stating that local content cannot be accessed. Example:
E/AndroidProtocolHandler( 2236): Unable to open content URL: content:////io.trigger.forge9aee7db8338b11e4b77d1231392b77b0/src/images/connect4.jpg
The same code works find under Android 4.3. This applies to all local content including images, CSS and JavaScript. All resources are referenced with relative paths such as "images/image.jpg".
My best guess is that there is an access policy change in newer versions of Android OS but I cannot figure out the details. I have made sure that nowhere in the code attempts to access external resources.
Antoine van Gelder was incredibly helpful on this. His diagnosis was absolutely correct that jQuery Mobile is rewriting the URLs for resources which causes newer versions of Android's Chrome Webview to fail when accessing resources. The generated URLs contain quadruple slashes after the protocol like this:
content:////io.trigger.forge9aee7db8338b11e4b77d1231392b77b0/src/resource.png
The extra slashes cause Webview to fail. Possibly some excessive checking for correctness or a security implication?
Antoine's suggestions of using older versions of jQuery Mobile or building a custom jQuery Mobile without Base Tag will probably work in some circumstances though neither was quite sufficient in my case. Particularly, removing Base Tag also removes some other functionality I needed.
An alternative approach is to make a minor hack to jQuery Mobile. For version 1.4.3 I did the following:
Edited an un-minified version of jQuery Mobile's javascript
Modified the getLocation function:
Save the return value to a temporary variable
Modify the temporary variable by removing quadruple slashes.
I used something very specific and restricted to the "content" protocol: "retVal = retVal.replace("content:////","content://");"
Return the fixed temporary variable
It looks like, starting with v1.3, jQuery Mobile are rewriting the URL's in your document which breaks the Chrome Webview's access to files in the app sandbox.
You could try filing a bug report with the jQuery Mobile devs but to sort this out in the short term your best options are probably one of:
1) Fall back to jQuery Mobile 1.2.1
2) Build a custom version of jQuery Mobile which excludes some navigation features. (Go to download builder (http://jquerymobile.com/download-builder/), scroll down to "Navigation" and de-select the "Base Tag" module)
This should be fixed in JqueryMobile 1.4.4.

WebView.addJavascriptInterface should not be called

AndroidStudio began to show me warning "WebView.addJavascriptInterface should not be called". But this method exists and is not deprecated. What's wrong with it? May be I am missing something and now there is better way to make interaction with Javascript?
It has known security vulnerabilities in earlier Android versions. From the docs:
This is a powerful feature, but also presents a security risk for
applications targeted to API level JELLY_BEAN or below, because
JavaScript could use reflection to access an injected object's public
fields. Use of this method in a WebView containing untrusted content
could allow an attacker to manipulate the host application in
unintended ways, executing Java code with the permissions of the host
application. Use extreme care when using this method in a WebView
which could contain untrusted content.

Change cryptos used in WebRTC browser calls

I am developing a voice / video calling system in which there is browser to browser, Android to Android and Android to browser calling. Although I have managed to get that all working, I have run into a problem with the cryptos being used to encrypt the audio / video packets being sent between two clients. My system requires a certain set of cryptos, and I have managed to get that set working with Android to Android calling. However, the default cryptos being used in WebRTC enabled browsers are significantly weaker than the alternate crypto set being used for Android to Android calling. Thus, I have to "dumb down" the cryptos in the system so that I can have Android to browser calling.
Since I have no access to the code for WebRTC enabled browsers (and definitely cannot modify it) my only recourse is to somehow select or tell the peerconnection object which crypto level / set to use. I swear I have heard of this being done before, but I cannot find where I saw it nor anywhere that talks about doing it. So, I was wondering if anyone knew:
Is such a thing possible?
If possible, how does one set the cryptos for the call?
What cryptos are supported in Chrome and Firefox?
If I am remembering what I saw correctly, it was done somewhere along the lines of passing a JSON looking something like: { 'crypto' : 'AES....'} to the constraints parameter of webkitRTCPeerConnection. However, I could potentially be imagining all of this.
You can enable DTLS by passing the following to the PeerConnection constructor:
{ 'optional': [{'DtlsSrtpKeyAgreement': 'true'}]}
However, that doesn't let you pick the crypto algorithm. For that you could potentially munge the SDP with a different crypto line with the given SRTP key management parameters. However, I'm not sure offhand if anything other than the default is supported in Chrome. That may be a good question for the discuss-webrtc list.

What does "enable DOM storage API" mean?

I came across this Android WebView function WebSettings.setDomStorageEnabled(true) and from the name alone I can infer that it simply "enables DOM storage".
The Android documentation, however, suggests something slightly different:
Set whether the DOM storage API is
enabled.
IOW, it enables the API rather than the storage itself.
My problem is... I didn't know about the existence of such an API until I encountered this function.
My Google search suggests that this API is closely associated with HTML5.
Does that mean that this function is
irrelevant to web sites/pages that
do not use HTML5? IOW, does it
affect existing non-HTML5 page
loading & rendering at all?
Where can I learn more about the DOM
storage API?
In particular, are there any gotchas
or caveats that I need to watch for
when calling
WebSettings.setDomStorageEnabled(true)
in an Android app?
Why is it disabled by default?
Update: I now can at least answer question #2: It turns out that the common name for "DOM Storage" is "Web Storage" and there is an entire Wikipedia article about this: http://en.wikipedia.org/wiki/Web_Storage
I believe this functionality is irrelevant for websites that do not use the HTML 5 specifications, since it is part of that spec. I would imagine the main thing to look out for when enabling this API is that it would then allow ANY website that takes advantage of DOM storage to use said storage options on the device. I would imagine it is disabled by default for space savings and security.
No. You will have to use it to enable some features of JS functionality as well.
devloper.android link:
http://developer.android.com/reference/android/webkit/WebSettings.html#setDomStorageEnabled%28boolean%29/
MDN explnation about DOM storage:
https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage
You need to know there are security attacks that can be made (if you use it with js).
It opens some security vulnerabilities of the system.

Categories

Resources