1156559 - A2DP and HFP are not initiated by device after remote AVRCP connection

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Bluetooth, defect)

Description

[Greg Grisco]

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.

Comment 1

[Keven Kuo [:kkuo]]

Hi! Ben,

Please help to take a look. Thanks

--
Keven

Comment 2

[Ben Tian (inactive)]

Jamin, please help check this bug. Thanks.

Comment 3

[Shawn Huang [:shawnjohnjr][:shuang] (as a happy gecko contributor)]

(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).
++++++++++++++++++++

Comment 4

[Jamin Liu [:jaliu][:Jamin]]

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.

Comment 5

[Aaron Wu]

[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

Comment 6

[Greg Grisco]

Ok, thanks Aaron and Shawn.

Comment 7

[Keven Kuo [:kkuo]]

(In reply to Greg Grisco from comment #6)
> Ok, thanks Aaron and Shawn.

No longer blocks: 1063044

--
Keven

Comment 8

[Jamin Liu [:jaliu][:Jamin]]

Due to the explanation at #comment 3, this bug isn't blocker anymore.
Reset Assignee to default.

Comment 9

[BMO Automation]

Firefox OS is not being worked on