If it´s not clear, we´re talking about Android here, and not windows - I see it saying "OS Version 10.0", which is wrong and probably my mistake.
For me the main issue is that it´s not working in the webview, because the app I´m developing depends on this. I just wanted to address it as the more general issue that it is to make sure that all aspects are covered. 
Seeing the added comment "Needs-Milestone", do I need to add more here?

Can someone from the WebView team confirm that this is an issue?
I thought getUserMedia worked fine on WebView.

What do you mean by "stock browser"? We don't provide a WebView based browser any more (it was discontinued in Android 6.0), so any WebView based browser that ships on a device is probably the device manufacturer's. Can you clarify exactly which device you are using and what browser app this actually is (i.e. the package name and version).

Also, if you're having trouble in your own application, then providing us with that app (or ideally a minimal repro case) would be more helpful than referring to an unknown browser.

You also haven't mentioned what version of WebView you're using on the device.

Probably related to this (restricted) bug crbug.com/707082

getUserMedia should work, yes.

Thank you all,

Regarding webview: No, it´s the other way around: The webview bases itself on the stock browser. With stock browser I mean the browser that´s born with the OS. I have tested this on Genymotion, AVD and a Huawei P8 phone - all with android 6.0, but also nougat - where going to https://appr.tc in the builtin browser does not show the local camera. 
Google chrome and opera on these platforms don´t have a problem.
Testing the same as described above on Genymotion, AVD and LG G3 phone - all with android 5.1.1 DOES show the local camera.
The stock browsers all have different names and versions, but I assume that they all depend on particular chromium components in the OS which are different in each android version - hence the bug.
The webview is bundled with B4A 6.80, but again: It just acts as the stock browser in the device where it´s installed. 

This is the code:

Sub Cambutton_Click

Dim videofeedcount As String
	Dim isfeedon As Boolean
	Dim jme As JavaObject
        Dim camview as WebView
	camview.Initialize("camview")
	jme.InitializeContext
	jme.RunMethod("SetWebChrome", Array(camview))
        videofeedcount = DateTime.Now
	isfeedon = True
	Dim url As String = "https://appr.tc/r/"&videofeedcount
	ToastMessageShow(videofeedcount,False)
	camview.LoadUrl(url)
        Activity.AddView(camview,0,0,Activity.Width,Activity.Height)

End Sub

#if java

import android.widget.*;
import android.webkit.*;
public void SetWebChrome(WebView camview) {
   camview.setWebChromeClient(new WebChromeClient() {
     @Override
     public void onPermissionRequest(PermissionRequest request) {
       BA.Log("onPermissionRequest");
       request.grant(request.getResources());
     }
   });
}

So, to reproduce this: 

Try the following on android 5.1 and on android 6.0, either in an emulator or on a hardware device:
1. Go to https://appr.tc/
2. Tell android that you allow access to your cam and mic.
3. Check if local camera shows.

On android 5.1, the result for point 3 will be positive, on android 6.0 it will be negative.
I hope this is clear now.

... edit to previous post: The browser where you should try the reproduction of the issue is (obviously I think) the stock browser, not any other browser such as google chrome, firefox or opera.

This does not reproduce on a nexus 6 with MRA59G (6.0) and webview 56.0.2924.87.

Are you sure that the apps you are testing with implement the camera and microphone permissions correctly?

Can you please provide logs from your device?

Thanks tobiasjs,

I just tried https://appr.tc/ on a Nexus 6 with MRA58K on Genymotion, so a bit younger than your version but got "Cannot create RTCPeerConnection: Illegal Constructor". This could be either the version, or that it runs on an emulator.
I´ve checked the webview versions now on various devices: 
Lollipop:
- Genymotion: 39
- Hardware LG G3: 39
Marshmallow:
- Hardware Huawei P8: 49
- Genymotion: 44
Nougat:
- Genymotion: 51

I checked this in system/app/webview folder. Could it be that all versions of webview between 39 and 56 are incompatible with sending webrtc?
This is simply a test in the browser builtin to the device, so they should do the same regardless of the android version. As mentioned, lollipop has no issues with this.
Where would I find logs for webview?

Thank you for providing more feedback. Adding requester "tobiasjs@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 just tried something else: I set up a Nexus 7 Nougat 7.1.1 AVD (Genymotion does not have such a high version of Android yet) to see what I´d get. Here the webview is v 52, and the behavour still the same. I then tried installing "Android system Webview" apk (v58) but the webview component still reports version 52, and still behaves the same way.
I don´t know if this "about" screen shot can help anyone to get a deeper understanding of what´s going wrong. If this indeed is about the webview version, and that devices ignore attempts to update it, I guess there´s very little we developers can do till in two years where a larger part of phones have fixed webviews installed..

Deleted: avdnougat7.1.1.png 307 KB

	avdnougat7.1.1.png 307 KB View Download

Ok, I´ve been playing around with this some more, and managed to put together a js script which shows that transmission IS possible - at least of video - from Android 6.0, but only that - no reception is possible.

https://lychee-custard-78219.herokuapp.com/demos/testconn.html?roomid=12345

(room ID can be anything, as long as it´s the same on the two devices. This is only for two parties, not more)

I know that it worked on Nexus for tobiasjs, but that´s prolly because he´s so lucky to have a device with a more recent version of webview. I´ve already checked of installing Android System Webview latest version solves the problem, but not - I suppose mobile phones don´t allow you to change a core component right away like that. Hence, as a developer, this is not a solution, even if I´d be able to hack my way to an updated version on my own device.
So I ran a logcat on the Marshmallow emulator and compared it to the one from Lollipop, and came up with all this. x.x.x.x is replacing my own public IP. Would anyone have any idea if the script I´m using in the previous link can be tweaked to work around this issue? The log is a bit zwahili to me. 

PS: Sorry if this is getting offtopic, as I guess that if latest chromium won´t have this issue, it´s not really a bug that should be addressed here anymore. Was just hoping that someone already came across the issue with older chromiums, and found a fix for it:

04-14 06:53:41.233 21374 22362 W chromium: 
[WARNING:webrtcsession.cc(1532)] Candidate has unknown component: 
Cand[672567781:2:tcp:1518214911:192.168.149.101:0:local::0::] for 
content: audio
04-14 06:53:41.238 21374 22362 W chromium: 
[WARNING:webrtcsession.cc(1532)] Candidate has unknown component: 
Cand[672567781:2:tcp:1518214911:192.168.149.101:0:local::0::] for 
content: video
04-14 06:53:41.265 21374 22362 W chromium: 
[WARNING:webrtcsession.cc(1532)] Candidate has unknown component: 
Cand[3294919965:2:udp:1686052607:x.x.x.x:64185:stun:10.0.3.15:46830::] 
for content: audio
04-14 06:53:41.269 21374 22362 W chromium:         
[WARNING:webrtcsession.cc(1532)] Candidate has unknown component:             
Cand[3294919965:2:udp:1686052607:x.x.x.x:64185:stun:10.0.3.15:46830::] 
for content: audio
04-14 06:53:41.270 21374 22362 W chromium: 
[WARNING:webrtcsession.cc(1532)] Candidate has unknown component: 
Cand[257893076:2:udp:1685987071:x.x.x.x:64186:stun:192.168.149.101:38704::] for content: audio 04-14 06:53:41.283 21374 22362 W chromium: [WARNING:webrtcsession.cc(1532)] Candidate has unknown component: Cand[3294919965:2:udp:1686052607:x.x.x.x:64185:stun:10.0.3.15:46830::] for content: video 04-14 06:53:41.284 21374 22362 W chromium: [WARNING:webrtcsession.cc(1532)] Candidate has unknown component: Cand[3294919965:2:udp:1686052607:x.x.x.x:64185:stun:10.0.3.15:46830::] for content: video 04-14 06:53:41.290 21374 22362 W chromium: [WARNING:webrtcsession.cc(1532)] Candidate has unknown component:

Cand[257893076:2:udp:1685987071:x.x.x.x:64186:stun:192.168.149.101:38704::] for content: video 04-14 06:53:41.292 21374 22362 W chromium: [WARNING:webrtcsession.cc(1532)] Candidate has unknown component: Cand[3294919965:2:udp:1686052607:x.x.x.x:64185:stun:10.0.3.15:46830::] for content: video 04-14 06:53:41.296 21374 22362 W chromium: [WARNING:webrtcsession.cc(1532)] Candidate has unknown component:

