889733 - [Bluetooth] Proximity sensor is not working when audio path is changed by HBS-700 headset

Status: RESOLVED FIXED

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

Description

[leo.bugzilla.gecko]

Step>
1. LG-HBS700 connect with b2g phone.
2. Make a active call.
3. Press the "+" volume button for 3 seconds.
4. Audio path is changed to handset from bluetooth PCM
5. Check the proximity sensor

Expected Results>
Proximity sensor is working well.

Actual Results>
Proximity sensor is not working.

It is HBS-700 headset feature that changed the audio path when long press + volume button.
Audio path is directly changed without any noti cause this feature, so proximity sensor is not working.
This bug seem to be make many trouble.

Please check this.
Thanks.

Comment 1

[Eric Chou [:ericchou] [:echou]]

I'll check tomorrow.

Comment 2

[Eric Chou [:ericchou] [:echou]]

Just tested with the latest v1.1 gecko/gaia and realized that the proximity sensor won't work right after Bluetooth headset is connected, which means you don't even need step 2~4. Once the Bluetooth connection is dropped, the proximity sensor works again.

Please note that no SCO connection is needed to reproduce this error. I've tried making a call during an ongoing Bluetooth file transfer session, the proximity sensor doesn't work either.

Comment 3

[Eric Chou [:ericchou] [:echou]]

ok, now I know what's going on here. When screen_manager.js gets the userproximity event from Gecko, it will check if there is a Bluetooth connection. If there is, then it will ignore that event and will not turn off the screen.

https://github.com/mozilla-b2g/gaia/blob/master/apps/system/js/screen_manager.js#L207

So, now the problem becomes: is it reasonable to keep the screen being turned on when Bluetooth headset is connected? We may need somebody to confirm this behavior. However, in my opinion, current behavior should be fine, otherwise users may be difficult switching the voice route from headset to handset or vice versa. I also tried my HTC Sensation XL and it wouldn't turn off the screen either.

Leo, please check my comment above and see if you still think this is an issue. All  suggestions will be welcome.

Thank you.

Comment 4

[leo.bugzilla.gecko]

Hi Eric,

There seems to be a misunderstanding.
It is right to keep the screen being turned on when Bluetooth headset is connected.

The point of this issue is HBS-700 headset.
This headset is possible to force the switch voice route if you click '+' button for 3 seconds.

In summery,

1. BT headset connected and make a call.
 -> The screen does not turn off(Proximity sensor does not work). OK.

2. Press the "+" volume button for 3 seconds during call. Then voice route is changed to handset from BT headset.
 -> Proximity sensor should work because current voice route is handset! But b2g phone does not recognize to change voice route. So voice route is handset but screen is keeping on.

This bug can be compatibility issues because b2g is not considered to change audio route to handset from BT. However, for user's convenience please check if it is modified.

HBS700 manual is described about this feature as below.

* Transferring a call
- If you make a call from the handset, the call will (depending on the phone settings) automatically transfer to the headset. If the call is not automatically transferred, you can manually transfer the call to, or from, the headset by pressing and holding VOLUME UP button for 3 seconds on the HBS-700 (handset and headset must be paired).

Comment 5

[Eric Chou [:ericchou] [:echou]]

> There seems to be a misunderstanding.
> It is right to keep the screen being turned on when Bluetooth headset is
> connected.
> 
> The point of this issue is HBS-700 headset.
> This headset is possible to force the switch voice route if you click '+'
> button for 3 seconds.
>
> In summery,
> 
> 1. BT headset connected and make a call.
>  -> The screen does not turn off(Proximity sensor does not work). OK.
> 
> 2. Press the "+" volume button for 3 seconds during call. Then voice route
> is changed to handset from BT headset.
>  -> Proximity sensor should work because current voice route is handset! But
> b2g phone does not recognize to change voice route. So voice route is
> handset but screen is keeping on.
> 
> This bug can be compatibility issues because b2g is not considered to change
> audio route to handset from BT. However, for user's convenience please check
> if it is modified.
> 
> HBS700 manual is described about this feature as below.
> 
> * Transferring a call
> - If you make a call from the handset, the call will (depending on the phone
> settings) automatically transfer to the headset. If the call is not
> automatically transferred, you can manually transfer the call to, or from,
> the headset by pressing and holding VOLUME UP button for 3 seconds on the
> HBS-700 (handset and headset must be paired).

