Closed Bug 1027506 Opened 5 years ago Closed 5 years ago

[Bluetooth][PTS][Bluedroid][2.0] TC_AG_OOR_BV_01_I Failed

Categories

(Firefox OS Graveyard :: Bluetooth, defect)

ARM
Gonk (Firefox OS)
defect
Not set

Tracking

(blocking-b2g:2.0+, firefox31 wontfix, firefox32 fixed, firefox33 fixed, b2g-v2.0 fixed, b2g-v2.1 fixed)

VERIFIED FIXED
2.0 S5 (4july)
blocking-b2g 2.0+
Tracking Status
firefox31 --- wontfix
firefox32 --- fixed
firefox33 --- fixed
b2g-v2.0 --- fixed
b2g-v2.1 --- fixed

People

(Reporter: echang, Assigned: shawnjohnjr)

References

Details

Attachments

(2 files, 1 obsolete file)

Attached file TC_AG_OOR_BV_01_I.zip
### STR
Test case : TC_AG_OOR_BV_01_I started
	- SDP Service record for PTS: 'Handsfree HF' successfully registered
	- The IUT claims support for the following eSCO LMP packet types: EV3, 2-EV3, 
	- AT: SPP connect succeeded
	- AT: Service Level Connection established
	- AT: post SLC command sequence complete
	- AT: RING
	- AT: Received +CLIP: "0958028209",129
	- AT: Incoming call established
	- HCI: Audio Connection enabled
	- HCI: Audio Connection disabled
	- AT: Service Level Connection disabled
	- The IUT claims support for the following eSCO LMP packet types: EV3, 2-EV3, 
	- AT: SPP connect succeeded
	- AT: Service Level Connection established
	- FATAL ERROR (AT): (call = 1) received when (callsetup = 0)
	- MTC received unexpected EXIT message from AT component
	- HCI: Audio Connection enabled
	- AT: post SLC command sequence complete
	- HCI: Audio Connection disabled
	- AT: SPP disconnect succeeded
	- MTC: Test case ended
Final Verdict : Inconclusive

###
No next instruction when moving IUT in the range of PTS.

### Version
https://pvtbuilds.mozilla.org/pvt/mozilla.org/b2gotoro/nightly/mozilla-aurora-nexus-4/2014/06/2014-06-17-16-02-02/
Assignee: nobody → shuang
Target Milestone: --- → 2.0 S5 (4july)
I can reproduce this symptom while doing out-of-range by walk. When you walk back to range, you need to wait for PTS indicates you to re-establish connection. If you don't see this dialog, and try to establish connection by youself, you will see this symptom.
OK, the main problem is that while the second hfp connection established, the response of CIND replied incorrectly. call is active at the time but we report inactive.
This is related to Bluetooth hfp connection dropped, call array had been clear.
When HFP connection lost, we shall not consider SCO also get disconnected. Patch in bug 1027506 can fix this problem. Because it's possible BluetoothHFPManger::Reset() get called, and Audio state changed to disconnected, but SCO connection did not really get disconnected.
Comment on attachment 8444409 [details] [diff] [review]
Bug 1027506 - [bluedroid] Don't reset call array after HFP link lost

Review of attachment 8444409 [details] [diff] [review]:
-----------------------------------------------------------------

::: dom/bluetooth/bluedroid/hfp/BluetoothHfpManager.cpp
@@ +390,5 @@
> +BluetoothHfpManager::Reset()
> +{
> +  // Phone & Device CIND
> +  ResetCallArray();
> +  // Clear Sco state

super-nit: SCO
Attachment #8444409 - Flags: review?(echou) → review+
blocking-b2g: --- → 2.0?
blocking-b2g: 2.0? → 2.0+
https://hg.mozilla.org/mozilla-central/rev/70c1ffd52bb4
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.