Cand[257893076:2:udp:1685987071:x.x.x.x:64186:stun:192.168.149.101:38704::] for content: video 04-14 06:53:41.299 21374 22362 W chromium: [WARNING:webrtcsession.cc(1532)] Candidate has unknown component:

Cand[257893076:2:udp:1685987071:x.x.x.x:64186:stun:192.168.149.101:38704::] for content: video 04-14 06:53:41.300 21374 22362 W chromium: [WARNING:webrtcsession.cc(1532)] Candidate has unknown component: Cand[3294919965:2:udp:1686052607:x.x.x.x:64185:stun:10.0.3.15:46830::] for content: audio 04-14 06:53:41.302 21374 22362 W chromium: [WARNING:webrtcsession.cc(1532)] Candidate has unknown component:

Cand[257893076:2:udp:1685987071:x.x.x.x:64186:stun:192.168.149.101:38704::] for content: audio 04-14 06:53:41.304 21374 22362 W chromium: [WARNING:webrtcsession.cc(1532)] Candidate has unknown component:

Cand[257893076:2:udp:1685987071:x.x.x.x:64186:stun:192.168.149.101:38704::] for content: audio 04-14 06:53:41.306 21374 22362 W chromium: [WARNING:webrtcsession.cc(1532)] Candidate has unknown component: Cand[1188767642:2:udp:41885439:64.251.31.85:48040:relay:x.x.x.x:64185::] for content: audio 04-14 06:53:41.310 21374 22362 W chromium: [WARNING:webrtcsession.cc(1532)] Candidate has unknown component: Cand[1188767642:2:udp:41885439:64.251.31.85:53885:relay:x.x.x.x:64185::] for content: audio 04-14 06:53:41.312 21374 22362 W chromium: [WARNING:webrtcsession.cc(1532)] Candidate has unknown component: Cand[1188767642:2:udp:41885439:64.251.31.85:63128:relay:x.x.x.x:64185::] for content: audio 04-14 06:53:41.331 21374 22362 W chromium: [WARNING:webrtcsession.cc(1532)] Candidate has unknown component: Cand[1188767642:2:udp:41819903:64.251.31.85:40531:relay:x.x.x.x:64186::] for content: audio 04-14 06:53:41.373 21374 22362 W chromium: [WARNING:webrtcsession.cc(1532)] Candidate has unknown component: Cand[1188767642:2:udp:41819903:64.251.31.85:57255:relay:x.x.x.x:64186::] for content: audio 04-14 06:53:41.379 21374 22362 W chromium: [WARNING:webrtcsession.cc(1532)] Candidate has unknown component: Cand[1188767642:2:udp:41885439:64.251.31.85:48040:relay:x.x.x.x:64185::] for content: video 04-14 06:53:41.382 21374 22362 W chromium: [WARNING:webrtcsession.cc(1532)] Candidate has unknown component: Cand[1188767642:2:udp:41885439:64.251.31.85:53885:relay:x.x.x.x:64185::] for content: video 04-14 06:53:41.400 21374 22362 W chromium: [WARNING:webrtcsession.cc(1532)] Candidate has unknown component: Cand[1188767642:2:udp:41885439:64.251.31.85:63128:relay:x.x.x.x:64185::] for content: video 04-14 06:53:41.411 21374 22367 E chromium: [ERROR:process_thread_impl.cc(31)] TimeUntilNextProcess returned an invalid value -2 04-14 06:53:41.413 21374 22362 W chromium: [WARNING:webrtcsession.cc(1532)] Candidate has unknown component: Cand[1188767642:2:udp:41819903:64.251.31.85:40531:relay:x.x.x.x:64186::] for content: video 04-14 06:53:41.419 21374 22362 W chromium: [WARNING:webrtcsession.cc(1532)] Candidate has unknown component: Cand[1188767642:2:udp:41819903:64.251.31.85:57255:relay:x.x.x.x:64186::] for content: video 04-14 06:53:41.428 21374 22362 W chromium: [WARNING:webrtcsession.cc(1532)] Candidate has unknown component: Cand[1188767642:2:udp:41819903:64.251.31.85:65118:relay:x.x.x.x:64186::] for content: audio 04-14 06:53:41.438 21374 22362 W chromium: [WARNING:webrtcsession.cc(1532)] Candidate has unknown component: Cand[1188767642:2:udp:41819903:64.251.31.85:65118:relay:x.x.x.x:64186::] for content: video 04-14 06:53:41.497 21374 22397 I X509Util: Failed to validate the certificate chain, error: java.security.cert.CertPathValidatorException: Trust anchor for certification path not found. 04-14 06:53:41.498 21374 22233 W chromium: [WARNING:socket_host_tcp.cc(220)] Error from connecting TLS socket, status=-202 04-14 06:53:41.499 21374 22363 W chromium: [WARNING:turnport.cc(361)] Jingle:Port[audio:1:0:relay:Net[eth1:10.0.3.0/24:Unknown]]: Connection with server failed, error=0 04-14 06:53:41.500 21374 22363 W chromium: [WARNING:turnport.cc(361)] Jingle:Port[audio:1:0:relay:Net[eth0:192.168.149.0/24:Unknown]]: Connection with server failed, error=0 04-14 06:53:41.915 21374 22381 E chromium: [ERROR:process_thread_impl.cc(31)] TimeUntilNextProcess returned an invalid value -4 04-14 06:53:42.537 21374 22363 E chromium: [ERROR:webrtcvoiceengine.cc(1455)] webrtc: (voe_audio_processing_impl.cc:1007): SetTypingDetectionStatus: not supported 04-14 06:53:42.537 21374 22363 W chromium: [WARNING:webrtcvoiceengine.cc(971)] SetTypingDetectionStatus(0) failed, err=8003 04-14 06:53:43.542 21374 22363 W chromium: [WARNING:webrtcvoiceengine.cc(1455)] webrtc: (neteq_impl.cc:630): InsertPacketInternal: Packet buffer flushed 04-14 06:53:43.639 21374 22381 E chromium: [ERROR:process_thread_impl.cc(31)] TimeUntilNextProcess returned an invalid value -3 04-14 06:53:44.525 21374 22363 W chromium: [WARNING:webrtcvoiceengine.cc(1455)] webrtc: (neteq_impl.cc:630): InsertPacketInternal: Packet buffer flushed 04-14 06:53:44.763 367 722 W AudioFlinger: write blocked for 9974 msecs, 45 delayed writes, thread 0xf1e40000 04-14 06:53:45.280 367 722 D AudioFlinger: mixer(0xf1e40000) throttle end: throttle time(11) 04-14 06:53:45.499 367 722 D AudioFlinger: mixer(0xf1e40000) throttle end: throttle time(5) 04-14 06:53:46.623 21374 22363 W chromium: [WARNING:vie_capturer.cc(130)] Same/old NTP timestamp for incoming frame. Dropping. 04-14 06:53:46.672 21374 22381 E chromium: [ERROR:process_thread_impl.cc(31)] TimeUntilNextProcess returned an invalid value -2 04-14 06:53:46.760 21374 22367 E chromium: [ERROR:process_thread_impl.cc(31)] TimeUntilNextProcess returned an invalid value -5 04-14 06:53:50.531 21374 22363 E chromium: [ERROR:stunport.cc(90)] Binding request timed out from 10.0.3.15:61000 (eth1) 04-14 06:53:50.531 21374 22363 E chromium: [ERROR:stunport.cc(90)] Binding request timed out from 192.168.149.103:58396 (eth0) 04-14 06:53:50.608 21374 22367 E chromium: [ERROR:process_thread_impl.cc(31)] TimeUntilNextProcess returned an invalid value -4 04-14 06:53:55.992 21374 22381 E chromium: [ERROR:process_thread_impl.cc(31)] TimeUntilNextProcess returned an invalid value -5