There is no misunderstanding. The description is quite clear. Nevertheless, I think the HBS700 Bluetooth headset was not actually 'disconnected' at that moment after pressing '+' button for 3 secs. Only SCO was dropped. You could check the hcidump and see if my guess is right.

So, if it's the case, which means that only SCO is dropped but SLC still exists, do we need to turn off the screen? Like I said in comment 3, as long as the SLC exists, we should let users be able to switch audio route between headset and handset easily by tapping the icon on Dialer app. Therefore leaving the screen on seems more reasonable.

We need UX input for this. ni? Casey, our UX design engineer, for professional support.

Comment 6

[leo.bugzilla.gecko]

Hi Eric,

OK. I understood your comment. 
As you said, it is the case that only SCO dropped and SLC exist.
Then let's discuss about UX.

There seems to be two case of advantages and disadvantages.
If screen is turned on during SLC exist, switch audio route easily as you said.
But on the other hands users will be inconvenient to call because they should be close to their ear from phones, then the icons on Dialer app may be tapping unintentionally.

Please refer about this cases and I hope you find the best way in UX.
Thanks.

Comment 7

[Eric Chou [:ericchou] [:echou]]

(In reply to leo.bugzilla.gecko from comment #6)
> Hi Eric,
> 
> OK. I understood your comment. 
> As you said, it is the case that only SCO dropped and SLC exist.
> Then let's discuss about UX.
> 
> There seems to be two case of advantages and disadvantages.
> If screen is turned on during SLC exist, switch audio route easily as you
> said.
> But on the other hands users will be inconvenient to call because they
> should be close to their ear from phones, then the icons on Dialer app may
> be tapping unintentionally.
> 
> Please refer about this cases and I hope you find the best way in UX.
> Thanks.

Let's wait for our UX feedback. Thanks.

Comment 8

[leo.bugzilla.gecko]

This case is improvement for UX not a bug.
So I change leo? and I'll determine whether to apply in the future.

Comment 9

[Casey Yee]

(In reply to Eric Chou [:ericchou] [:echou] from comment #5)
> > 1. BT headset connected and make a call.
> >  -> The screen does not turn off(Proximity sensor does not work). OK.

In the case that a BT headset is connected and on a active call, the proximity sensor should not work (as already stated).   

The screen should however be able to turn off after a set period of time (so that it doesn't continue eating up battery).  

The screen should wake when:
- Pressing any physical buttons (inc. home and volume buttons)
- When call is initiated/ended.
- When call is transferred back to handset.

> > 
> > 2. Press the "+" volume button for 3 seconds during call. Then voice route
> > is changed to handset from BT headset.
> >  -> Proximity sensor should work because current voice route is handset! But
> > b2g phone does not recognize to change voice route. So voice route is
> > handset but screen is keeping on.

Makes sense to me :)


<snip>

> > 
> So, if it's the case, which means that only SCO is dropped but SLC still
> exists, do we need to turn off the screen? Like I said in comment 3, as long
> as the SLC exists, we should let users be able to switch audio route between
> headset and handset easily by tapping the icon on Dialer app. Therefore
> leaving the screen on seems more reasonable.
> 

If the audio is transferred back to the handset, the proximity sensor should be turned back On.  The screen on/off behavior should be as normal handset usage behavior.

I hope that all makes sense ;)

Comment 10

[Eric Chou [:ericchou] [:echou]]

(In reply to Casey Yee [:cyee] from comment #9)
> (In reply to Eric Chou [:ericchou] [:echou] from comment #5)
> > > 1. BT headset connected and make a call.
> > >  -> The screen does not turn off(Proximity sensor does not work). OK.
> 
> In the case that a BT headset is connected and on a active call, the
> proximity sensor should not work (as already stated).   
> 
> The screen should however be able to turn off after a set period of time (so
> that it doesn't continue eating up battery).  
> 
> The screen should wake when:
> - Pressing any physical buttons (inc. home and volume buttons)
> - When call is initiated/ended.
> - When call is transferred back to handset.
> 
> > > 
> > > 2. Press the "+" volume button for 3 seconds during call. Then voice route
> > > is changed to handset from BT headset.
> > >  -> Proximity sensor should work because current voice route is handset! But
> > > b2g phone does not recognize to change voice route. So voice route is
> > > handset but screen is keeping on.
> 
> Makes sense to me :)
> 
> 
> <snip>
> 
> > > 
> > So, if it's the case, which means that only SCO is dropped but SLC still
> > exists, do we need to turn off the screen? Like I said in comment 3, as long
> > as the SLC exists, we should let users be able to switch audio route between
> > headset and handset easily by tapping the icon on Dialer app. Therefore
> > leaving the screen on seems more reasonable.
> > 
> 
> If the audio is transferred back to the handset, the proximity sensor should
> be turned back On.  The screen on/off behavior should be as normal handset
> usage behavior.
> 
> I hope that all makes sense ;)

Thanks, Casey. I'm fine with both. When Bluetooth headset is connected but the audio is from the handset, either the proximity sensor is enabled or disabled are reasonable from different aspects. 

Hand this over to Arthur for further implementation. Thanks everyone. :)

Comment 11

[Gina Yeh [:gyeh] [:ginayeh]]

Per Arthur, we failed to receive system message of "bluetooth-sco-status-changed". Let me take a look at it and I'll file a bug to fix it, too.

Comment 12

[Arthur Chen [:arthurcc][inactive after 6/30]]

Attachment: link to https://github.com/mozilla-b2g/gaia/pull/10935

Alive, the patch aims to check bluetooth SCO status as an additional condition for ignoring proximity events. This patch depends on a gecko fix but we've already test it with an local build. Please help review it, thanks!

Comment 13

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 774453 [details]
link to https://github.com/mozilla-b2g/gaia/pull/10935

Basically r+ but please see github comments.
If the semantic of Bluetooth module in system is not as I think, please help to change it.

i.e., |Bluetooth.scoConnected| should imply |Bluetooth.connected| ?

Comment 14

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 774453 [details]
link to https://github.com/mozilla-b2g/gaia/pull/10935

Have an offline discussion w/ Arthur on this today.
I think it's worthy to be mentioned here:

In current Bluetooth object inside system, the following attributes are confusing:
Bluetooth.scoConnected, Bluetooth.hfpHspConnected, Bluetooth.oppConnected.

I think this makes other confusing because "sco"/"a2dp" is the headset channel type, hfp/hsp is protocol, opp is just indicating file transferring.

We should embed this more elegantly, no matter from gaia or gecko.

My proposal is let gaia wrap all this kind of Bluetooth spec-ed specific noun into a meaningful attribute name.

For example:

Bluetooth.isVoiceChannelConnecting // Indicate SCO
Bluetooth.isMediaChannelConnecting // Indicate A2DP
Bluetooth.connectingProtocol // HSP or HFP or ...
Bluetooth.isFileTransferring // OPP on
Bluetooth.connected // Indicate BT is connected or not.

I know less than you guys about BT and also that BT is a complex spec-ed stuff. Let's try to find out a balanced way to implement it between semantical and practical.

Comment 15

[leo.bugzilla.gecko]

I nominate leo- because it is not block issue.

Comment 16

[(inactive after 6/18) Alive Kuo [:alive]]

Another offline discussion and the conclusion: forget #14, and
Use Bluetooth.profile.SCO and Bluetooth.getCurrentProfiles to access those profiles.

Comment 17

[Arthur Chen [:arthurcc][inactive after 6/30]]

Comment on attachment 774453 [details]
link to https://github.com/mozilla-b2g/gaia/pull/10935

Alive, patch revised based on the discussion. Could you help review it again? Thanks!

Comment 18

[(inactive after 6/18) Alive Kuo [:alive]]

Comment on attachment 774453 [details]
link to https://github.com/mozilla-b2g/gaia/pull/10935

r=me. Hope this helps the following development progress...

Comment 19

[Arthur Chen [:arthurcc][inactive after 6/30]]

Alive, thanks for reviewing!

master: https://github.com/mozilla-b2g/gaia/commit/fabeff5e8326882284810943b0124a31bd07880a