Closed Bug 976458 Opened 10 years ago Closed 10 years ago

[Sora][BT][Music] Music play from MS after reset BT headset.

Categories

(Firefox OS Graveyard :: Bluetooth, defect, P1)

Product:
Firefox OS Graveyard
Component:
Bluetooth
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: sync-1, Assigned: shawnjohnjr)

Details

Attachments

(3 files)

adblog of this issue
22.51 KB, text/plain
Details
hcidump log of this issue
50.51 KB, text/plain
Details
hcidump log for comment 29
52.22 KB, text/plain
Details 
DEFECT DESCRIPTION:
  Music play from MS after reset BT headset. 
 
  REPRODUCING PROCEDURES:
  1. MS connect BT headset;
  2. Play music and music is from BT headset;
  3. Power off BT headset;
  4. Power on BT headset;
  5. BT headset can connect MS automatically but A2DP not active --> KO
  6. Play music;
  7. Music is from MS and not from BT headset.
 
  EXPECTED BEHAVIOUR:
  Music should be from BT headset.
The bt headset is Nokia BH-214
Attached file adblog of this issue — 

    
    

    
  


  

    
    

    
  
Does this reproduce on a 1.1 Buri device?
Component: General → Bluetooth
Flags: needinfo?(sync-1)

    
    

    
  
