New issue
Advanced search Search tips

Issue 797914 link

Starred by 5 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 2
Type: Bug-Regression



Sign in to add a comment

requestMediaKeySystemAccess for "com.widevine.alpha" fails

Reported by j.caro...@peoplesplayground.nl, Dec 28 2017

Issue description

Steps to reproduce the problem:
This is based on a Cordova project that includes the above index.html, so not sure what the most practical way is to reproduce.
1. Run the index.html
2. Observe the console output via remote debug/inspect

What is the expected behavior?
There should be widevine support

What went wrong?
The Promise is rejected with "DOMException: Unsupported keySystem or supportedConfigurations".

Did this work before? Yes Chrome 55

Does this work in other browsers? Yes

Chrome version: 63.0.3239.111  Channel: n/a
OS Version: 7
Flash Version: 

Looking at the error, first thoughts were about the changes since Chrome 58 which require a secure context for EME API's, but we found that the file:// is treated as a secure context. Also the same (commented) code for "clearkey" does work (it should throw an exception in the first place). 
Other reported issues that we found suggest a limitation of DRM resources, but it can be reproduced on devices after a cold start and after clearing app data.
It also seems to be Android(TV) related - we have been able to reproduce on different Android TV devices (version 7), whereas on Android 8.1 with the same Chrome client, we could not reproduce.
Chrome 55 is the version we know it works, we have not tested with other in between versions than te latest in this report.
 
index.html
1.4 KB View Download
Labels: Needs-triage-Mobile
Cc: pnangunoori@chromium.org ligim...@chromium.org arthurso...@chromium.org
Components: Mobile>WebView
Labels: Triaged-Mobile Needs-Feedback
Tested on latest Chrome Stable #63.0.3239.111 and Chrome Canary #65.0.3306.0 on SM-J710F Android 7.0.0 Build/NRD90M and able to notice the mentioned behavior, i.e. noticed an error "DOMException: Unsupported keySystem or supportedConfigurations"

Also verified on the earlier Chrome Version's #59.0.3030.0, #55.0.2841.0, #50.0.2624.0, observed the error "DOMException: None of the requested configurations were supported".

j.carolus@ -- Could you please verify the screenshots and let us know if anything is missed.

CC'ing dev for the further inputs.
arthursonzogni@ -- Could you please look into this issue.

Attaching the screenshots for reference.


Thanks in advance!
Screen Shot 2017-12-29 at 12.29.52 PM.png
180 KB View Download
Screen Shot 2017-12-29 at 12.30.31 PM.png
129 KB View Download
Screen Shot 2017-12-29 at 12.33.18 PM.png
150 KB View Download
Pada 29/12/2017 3:17 PTG, "pnanguno… via monorail" <
monorail+v2.787253306@chromium.org> menulis:

arthursonzogni@chromium.org

requestMediaKeySystemAccess for "com.widevine.alpha" fails

#65.0.3306.0 on SM-J710F Android 7.0.0 Build/NRD90M and able to notice the
mentioned behavior, i.e. noticed an error "DOMException: Unsupported
keySystem or supportedConfigurations"

#50.0.2624.0, observed the error "DOMException: None of the requested
configurations were supported".

anything is missed.
We have *not* observed the "DOMException: None of the requested configurations were supported".
This is because of a false assumption from my side - apologies. The index.html is supposed to work for Chrome 58+ which also requires to specify more requirements such as audio and video codecs and robustness. One or more may not be compatible with the older Chrome versions.

Our observations:
a. Android 6.0 with Chrome/55.0.2883.91 -> widevine is supported
b. Android 7.0 with Chrome/63.0.3239.111 -> not supported, "DOMException: Unsupported
keySystem or supportedConfigurations"
c. Android 8.1 with Chrome/63.0.3239.111 -> widevine is supported

Test cases a. and b. where performed on the same devices after an upgrade, c. on another device as 8.1 was not available for the other devices. 

Conclusion from our side is that the underlying DRM system is available (worked on Android 6.0). The configuration to request is in order (as per spec of 58+ and working on 8.1 with same Chrome version).

So this looks more like an Android related issue. 

Is this the right place for this issue, or do we have to report to Android? Or is there something perhaps that you can see?

Regards,
Jeroen




Project Member

Comment 5 by sheriffbot@chromium.org, Dec 29 2017

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "pnangunoori@chromium.org" to the cc list and removing "Needs-Feedback" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
I don't have any knowledge in this area.

I made this test case is accessible in:
https://pste.eu/p/kfjO.html

Here is what I got on Android 7.1.2

# Chromium 64
kfjO.html:38 no widevine support, rejected
kfjO.html:39 DOMException: Unsupported keySystem or supportedConfigurations.

# Chrome 55:
kfjO.html:36 widevine support ok MediaKeySystemAccess {keySystem:"com.widevine.alpha"}

#Chrome 63:
kfjO.html:36 widevine support ok MediaKeySystemAccess {keySystem:"com.widevine.alpha"}

That looks good to me.

