Build Information Gaia ef66efa34ed8a559c8998bde688fae88eb943a7a Gecko https://hg.mozilla.org/mozilla-central/rev/b40296602083 BuildID 20140522040230 Version 32.0a1 ro.build.version.incremental=94 ro.build.date=Tue May 20 09:29:20 CST 2014 Steps to reproduce Connect a BT headset Make a phone call => Verify that the sound is coming from the headset Activate speaker => Verify that the sound is coming from the speaker only Switch to BT headset again Actual result The sound is coming from the phone. Expected result The sound should come from the BT heaset again Reproducibility rate: 100%

QA Wanted to see if it's reproducible on 1.4 and on Buri.

The Flame switches to the Bluetooth device correctly but the device freezes after connected. This issue DOES reproduce on Buri 2.0 Environmental Variables: Device: Flame 1.4 Build ID: 20140609000201 Gaia: 8b239e41bbd85aa7b6a2c5d388e775ba7de6fb2b Gecko: e3f85877db29 Version: 30.0 (1.4) MOZ Firmware Version: v10G-2 Environmental Variables: Device: Buri 2.0 Build ID: 20140609040203 Gaia: 12af93123c5db55212d51fe235d39f21209a1eaa Gecko: 9305a8ec77fe Version: 32.0a1 (2.0) MOZ Firmware Version: v1.2device.cfg Flame 1.4: Call is placed and is directed through Bluetooth headset but Device freezes. Buri 2.0: Call switches from Bluetooth to speaker, but remains on the Device speaker rather than Bluetooth when switched again.

Waw! What about Buri 1.4?

This issue DOES reproduce on Buri 1.4 1.4 Environmental Variables: Device: Buri 1.4 Build ID: 20140610063002 Gaia: c39db439202b29897bee9896bc789e6782809f3a Gecko: edd648be2b07 Version: 30.0 (1.4) MOZ Firmware Version: v1.2device.cfg User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0

Does the device freeze? Or does the call remain on the speaker on Buri 1.4?

The device does not freeze. The call remains on speaker on the Buri 1.4.

I need this written up more clearly. The freeze is a separate problem that should be filed separately, so let's get a different bug on file for that. For the bug described in comment 0 - is this happening on 1.3 & 1.4?

This issue DOES reproduce on Buri 1.4 1.4 Environmental Variables: Device: Buri 1.4 Build ID: 20140612063006 Gaia: 80bf1039c6ce8bcde57ce06ecb09e40c18c538c6 Gecko: 39b6237907d9 Version: 30.0 (1.4) Firmware Version: v1.2device.cfg User Agent: Mozilla/5.0 (Mobile; rv:30.0) Gecko/30.0 Firefox/30.0 This issue DOES NOT reproduce on Buri 1.3. User is able to switch between the bluetooth headset and speaker phone. 1.3 Environmental Variables: Device: Buri 1.3 Build ID: 20140612002831 Gaia: 20cce4e5dd3ca7dfffc82ce1dce71741dd446952 Gecko: 233d0d0ea774 Version: 28.0 (1.3) Firmware Version: v1.2device.cfg User Agent: Mozilla/5.0 (Mobile; rv:28.0) Gecko/28.0 Firefox/28.0

Buri 2.0 = Repro Buri 1.4 = Repro Buri 1.3 = No repro QA-Wanted : let's get a regression window

Blocking as this is a basic functional bug..

This might be a gaia issue. The main operation is in call_screen.js and calls_handler.js: // Menu item of switch voice to bluetooth device switchToDeviceButton: document.getElementById('btmenu-btdevice'), // Register the handler function to click event this.switchToDeviceButton.addEventListener('click', this.switchToDefaultOut.bind(this)); // Please pay attention to the parameter 'doNotConnect', it is an 'MouseEvent object' // once the function is triggered as the callback of click event switchToDefaultOut: function cs_switchToDefaultOut(doNotConnect) { this.speakerButton.classList.remove('active-state'); this.bluetoothButton.classList.add('active-state'); CallsHandler.switchToDefaultOut(doNotConnect); this.toggleBluetoothMenu(false); }, // Here, the param 'doNotConnect' transferred must be the 'MouseEvent object' // and then the judgement '!doNotConnect' in following function must always // be false, so that we will never have a chance to connect BT Sco. function switchToDefaultOut(doNotConnect) { if (telephony.speakerEnabled) { telephony.speakerEnabled = false; } if (!doNotConnect) { // add a btHelper.isConnected() check before calling disconnectSco // once bug 929376 lands. btHelper.connectSco(); } } The above is my analysis of the issue based on branch v1.4, i think we'd better ask for etienne's opinion. Could you please help check my comments on this and let me know if there's something wrong. Thanks a lot.