(In reply to Jason Smith [:jsmith] from comment #4)
> Does this reproduce on a 1.1 Buri device?

Buri doesn't support A2DP.
Flags: needinfo?(sync-1)

    
    

    
  
(In reply to Kunny Liu from comment #5)
> (In reply to Jason Smith [:jsmith] from comment #4)
> > Does this reproduce on a 1.1 Buri device?
> 
> Buri doesn't support A2DP.

To be clear, Buri is capable of supporting A2DP, but only with post-1.2 FirefoxOS.
Assignee: nobody → shuang

    
    

    
  
Is this bug compatibility bug or general bugs happened on every headsets?
Based on description and steps to reproduce step 2 and 3, Bluetooth headset shall reconnect actively to phone again after Power-Off-On headset. From the log, gecko did not get a2dp state changed. Either bluetooth headset does not reconnect a2dp profile or bluez stack does not handle a2dp connection request. If bluetooth headset does not reconnect a2dp, b2g phone shall not reconnect a2dp profile actively, it all depends on bluetooth headset behavior. Can bug reporter help to confirm their bluez stack actually reports a2dp state changed?

Note:
If b2g phone gets incoming hfp connection request first, after hfp connection completed, b2g phone would not initiate a2dp outgoing connection. It depends on bluetooth headset.

So we need to figure out why bluez does not get incoming a2dp connection request first.
Flags: needinfo?(sync-1)

    
    

    
  
This bug might need more input from bug reporter, and we can take further action based on information.

    
    

    
  
(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #7)
> Is this bug compatibility bug or general bugs happened on every headsets?
> Based on description and steps to reproduce step 2 and 3, Bluetooth headset
> shall reconnect actively to phone again after Power-Off-On headset. From the
> log, gecko did not get a2dp state changed. Either bluetooth headset does not
> reconnect a2dp profile or bluez stack does not handle a2dp connection
> request. If bluetooth headset does not reconnect a2dp, b2g phone shall not
> reconnect a2dp profile actively, it all depends on bluetooth headset
> behavior. Can bug reporter help to confirm their bluez stack actually
> reports a2dp state changed?
> 
> Note:
> If b2g phone gets incoming hfp connection request first, after hfp
> connection completed, b2g phone would not initiate a2dp outgoing connection.
> It depends on bluetooth headset.
> 
> So we need to figure out why bluez does not get incoming a2dp connection
> request first.

I have reproduced this bug on three headsets: Vondafone A2201, Nokia BH-214, Sky-Tone S8. And all headsets can connect Android devices with A2DP after power switch.

    
    

    
  
(In reply to Kunny Liu from comment #9)
> (In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #7)
> > Is this bug compatibility bug or general bugs happened on every headsets?
> > Based on description and steps to reproduce step 2 and 3, Bluetooth headset
> > shall reconnect actively to phone again after Power-Off-On headset. From the
> > log, gecko did not get a2dp state changed. Either bluetooth headset does not
> > reconnect a2dp profile or bluez stack does not handle a2dp connection
> > request. If bluetooth headset does not reconnect a2dp, b2g phone shall not
> > reconnect a2dp profile actively, it all depends on bluetooth headset
> > behavior. Can bug reporter help to confirm their bluez stack actually
> > reports a2dp state changed?
> > 
> > Note:
> > If b2g phone gets incoming hfp connection request first, after hfp
> > connection completed, b2g phone would not initiate a2dp outgoing connection.
> > It depends on bluetooth headset.
> > 
> > So we need to figure out why bluez does not get incoming a2dp connection
> > request first.
> 
> I have reproduced this bug on three headsets: Vondafone A2201, Nokia BH-214,
> Sky-Tone S8. And all headsets can connect Android devices with A2DP after
> power switch.
Thanks for your information. Can bug reporter help to confirm their bluez stack actually reports a2dp state changed in your Nokia BH-214 case? Gecko A2DP depends on bluez a2dp state changed. Because from logcat, I don't see any a2dp related log after hfp profile state changed.
blocking-b2g: --- → 1.3?

    
    

    
  
Because bluez stack already notify the remote device class is 0x240404 to gecko, so I think gecko can connect a2dp profile actively even if bluez does not get incoming a2dp connection request.

    
    

    
  
If you can confirm that bluez stack does not get incoming a2dp connection request in your case, we can discuss further. There is one reason not to connect a2dp actively and let bluetooth headset decide to reconnect back. There is no good measurement when blueooth headset initiates a2dp connection after hfp connection completed. Thus, connect a2dp profile actively might cause a2dp connection collision, and you need to handle various timing condition since there are so many different bluetoot accessories. As far as I know, iPhone would not initiate a2dp profile connection after incoming hfp connection. This is why we don't initiate a2dp connection actively since reconnection made from HF role is preferable. See whitepaper Simultaneous Use of HFP A2DP and AVRCP_WP_V11.

Again, it would be good if you can clarify all models you tested 'Vondafone A2201, Nokia BH-214, Sky-Tone S8' would not initiate a2dp connection and bluez does not get a2dp connection request. Since we need to identify this bug is to require Gecko Bluetooth behavior change or there is something else we need to take care.

    
    

    
  
Waiting for input on whether this is a headset problem or a gecko problem in order to make a blocking decision.

    
    

    
  
(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #12)
> If you can confirm that bluez stack does not get incoming a2dp connection
> request in your case, we can discuss further. There is one reason not to
> connect a2dp actively and let bluetooth headset decide to reconnect back.
> There is no good measurement when blueooth headset initiates a2dp connection
> after hfp connection completed. Thus, connect a2dp profile actively might
> cause a2dp connection collision, and you need to handle various timing
> condition since there are so many different bluetoot accessories. As far as
> I know, iPhone would not initiate a2dp profile connection after incoming hfp
> connection. This is why we don't initiate a2dp connection actively since
> reconnection made from HF role is preferable. See whitepaper Simultaneous
> Use of HFP A2DP and AVRCP_WP_V11.
> 
> Again, it would be good if you can clarify all models you tested 'Vondafone
> A2201, Nokia BH-214, Sky-Tone S8' would not initiate a2dp connection and
> bluez does not get a2dp connection request. Since we need to identify this
> bug is to require Gecko Bluetooth behavior change or there is something else
> we need to take care.

Could you please tell me where can I add log in bluez code to make sure that bluez does not get a2dp connection request.
From current log of bluez, I can't find any message about A2DP when bluetooth headset power on.

    
    

    
  
Really? Because I tested on Sora and I saw bluez log prints out if there is an incoming a2dp connection. It should be something like this.

 43 02-26 15:46:34.342 D/--bluez--( 1526): avdtp_confirm_cb --> AVDTP: incoming connect from 00:21:3C:86:0E:CE
 44 02-26 15:46:34.342 D/--bluez--( 1526): sink_set_state --> State changed /org/bluez/1526/hci0/dev_00_21_3C_86_0E_CE: SINK_STATE_DISCONNECTED -> SINK_STATE_CONNECTING
 45 02-26 15:46:34.342 D/--bluez--( 1526): agent_authorize --> authorize request was sent for /org/bluez/1526/hci0/dev_00_21_3C_86_0E_CE
 46 02-26 15:46:34.392 D/--bluez--( 1526): avdtp_connect_cb --> AVDTP: connected signaling channel to 00:21:3C:86:0E:CE
 47 02-26 15:46:34.392 D/--bluez--( 1526): avdtp_connect_cb --> AVDTP imtu=672, omtu=895
 48 02-26 15:46:34.392 D/--bluez--( 1526): read_special_map_devaddr --> category avrcp_delay is not available in iop file
 49 02-26 15:46:34.932 D/--bluez--( 1526): avctp_set_state --> AVCTP Connecting
 50 02-26 15:46:34.992 D/--bluez--( 1526): avctp_connect_cb --> AVCTP: connected to 00:21:3C:86:0E:CE
 51 02-26 15:46:34.992 D/EventHub(  288): No input device configuration file found for device 'AVRCP'.
 52 02-26 15:46:34.992 D/--bluez--( 1526): init_uinput --> AVRCP: uinput initialized for 00:21:3C:86:0E:CE
 53 02-26 15:46:35.002 D/--bluez--( 1526): avctp_set_state --> AVCTP Connected
 54 02-26 15:46:35.022 I/EventHub(  288): New device: id=10, fd=92, path='/dev/input/event7', name='AVRCP', classes=0x80000001, configuration='', keyLayout='/system/usr/    keylayout/AVRCP.kl', keyCharacterMap='/system/usr/keychars/Generic.kcm', builtinKeyboard=false, usingSuspendBlockIoctl=true, usingClockIoctl=true
 55 02-26 15:46:35.022 I/InputReader(  288): Device added: id=10, name='AVRCP', sources=0x00000101
 56 02-26 15:46:37.992 D/--bluez--( 1526): avdtp_ref --> 0xb6f61ef8: ref=2
 57 02-26 15:46:38.032 D/--bluez--( 1526): session_cb --> 
 58 02-26 15:46:38.032 D/--bluez--( 1526): avdtp_parse_resp --> DISCOVER request succeeded
 59 02-26 15:46:38.032 D/--bluez--( 1526): avdtp_discover_resp --> seid 1 type 1 media 0 in use 0
 60 02-26 15:46:38.042 D/--bluez--( 1526): session_cb --> 
 61 02-26 15:46:38.042 D/--bluez--( 1526): avdtp_parse_resp --> GET_CAPABILITIES request succeeded
 62 02-26 15:46:38.042 D/--bluez--( 1526): avdtp_get_capabilities_resp --> seid 1 type 1 media 0

    
    

    
  
So is this a BT issue?
Flags: needinfo?(shuang)

    
    

    
  
As Comment 13 mentioned, we need more input from reporter.
Flags: needinfo?(shuang)

    
    

    
  
Sorry, i made a mistake， I found “Sky-tone S8” can connect A2DP profile by correct operation, I made it always into pairing status before.

There are two bluez log of "Nokia BH-214" and "Sky-tone S8" when headset power on:
"Nokia BH-214":
D/--bluez--( 1587): mgmt_event --> cond 1
D/--bluez--( 1587): mgmt_event --> Received 15 bytes from management socket
D/--bluez--( 1587): mgmt_event --> Opcode: 0x17
D/--bluez--( 1587): mgmt_remote_class --> hci0 addr 00:0B:E4:97:FD:94, class 0x240404
D/--bluez--( 1587): mgmt_event --> cond 1
D/--bluez--( 1587): mgmt_event --> Received 13 bytes from management socket
D/--bluez--( 1587): mgmt_event --> Opcode: 0xb
D/--bluez--( 1587): mgmt_device_connected --> hci0 device 00:0B:E4:97:FD:94 connected
I/GeckoBluetooth(  290): EventFilter --> EventFilter: org.bluez.Device, /org/bluez/1587/hci0/dev_00_0B_E4_97_FD_94, PropertyChanged
I/GeckoBluetooth( 1457): Notify --> [D] Notify: PropertyChanged
I/GeckoBluetooth( 1457): Notify --> [D] Notify: PropertyChanged
D/--bluez--( 1587): mgmt_event --> cond 1
D/--bluez--( 1587): mgmt_event --> Received 17 bytes from management socket
D/--bluez--( 1587): mgmt_event --> Opcode: 0x18
D/--bluez--( 1587): mgmt_event --> cond 1
D/--bluez--( 1587): mgmt_event --> Received 20 bytes from management socket
D/--bluez--( 1587): mgmt_event --> Opcode: 0x19
D/--bluez--( 1587): mgmt_event --> cond 1
D/--bluez--( 1587): mgmt_event --> Received 262 bytes from management socket
D/--bluez--( 1587): mgmt_event --> Opcode: 0x13
D/--bluez--( 1587): mgmt_remote_name --> hci0 addr 00:0B:E4:97:FD:94, name Nokia BH-214
D/--bluez--( 1587): btd_event_remote_name --> 
D/--bluez--( 1587): adapter_resolve_names --> cur: 0
D/--bluez--( 1587): adapter_resolve_names --> dev: 0x0
D/--bluez--( 1587): mgmt_event --> cond 1
D/--bluez--( 1587): mgmt_event --> Received 13 bytes from management socket
D/--bluez--( 1587): mgmt_event --> Opcode: 0x16
D/--bluez--( 1587): mgmt_encrypt_change_event --> hci0 00:0B:E4:97:FD:94 encrypt change event
D/--bluez--( 1587): mgmt_event --> cond 1
D/--bluez--( 1587): mgmt_event --> Received 13 bytes from management socket
D/--bluez--( 1587): mgmt_event --> Opcode: 0x16
D/--bluez--( 1587): mgmt_encrypt_change_event --> hci0 00:0B:E4:97:FD:94 encrypt change event

===================================================================================================
"Sky-tone S8":
D/--bluez--( 1587): avdtp_confirm_cb --> AVDTP: incoming connect from 00:11:6C:09:F1:30
D/--bluez--( 1587): sink_set_state --> State changed /org/bluez/1587/hci0/dev_00_11_6C_09_F1_30: SINK_STATE_DISCONNECTED -> SINK_STATE_CONNECTING
D/--bluez--( 1587): agent_authorize --> authorize request was sent for /org/bluez/1587/hci0/dev_00_11_6C_09_F1_30
D/--bluez--( 1587): avdtp_connect_cb --> AVDTP: connected signaling channel to 00:11:6C:09:F1:30
D/--bluez--( 1587): avdtp_connect_cb --> AVDTP imtu=672, omtu=895
D/--bluez--( 1587): read_special_map_devaddr --> category avrcp_delay is not available in iop file
D/--bluez--( 1587): avctp_set_state --> AVCTP Connecting
D/--bluez--( 1587): avctp_connect_cb --> AVCTP: connected to 00:11:6C:09:F1:30
D/EventHub(  290): No input device configuration file found for device 'AVRCP'.
D/--bluez--( 1587): init_uinput --> AVRCP: uinput initialized for 00:11:6C:09:F1:30
D/--bluez--( 1587): avctp_set_state --> AVCTP Connected
I/EventHub(  290): New device: id=13, fd=124, path='/dev/input/event9', name='AVRCP', classes=0x80000001, configuration='', keyLayout='/system/usr/keylayout/AVRCP.kl', keyCharacterMap='/system/usr/keychars/Generic.kcm', builtinKeyboard=false, usingSuspendBlockIoctl=true, usingClockIoctl=true
I/InputReader(  290): Device added: id=13, name='AVRCP', sources=0x00000101
D/--bluez--( 1587): avdtp_ref --> 0xb8e041e0: ref=2
D/--bluez--( 1587): session_cb --> 
D/--bluez--( 1587): avdtp_parse_resp --> DISCOVER request succeeded
D/--bluez--( 1587): avdtp_discover_resp --> seid 1 type 1 media 0 in use 0
D/--bluez--( 1587): session_cb --> 
D/--bluez--( 1587): avdtp_parse_resp --> GET_CAPABILITIES request succeeded
D/--bluez--( 1587): avdtp_get_capabilities_resp --> seid 1 type 1 media 0
D/--bluez--( 1587): discovery_complete --> Discovery complete
D/--bluez--( 1587): avdtp_ref --> 0xb8e041e0: ref=3
D/--bluez--( 1587): setup_ref --> 0xb8e04af8: ref=1
D/--bluez--( 1587): a2dp_read_edrcapability --> remote device version is 6
D/--bluez--( 1587): a2dp_config --> a2dp_config: selected SEP 0xb8defb60
D/--bluez--( 1587): setup_ref --> 0xb8e04af8: ref=2
D/--bluez--( 1587): avdtp_set_configuration --> 0xb8e041e0: int_seid=1, acp_seid=1
D/--bluez--( 1587): setup_unref --> 0xb8e04af8: ref=1
D/--bluez--( 1587): session_cb --> 
D/--bluez--( 1587): avdtp_parse_resp --> SET_CONFIGURATION request succeeded
D/--bluez--( 1587): setconf_cfm --> Source 0xb8defb60: Set_Configuration_Cfm
D/--bluez--( 1587): avdtp_sep_set_state --> stream state changed: IDLE -> CONFIGURED
D/--bluez--( 1587): update_streaming_device -->  0xb8e046e0 0
D/--bluez--( 1587): session_cb --> 
D/--bluez--( 1587): avdtp_parse_resp --> OPEN request succeeded
D/--bluez--( 1587): avdtp_connect_cb --> AVDTP: connected transport channel to 00:11:6C:09:F1:30
D/--bluez--( 1587): handle_transport_connect --> Flushable packets enabled
D/--bluez--( 1587): handle_transport_connect --> sk 23, omtu 895, send buffer size 81920
D/--bluez--( 1587): open_cfm --> Source 0xb8defb60: Open_Cfm
D/--bluez--( 1587): stream_setup_complete --> Stream successfully created
D/--bluez--( 1587): setup_unref --> 0xb8e04af8: ref=0
D/--bluez--( 1587): setup_free --> 0xb8e04af8
D/--bluez--( 1587): avdtp_unref --> 0xb8e041e0: ref=2
D/--bluez--( 1587): avdtp_sep_set_state --> stream state changed: CONFIGURED -> OPEN
D/--bluez--( 1587): sink_set_state --> State changed /org/bluez/1587/hci0/dev_00_11_6C_09_F1_30: SINK_STATE_CONNECTING -> SINK_STATE_CONNECTED
D/--bluez--( 1587): update_streaming_device -->  0xb8e046e0 0
D/--bluez--( 1587): server_cb --> Accepted new client connection on unix socket (fd=24)
D/--bluez--( 1587): control_cb --> Got 14 bytes of data for AVCTP session 0xb8e04b40
D/--bluez--( 1587): control_cb --> AVCTP transaction 1, packet type 0, C/R 0, IPID 0, PID 0x110E
D/--bluez--( 1587): control_cb --> AVRCP command 0x1, subunit_type 0x09, subunit_id 0x0, opcode 0x00, 8 operands
D/--bluez--( 1587): control_cb --> Got Vendor Dep opcode
D/--bluez--( 1587): control_cb --> Pdu id is PDU_GET_CAPABILITY_ID
D/--bluez--( 1587): control_cb --> Got 18 bytes of data for AVCTP session 0xb8e04b40
D/--bluez--( 1587): control_cb --> AVCTP transaction 2, packet type 0, C/R 0, IPID 0, PID 0x110E
D/--bluez--( 1587): control_cb --> AVRCP command 0x3, subunit_type 0x09, subunit_id 0x0, opcode 0x00, 12 operands
D/--bluez--( 1587): control_cb --> Got Vendor Dep opcode
D/--bluez--( 1587): control_cb --> Got 18 bytes of data for AVCTP session 0xb8e04b40
D/--bluez--( 1587): control_cb --> AVCTP transaction 3, packet type 0, C/R 0, IPID 0, PID 0x110E
D/--bluez--( 1587): control_cb --> AVRCP command 0x3, subunit_type 0x09, subunit_id 0x0, opcode 0x00, 12 operands
D/--bluez--( 1587): control_cb --> Got Vendor Dep opcode
D/--bluez--( 1587): control_cb --> playback position req for 1

===========================================================================
So, I think this issue is a headset problem. Thanks for your support!

    
    

    
  
Sounds like we close this out then.
Status: NEW → RESOLVED
blocking-b2g: 1.3? → ---
Closed: 10 years ago
Flags: needinfo?(sync-1)
Resolution: --- → INVALID

    
    

    
  
But there is still a problem, I have reproduced this issue on iPhone5 with "Nokia BH-214", and "Nokia BH-214" can connect A2DP after power off power on.

    
    

    
  
(In reply to Kunny Liu from comment #20)
> But there is still a problem, I have reproduced this issue on iPhone5 with
> "Nokia BH-214", and "Nokia BH-214" can connect A2DP after power off power on.
Did you see a2dp incoming connection request from the logcat if you tried with Sora and BH-214? I don't have Nokia BH-214 headset at hand, so still need your input.

    
    

    
  
Sorry, I don't know how to get the log of iOS.

    
    

    
  
(In reply to Kunny Liu from comment #18)
> Sorry, i made a mistake， I found “Sky-tone S8” can connect A2DP profile by
> correct operation, I made it always into pairing status before.
> 
> There are two bluez log of "Nokia BH-214" and "Sky-tone S8" when headset
> power on:
> "Nokia BH-214":
> D/--bluez--( 1587): mgmt_event --> cond 1
> D/--bluez--( 1587): mgmt_event --> Received 15 bytes from management socket
> D/--bluez--( 1587): mgmt_event --> Opcode: 0x17
> D/--bluez--( 1587): mgmt_remote_class --> hci0 addr 00:0B:E4:97:FD:94, class
> 0x240404
> D/--bluez--( 1587): mgmt_event --> cond 1
> D/--bluez--( 1587): mgmt_event --> Received 13 bytes from management socket
> D/--bluez--( 1587): mgmt_event --> Opcode: 0xb
> D/--bluez--( 1587): mgmt_device_connected --> hci0 device 00:0B:E4:97:FD:94
> connected
> I/GeckoBluetooth(  290): EventFilter --> EventFilter: org.bluez.Device,
> /org/bluez/1587/hci0/dev_00_0B_E4_97_FD_94, PropertyChanged
> I/GeckoBluetooth( 1457): Notify --> [D] Notify: PropertyChanged
> I/GeckoBluetooth( 1457): Notify --> [D] Notify: PropertyChanged
> D/--bluez--( 1587): mgmt_event --> cond 1
> D/--bluez--( 1587): mgmt_event --> Received 17 bytes from management socket
> D/--bluez--( 1587): mgmt_event --> Opcode: 0x18
> D/--bluez--( 1587): mgmt_event --> cond 1
> D/--bluez--( 1587): mgmt_event --> Received 20 bytes from management socket
> D/--bluez--( 1587): mgmt_event --> Opcode: 0x19
> D/--bluez--( 1587): mgmt_event --> cond 1
> D/--bluez--( 1587): mgmt_event --> Received 262 bytes from management socket
> D/--bluez--( 1587): mgmt_event --> Opcode: 0x13
> D/--bluez--( 1587): mgmt_remote_name --> hci0 addr 00:0B:E4:97:FD:94, name
> Nokia BH-214
> D/--bluez--( 1587): btd_event_remote_name --> 
> D/--bluez--( 1587): adapter_resolve_names --> cur: 0
> D/--bluez--( 1587): adapter_resolve_names --> dev: 0x0
> D/--bluez--( 1587): mgmt_event --> cond 1
> D/--bluez--( 1587): mgmt_event --> Received 13 bytes from management socket
> D/--bluez--( 1587): mgmt_event --> Opcode: 0x16
> D/--bluez--( 1587): mgmt_encrypt_change_event --> hci0 00:0B:E4:97:FD:94
> encrypt change event
> D/--bluez--( 1587): mgmt_event --> cond 1
> D/--bluez--( 1587): mgmt_event --> Received 13 bytes from management socket
> D/--bluez--( 1587): mgmt_event --> Opcode: 0x16
> D/--bluez--( 1587): mgmt_encrypt_change_event --> hci0 00:0B:E4:97:FD:94
> encrypt change event
> 
> =============================================================================


I did not see Nokia BH-214 HFP/A2DP connection logs here. Nothing happened here.
Maybe you copy/paste wrong section?

    
    

    
  
(In reply to Kunny Liu from comment #22)
> Sorry, I don't know how to get the log of iOS.
Oh. You misunerstood me. See Comment 23, I did not see both HFP/A2DP connection request log from bluez side. So this is something you can check from bluez side.

    
    

    
  
(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #21)
> (In reply to Kunny Liu from comment #20)
> > But there is still a problem, I have reproduced this issue on iPhone5 with
> > "Nokia BH-214", and "Nokia BH-214" can connect A2DP after power off power on.
> Did you see a2dp incoming connection request from the logcat if you tried
> with Sora and BH-214? I don't have Nokia BH-214 headset at hand, so still
> need your input.

As mentioned comment 18, if I use Sora and BH-214, bluez can't receive a2dp incoming connection request.
But I don't know why iPhone5 can connect A2DP with BH-214 after BH-214 power off and power on.

    
    

    
  
(In reply to Shawn Huang [:shuang] [:shawnjohnjr] from comment #23)

> Maybe you copy/paste wrong section?

It's all of logcat output when BH-214 power on.

    
    

    
  
I have test this issue of three Android devices with BH-214:
1. TCL idol x : can connect A2DP after headset reset.
2. Samsung GALAXY S4 : can't connect A2DP after headset reset.
3. Sony LT26i: can connect A2DP after headset reset.

I don't know is a headset problem or a b2g problem.

    
    

    
  
Under this circumstance, I think for the BH-214, we need to modify something in the BT stack in order to make it works for the re-connection case. But generally speaking I will say the mechanism for reconnecting after turn on/off the BT headset works fine. 

So I think we shouldn't nom this issue as 1.3 blocker, but we definitely need to keep checking this one. 

Thanks and let me know if you think otherwise

Vance

    
    

    
  
(In reply to Kunny Liu from comment #27)
> I have test this issue of three Android devices with BH-214:
> 1. TCL idol x : can connect A2DP after headset reset.
> 2. Samsung GALAXY S4 : can't connect A2DP after headset reset.
> 3. Sony LT26i: can connect A2DP after headset reset.
> 
> I don't know is a headset problem or a b2g problem.
I reviewed your log again. To clarify here, I think iPhone won't init a2dp connection after hfp connection completed. It shall depend on HF hehavior to recover connection. I believe Nokia BH-214 would recover connection. So the only thing I can suspect is bt stack SDP query part. As your hcidump log shows no avdtp connection request from headset. And this part is not related to gecko.

Please provide full hcidump log from the beginning.
It shall include:
1. Scan for device
2. Pair with BH-214
3. Connect BH-214 HFP/A2DP profile
4. Turn off/on BH-214
5. HFP connected but missing A2DP profile

    
    

    
  


  

    
    

    
  
stack seems reply <<uuid-16 0x111e (Handsfree) uint 0x105 >> twice time. This is strange.

< ACL data: handle 4 flags 0x00 dlen 44
    L2CAP(d): cid 0x0054 len 40 [psm 1]
        SDP SSA Rsp: tid 0x1 len 0x23
          count 32
          record #0
              aid 0x0009 (BTProfileDescList)
                 < < uuid-16 0x111e (Handsfree) uint 0x105 > >
          record #1
              aid 0x0009 (BTProfileDescList)
                 < < uuid-16 0x111e (Handsfree) uint 0x105 > >
          cont 00

    
    

    
  
Note - if this ends up being a bug in gecko, please reopen the bug.

    
    

    
  
Ok, I have fixed this issue in gaia. If the device support a2dp and gaia receive hfp connect but can't receive a2dp connect within 10s. Then make gaia connect this device again for a2dp connection.

    
    

    
  
(In reply to Kunny Liu from comment #33)
> Ok, I have fixed this issue in gaia. If the device support a2dp and gaia
> receive hfp connect but can't receive a2dp connect within 10s. Then make
> gaia connect this device again for a2dp connection.

device means bluetooth headset.

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: