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)
Tracking
(b2g-v2.0 affected, b2g-v2.1 affected, b2g-v2.2 affected)
RESOLVED
INVALID
People
(Reporter: SalvadorR, Unassigned)
References
Details
(Whiteboard: [2.1-flame-test-run-3])
Attachments
(1 file)
(deleted),
text/plain
|
Details |
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/
Reporter | ||
Comment 1•10 years ago
|
||
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
Reporter | ||
Comment 5•10 years ago
|
||
Android and iphone functions the same way. I believe this is by design.
Flags: needinfo?(srapanan)
Blocks: 1055347
You need to log in
before you can comment on or make changes to this bug.
Description
•