I think you have some incorrect assumptions in various replies here that are making it a bit harder to understand what your problem is:

"Regarding webview: No, it´s the other way around: The webview bases itself on the stock browser." - this is not the case. It's exactly as I explained in comment #6. We maintain this code (including the stock AOSP browser before it was deleted), we know exactly how it works, I assure you :)
I'm not sure what you mean by the rest of your comment there as a result.


"I know that it worked on Nexus for tobiasjs, but that´s prolly because he´s so lucky to have a device with a more recent version of webview. I´ve already checked of installing Android System Webview latest version solves the problem, but not - I suppose mobile phones don´t allow you to change a core component right away like that. Hence, as a developer, this is not a solution, even if I´d be able to hack my way to an updated version on my own device."

This is also wrong. Since Android 5.0 the WebView is an updatable component (because we made OS changes to make it into one), and you absolutely can update it on your own device as long as it's Android 5.0 or later. Updating WebView is the expected solution, and hundreds of millions of devices update WebView every six weeks when we release a new version. There's no "hacking your way" - it's just a Play Store update.

Hi tome,

Thank you for replying and appologies for if it sounded as if I gave the impression that I don´t think you know how things work: At that point I was not aware that webview is a component that all chromium developers are highly skilled at. 
So, thank you for clarifying some of the things I´ve misunderstood. 
However, if webrtc in webview fails to receive video across all 6.0 devices I´ve tried, with or without the android system webview update, while succeeding in 5.1, AND the logcat from 6.0 shows a bunch of chromium related warnings and errors, it´s hard for someone not specialized in chromium and webview not to assume what I did, no? :)
Do you have any clue where I need to look for an answer to these problems then?

If you start by telling us exactly which browser app on what device and with which android version you're testing, we might be able to figure out what's going on.

Hi tome,

I got it all figured out and it´s pretty embarassingly simple and caused a big "doh" when I realized what the issue was. I had not carefully enough paid attention to the permissions for API 23+. Now that I´ve changed the code, the only thing I still need to figure out is that for some combinations of android devices, only one can invite the other for a webrtc call - not the opposite. For instance, if calling between 5.1 and 6.0, it´ll only work when 6.0 calls.
This should be easy to handle though. 
The other thing is that on 5.1, when leaving a webrtc page, such as https://appr.tc/ when in a call with someone using 6.0 (or firefox on PC), the browser will crash on 5.1. Between two 5.1 devices, this won´t happen. 
In this case I tried with the webview based browser in Cyanogenmod based 5.1.1, which is webview 39, the other 5.1 device was Genymotion and the same webview, then firefox v 52.0.2 on PC, 6.0 on genymotion with chrome webview version 57.

So, I tried to downgrade the webview on 6.0 to 44, that comes with the genymotion by default and bang - problem gone. I tried this on and off a few times, and the problem returned every time I reinstalled version 57 of the webview - on 6.0 that is, so NOT on the phone where the webview would crash, but on the on the other device. Apparently webview 57 sends something that webview 39 doesn´t like..

Then that sounds like we had a bug in old version of WebView; update the webview on the older device? WebView 39 is ancient and virtually no users run that any more (almost all L+ devices are on 50+)

Allright, that actually helped on my hardware lollipop device! In genymotion it´s possible to install a later version, but it´s still the old one being used. This of course is not a problem - what matters is how hardware devices behave. I´ll check tonight and see if my wifes marshmallow phone no longer kicks the lollipop webview on the lollipop phone :) Thanks!

Presumably genymotion is based on AOSP, which doesn't use the Google-branded WebView that can be updated from the Play Store? It's possible to build a new AOSP WebView just from the chromium source code, though. Genymotion could just update it. We also have binaries for a few AOSP versions available in AOSP already (you can just take the AOSP webview from android 7.0 and use it as a replacement for the one on android 5/6).

Well, in fact the phone on which I have Lollipop is using Cyanogenmod - also forked with AOSP. That phone is rooted, which they say Genymotion is as well, but perhaps in a different way. So I´m worrying that it´s only possible to upgrade the webview on lollipop on rooted hardware. Some people say that´s indeed the case: 

https://android.stackexchange.com/questions/139413/android-system-webview-installed-but-not-used-by-apps

All devices that ship with the Play Store preinstalled are configured to use the Google-branded WebView and get updates automatically from the Play Store.

Custom roms (and custom emulator builds like genymotion) might be configured any way; it's up to the people who built the custom rom to set it up how they want it, and you'd have to ask them how webview updates are expected to work. Many popular recent Cyanogen roms use the Google webview automatically if it's installed, or have an option somewhere to switch to it, but not all do.

People who make their own roms should be making sure there's some way for users to get WebView updates, since they're important for security, but we don't control that, it's up to them. The behaviour of custom roms has nothing to do with how it works on regular devices.

Anyway, I'm closing this, because it sounds like whatever issue there is was already fixed.