From there I don't know what to do. I filed a bug to the Widevine team here: https://buganizer.corp.google.com/issues/71494854
Thanks for making it available and filing with the Widevine team. 

Perhaps is good to add that on Android 8, Widevine is working for all tested Chrome versions.
Cc: ddorwin@chromium.org xhw...@chromium.org
cc'ing third_party/widevine owners - ddorwin@ / xhwang@, any idea?

Comment 9 by xhw...@chromium.org, Jan 23 2018

https://pste.eu/p/kfjO.html gives me a 404.

The history of this bug is confusing. What exactly is the problem?
Components: Internals>Media>Encrypted
The history of this bug is indeed a bit confusing and it's hard to pinpoint the problem.
So here is the history in more detail:

We have an Android application that is built using Cordova - so it's using a webview with the Chrome version of the device. But the issue can be seen from the browser directly.
We noticed that a number of different Android TV models (e.g. Sony Bravia, NVIDIA Shield) were no longer able to play streams protected with Widevine, after their Android and Chrome were updated - from Android 6.0 + Chrome/55 to Android 7.0 + Chrome/63.
Android 8.0 devices with the same Chrome/63 version were able to play.

Android 8 is net yet available for the devices in question, so this is a big problem for our client who is in production with the app.

To make things more complicated, there are very few occurrences where requesting the key system actually works (found after posting here), but we are not able to reproduce (e.g. rebooting, clearing application cache/data, restarting the app scenario's). It will then be able play during the lifetime of the app.

Maybe somebody can comment on where to file this bug as well or what the best way forward is?

Comment 9
> https://pste.eu/p/kfjO.html gives me a 404.
Sorry, tt looks like this website remove its contents after some time.
That is the content of file in comment 1.
New URL: https://pste.eu/p/FjG4.html (it will be a 404 after some time)
The configuration used:
var config = [{
  "initDataTypes": ["cenc"],
  "sessionTypes": ["temporary"],
  "audioCapabilities": [{
    "contentType": "audio/mp4;codecs=\"mp4a.40.2\"",
    "robustness": "SW_SECURE_CRYPTO"
  }],
  "videoCapabilities": [{
    "contentType": "video/mp4;codecs=\"avc1.42E01E\"",
    "robustness": "SW_SECURE_CRYPTO"
  }]
}];
navigator.requestMediaKeySystemAccess("com.widevine.alpha", config);
Owner: xhw...@chromium.org
Status: Assigned (was: Unconfirmed)
xhwang@, could you take a look or triage this?
Re #11: I cannot see how the query sometimes work and sometimes not work. Do you always allow the permission prompt? Do you always serve the page on https?
Re #15
The page is always served in the exact same way - the page is built in an Android webview and the same build is ran multiple times. The page is served via file://, which is also secure context, and there is always stable behaviour on Android 8.

What do you mean with permission prompt?
Cc: jrumm...@chromium.org
file:// may be a unique origin, which I think is blocked in the EME implementation.

Note that WebView-based apps receive a permission request via the WebView API and are required to handle that. The WebView implementation itself does not prompt.
I checked file:// origin, should be treated as a "SecureContext".

Again - it works as expected on Android 8 (same build). 
Does that mean Android 8 does not respect the permission request requirement and or the origin check?

Also, you would expect it to never work if there is a permission requirement.

Are you talking about an android permission?

The sessionType is temporary, so it's net clear to me what kind of permission the user has to give?



In #11, "the issue can be seen from the browser directly". Since this can repro in the browser (Chrome on Android I suppose), let's focus on the browser case since that's easier to discuss/repro.

When you use Chrome on Android, to use Widevine key system, even for temporary session, you'll see a Chrome permission prompt, if you reject the prompt requestMediaKeySystemAccess() will be rejected.

I don't think it's the problem but want to rule out possibilities before we dive deeper.
Testing in a browser was a while ago, I must have mindlessly clicked the prompt and forgot about it, you are right, it prompts for permission.

So what is still confusing for me is that it works on Android 8, and in some rare cases on Android 7.

Are you referring to a case like this (I could not find something related to widevine):
https://medium.com/@xabaras/android-webview-handling-geolocation-permission-request-cc482f3de210


We have been able to pinpoint the issue and create an isolated test:
https://github.com/jcarolus/issue-android-webview

The activity:
https://github.com/jcarolus/issue-android-webview/blob/master/app/src/main/java/com/example/jcarolus/myapplication/MainActivity.java

The index.html
https://github.com/jcarolus/issue-android-webview/blob/master/app/src/main/assets/index.html

Observed: 
- release builds do NOT work on Android 7.
- debug session DOES work on Android 7
On Android 8, all cases work.
Replacing the file:// with a https:// source will work for both Android 7 and 8.

Maybe this helps finding where the issue is; looks like Android 7 related. 

Cheers
Can you repro this issue in Chrome browser on Android? Or is it specific to Android WebView?
It's specific to WebView.
Cc: boliu@chromium.org
+boliu: This issue is specific to WebView and only repros on certain Android versions. Do you know anyone on the WebView side that can help investigate this? 

Comment 25 by boliu@chromium.org, Apr 23 2018

Are we sure this isn't due to file:// url? From MainActivity.java in #21:
webView.loadUrl("file:///android_asset/index.html"); // https:// will work

So https works in webview? When you were testing in chrome, were you using a file:// url?

In this post, xhwang also mentions need special flags for EME to work with file url:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/tXmKPlXsnCQ/n1n6pAJxBwAJ

File urls are always going to be a special snow flake on edge case behaviors, so cordova should really stop relying on file urls so extensively..
If file:// was not treated as a secure origin, the EME API's should not be available and an exception should be thrown (my interpretation of the documentation). However, there is the reject for the key system not to be available.

https:// works in WebView. 
I have not tested file:// in chrome, but I would expect some cross site problems.

The premise of Cordova is to work with file urls because e.g. Apple/iOS does not allow hosted applications. If it's not supposed to work, then ok, developers should not try to use EME on Cordova.

Since everything works on Android 8, I suspect a bug/inconsistency somewhere. 

Chrome's EME implementation has a check for unique origins (beyond what is in the spec).  This may be causing the behavior you see, though I don't know why it would have changed across Android versions.
As an extra test, I tested the index.html via file:// on desktop Chrome 66, and this works.

My conclusion is that the `onPermissionRequest` override on the `WebChromeClient` for the WebView is not being called when on Android 7 running the app in release mode. If there is an extra check for unique origins, this is failing in debug mode (because it is working then).

Comment 29 by boliu@chromium.org, Apr 25 2018

Can you check file:// url on chrome on android. ie try the same (ideally latest) version of chrome and webview, on the same device, both using file:// urls.

Generally webview shouldn't differ from chrome on android (modulo all the webview settings/callbacks)
Tested on Android 7 via file:// url. 
This works. It follows the expected flow where you have to manually allow the prompt to uniquely identify your device needed by EME. 
The prompt should not be shown in WebView, here this needs to be programatically done via the onPermissionRequest.

I have the same issue, so I am going to share my findings. We are trying to use Shaka Player in an Android Cordova-based app with DASH Widevine DRM content and seeing mixed results based on Android versions. Typically if I run the attached JavaScript file in a Cordova 8 based Android WebView I am seeing:
- Nexus 5X with Android 8.1 (Chrome 66.0.3359.126 WebView): works 
- Samsung J5 with Android 7.1.1 (Chrome 66.0.3359.126 WebView): fails
- Nexus 7 with Android 6.0.1 (Android System WebView 66.0.3359.126): fails

The same test for ClearKey DRM passes on all devices. No issue in Chrome for Android so this is really WebView specific. I ran the same test in a WebView generated from native code from Android Studio and I was able to see the same issue. I made sure the user permission was programmatically granted in the WebView, but note that this permission is also granted by default in Cordova as described here: https://github.com/apache/cordova-android/pull/178.

Did you make any progress on this?


widevine.js
811 bytes View Download
There is no progress. 
The only thing that does work is if you make it a "https:// hosted" app in Cordova, which is usually not an option.
I just tried to use the player in a HTTPS iframe with encrypted-media Feature Policy, in the long-shot hope that it would trick the system into allowing EME in a Cordova app, but no, it does not work. Also confirming the issue is on Android 5. I am just not sure how to create a "https:// hosted" app in Cordova since the file protocol is used as origin for Cordova apps. It would be great if the Google/WideVine team could fix this at some point.
Creating a hosted app in Cordova is doable, be it not advisable (no fallback when device is offline etc).

You can just replace <content src="index.html"/> to <content src="https://yourdomain/index.html" /> in the config.xml.
But you have to make sure to copy the correct wwwroot to your server: 
(cordova root)/platforms/android/app/src/main/assets/www
such that all cordova (plugin) related javascript are available.
You could even consider removing all assets from the cordova www, while making sure to deploy them to your server.

So yes I can set <content src="https://app-url"> to a fully qualified HTTPS URL and this works. Though I am reluctant to consider this option mainly because it makes managing offline playback impossible. I also tried to set window.location.href or using window.open upon onDeviceReady but in this case it still does not work. Well actually it may work if I use InAppBrowser with window.open and configure it to use the system browser AND this system browser happens to be Chrome (but this feels pointless since we are moving the viewer outside of the WebView-based app in this case).

Comment 36 by torne@chromium.org, May 24 2018

There are a number of different ways in the WebView API to load locally cached/stored content such that it appears to be loaded from a real HTTPS origin: substituting network responses with shouldInterceptRequest, using loadDataWithBaseURL to load the content directly with a different origin, or just using a service worker to cache the content for offline support (as any web page could do).

I'm not a Cordova expert so don't know how well any of these things are supported by Cordova, but we (the webview team) strongly recommend that applications do *not* rely on file: origins for any purpose, and use real origins for their content in all cases. We're aware this isn't always easy right now and are working on improvements to the APIs to make this less challenging, but it *is* possible with the current APIs already.

Sign in to add a comment