Steps to reproduce the problem:
1. Run the testCase.html in a https server and open it in Google Chrome.
2. Click in the start button (this will invoke getUserMedia). 
3. Click in stop button (this will stop all the tracks and clear all references)
4. By taking a heap snapshot in profiles (Developer tools) you can verify that the browser is still keeping references to MediaStreamTrack and MediaStream causing side effects in Android.

What is the expected behavior?
The references to MediaStreamTrack and MediaStream are supposed to be garbage collected.

What went wrong?
This is not causing any side effect for the desktop application, but on Android (Google Chrome and WebView), if you use getUserMedia selecting the headset earpiece, then even though all tracks are stopped, the phone will still not produce sounds using the speakerphone (even in other applications, e.g. youtube), until you close the concerned Google Chrome tab (Or webView).

It seems that the fact that those tracks are not garbage collected prevents Android to use the default rendering device in other apps.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 56.0.2924.87  Channel: stable
OS Version: 6.0.1
Flash Version: 

Maybe that the underlying problem is that Google Chrome (or the WebView) should not cause all sounds to be rendered by the same device when using getUSerMedia(). But this is more of a philosophical question!
 

Deleted: testCase.html 519 bytes

testCase.html 519 bytes View Download