When remote device uses AVRCP to connect, expectation is that if the remote did not also connect A2DP and HFP, that the device would initiate these connections. This makes it possible for remote to simply press "Play" and have audio route to the headset. This feature is supported on Android. Not sure if this simply isn't supported, or if the feature is there but broken.
Hi! Ben, Please help to take a look. Thanks -- Keven
Jamin, please help check this bug. Thanks.
Assignee: nobody → jaliu
(In reply to Greg Grisco from comment #0) > When remote device uses AVRCP to connect, expectation is that if the remote > did not also connect A2DP and HFP, that the device would initiate these > connections. This makes it possible for remote to simply press "Play" and > have audio route to the headset. This feature is supported on Android. > > Not sure if this simply isn't supported, or if the feature is there but > broken. Hi Greg, I assume you're expecting that when the remote device initiated "incoming" AVRCP connection request and after AVRCP get connected, you expect that FXOS connects both HFP/A2DP profiles. I have some concerns about this design for HFP profile. Usually the remote device(headset/car kit) is trying to connect HFP profile back to FxOS phone if the phone is trying to connect at the same time, this creates HFP connection collision. If we implement this behavior, we need to tweak the delay time for different devices, otherwise it's easy to hit collision and results in connection failure, it happens on Android especially with car kits. Also as far as I know, based on the bluedroid AVRCP API connection state never reported to framework (see hardware/libhardware/include/bt_rc.h), so bluedroid stack will connect A2DP profile automatically to remote device after AVRCP connected if the remote device send AVRCP incoming request. This A2DP connection made by bluedroid stack, not Gecko. I think even iPhone won't establish HFP profile directly, if the remote device only sends AVRCP connection request. Regarding connection sequence, as depicted in "SIMULTANEOUS USE OF HFP, A2DP, AND AVRCP PROFILES white paper", Bluetooth SIG published: ++++++++++++++++++++ Recommendation 2: If both AVDTP and AVCTP protocols are being connected, then the order of connection establishment should be first the AVDTP signaling connection and then the AVCTP signaling connection. Motivation 2: If an AVRCP PLAY is received by the MP before an AVDTP connection is established, audio may begin to play on the MP and will not be streamed to the RD, resulting in the first few seconds being lost or being rendered at another location (e.g. a built-in speaker on the MP). Recommendation 10: --------> This can apply to current bluedroid behavior, if incoming AVRCP connection established, A2DP connection made. To start playback from RD, the AVRCP_PLAY command should be sent to the MP; the RD should not try to use AVDTP procedures to start playback. Motivation 10: Since the MP device has the knowledge what the next song will be, it can decide best what CODEC parameters have to be configured in RD initiated case. If only GAVDP procedures are used, the MP may have to reconfigure or release, establish and start with the best CODEC parameters for the next audio track. Recommendation 18: ----> Always connect HFP profile first! The HFP service level connection, AVDTP signaling and AVCTP signaling connections should be established depending on the actions taken when the user powers on the device, performs user action to establish a connection, or due to an internal event. This applies to AG_MP and HF_RD. The order of connection establishment should be HFP service level connection first, AVDTP signaling link connection next and AVCTP signaling connection last. Motivation 18: HFP SLC should be connected first since HFP has the highest priority and should be quickly available e.g. if a call is incoming or already active. For the order of AVDTP and AVCTP please see Motivation 2). ++++++++++++++++++++
Hi Greg, Thank you for reporting this issue. The behavior is not supported by FxOS. If the connection is established by FxOS, Gecko would initiate AVRCP, A2DP and HFP. However, if it's a incoming connection and the remote device only initiate AVRCP, Gecko wouldn't initiate other profiles automatically. Please refer to #comment 3 for more details. Hi Aaron, Do we have a plan to put this feature to v2.2, v3 or our backlog ? Please help us to triage this bug.
[Tracking Requested - why for this release]: Hi Greg, it's currently not supported. As new feature, we can plan to do in further timeline but not on 2.2 for now. Move this to tracking-b2g:backlog and we can nominate as next version's feature. Thanks, Aaron
blocking-b2g: 2.2? → ---
tracking-b2g: --- → backlog
Ok, thanks Aaron and Shawn.
(In reply to Greg Grisco from comment #6) > Ok, thanks Aaron and Shawn. No longer blocks: 1063044 -- Keven
Due to the explanation at #comment 3, this bug isn't blocker anymore. Reset Assignee to default.
Assignee: 6jamin → nobody
Firefox OS is not being worked on
Status: NEW → RESOLVED
Last Resolved: 8 months ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.