Closed Bug 1079437 Opened 10 years ago Closed 10 years ago

[Bluetooth] When listening to music through bluetooth headphones and moving back into bluetooth range, music does not resume.

Categories

(Firefox OS Graveyard :: Bluetooth, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 affected)

RESOLVED INVALID
Tracking Status
b2g-v2.0 --- affected
b2g-v2.1 --- affected
b2g-v2.2 --- affected

People

(Reporter: SalvadorR, Unassigned)

References

Details

(Whiteboard: [2.1-flame-test-run-3])

Attachments

(1 file)

Attached file logcat_20141007_1141.txt (deleted) —
Description: When DUT is connected to bluetooth headset, if user listens to music and moves out of bluetooth range, the music will not resume to where the song left off at. Pre-requisite: Have a bluetooth headset paired to DUT and a song Repro Steps: 1) Update a Flame device to BuildID: 20141006000205 2) While be paired with the bluetooth headset device, play a song 3) While the song is playing, move away from the the DUT while wearing the bluetooth headset until the bluetooth is out of range 4) When out of range of bluetooth, move back to bluetooth range 5) Observe behavior of bluetooth headset Actual: Bluetooth does not resume song, when coming back to bluetooth range Expected: Bluetooth resumes song, when coming back to bluetooth range Environmental Variables: Device: Flame 2.1 BuildID: 20141006000205 Gaia: 778ebac47554e1c4b7e9a952d73e850f58123914 Gecko: c4a4b04c617c Gonk: 2c909e821d107d414f851e267dedcd7aae2cebf Version: 34.0a2 (2.1) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Notes: This issue was tested with 3 different bluetooth headsets Repro frequency: 5/5 Link to failed test case: https://moztrap.mozilla.org/manage/case/9033/
This issue also occurs on Flame 2.0 KK (319mb) and Flame 2.2 KK (319mb) Actual: Bluetooth does not resume song, when coming back to bluetooth range Flame 2.0 KitKat Base (319mb)(Full Flash) Environmental Variables: Device: Flame 2.0 Build ID: 20141006000202 Gaia: 092d2b7678774c8b0b06dca0e0a8119e9eafdec3 Gecko: 69ca61f7edf3 Version: 32.0 (2.0) Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Flame 2.2 KitKat Base (319mb)(Full Flash) Environmental Variables: Device: Flame 2.2 Master BuildID: 20141007040205 Gaia: 83de447d9ae9a59459d7a445f9348a254c661850 Gecko: 9ee9e193fc48 Gonk: 2c909e821d107d414f851e267dedcd7aae2cebf Version: 35.0a1 (2.2 Master) Firmware: V180 User Agent: Mozilla/5.0 (Mobile; rv:35.0) Gecko/35.0 Firefox/35.0
QA Whiteboard: [QAnalyst-Triage?]
Flags: needinfo?(dharris)
For out-of-range case, we won't do reconnect by polling a2dp devices, as usual case, the user needs to manually trigger bluetooth headset reconnection (usually by pressing play button or call button). Can you get reference devices (Android phones/iPhone) to confirm again?
Flags: needinfo?(srapanan)
Not blocking on this case as the user can manually play the music again once in range. This also might be expected based on comment 2
QA Whiteboard: [QAnalyst-Triage?] → [QAnalyst-Triage+]
Flags: needinfo?(dharris)
Because we won't do polling to connect to A2DP (we cannot predict when A2DP device is available), as most phones won't do that, so I think this design make sense.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → INVALID
Android and iphone functions the same way. I believe this is by design.
Flags: needinfo?(srapanan)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: