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!

Deleted: Screen Shot 2017-12-29 at 12.29.52 PM.png 180 KB

	Screen Shot 2017-12-29 at 12.29.52 PM.png 180 KB View Download

Deleted: Screen Shot 2017-12-29 at 12.30.31 PM.png 129 KB

	Screen Shot 2017-12-29 at 12.30.31 PM.png 129 KB View Download

Deleted: Screen Shot 2017-12-29 at 12.33.18 PM.png 150 KB

	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

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'ing third_party/widevine owners - ddorwin@ / xhwang@, any idea?

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

The history of this bug is confusing. What exactly is the problem?

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);

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?

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.

+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? 

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).

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?

Deleted: widevine.js 811 bytes

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).

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.