Closed Bug 845660 Opened 11 years ago Closed 11 years ago

[Call] Proximity sensor shouldn't work on speaker/BT SCO mode in call.

Categories

(Firefox OS Graveyard :: Gaia::System, defect, P2)

ARM
Gonk (Firefox OS)
defect

Tracking

(blocking-b2g:leo+, b2g18 fixed, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 unaffected)

RESOLVED FIXED
1.1 QE1 (5may)
blocking-b2g leo+
Tracking Status
b2g18 --- fixed
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- unaffected

People

(Reporter: leo.bugzilla.gecko, Assigned: mchen)

References

Details

(Whiteboard: [TD-8943])

Attachments

(1 file)

Even though the speaker mode is ON during a call, proximity sensor still works.
Proximity sensor should not be worked in the speaker or bluetooth mode.

Thanks in advance
OS: Windows 7 → Gonk (Firefox OS)
Priority: -- → P2
Hardware: x86 → Other
Summary: Proximity sensor works with speaker mode in call. → [Call] Proximity sensor works with speaker mode in call.
blocking-b2g: --- → leo?
Hardware: Other → ARM
Component: General → DOM: Device Interfaces
Product: Boot2Gecko → Core
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
blocking-b2g: leo? → ---
needinfo? UX to confirm that proximity sensor is supposed to work during phone call when the speaker mode is on or bluetooth mode is on.
Flags: needinfo?(jcarpenter)
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Blocks: 858444
blocking-b2g: --- → leo?
Josh, do you have any comments on this one? We need your input. 
Thanks!
This is broken. The phone is not bumping against your face when in speaker mode (the point of that feature is that the phone is *not* against your face), and then when you try to interact with the phone in-call, the screen will go dark. Blocking+.
blocking-b2g: leo? → leo+
Flags: needinfo?(jcarpenter)
Assignee: nobody → mchen
Currently, we implemented the detection of closing face by proximity sensor on system app (screen_manager.js). So if we want to know the timing of enabling speaker mode, we need a specific Web API to know this. But currently there is no Web API can be used to register a callback or listen the event. (There is just a attribute for reading/writing - nsIDOMTelephony::speakerEnabled)

So we need a way to know the timing of speakerEnabled. 

Hi Hsin-Yi,

Am I right of there is no way to know the timing of speakerEnabled from Gaia?

Thanks
Flags: needinfo?(htsai)
Summary: [Call] Proximity sensor works with speaker mode in call. → [Call] Proximity sensor shouldn't work on speaker mode in call.
Whiteboard: [TD-8943]
Marco, sorry for the late reply. As you mentioned, current API only provides an attribute to set/get the speaker state, but no events are fired when the state changes.
Flags: needinfo?(htsai)
Attached patch Patch v1Splinter Review
Before calling turnScreenOff(), if SCO or speaker is enabled then just to skip it.

Thanks for the review.
Attachment #736717 - Flags: review?(timdream)
Attachment #736717 - Flags: review?(timdream) → review+
Summary: [Call] Proximity sensor shouldn't work on speaker mode in call. → [Call] Proximity sensor shouldn't work on speaker/BT SCO mode in call.
https://github.com/mozilla-b2g/gaia/commit/70c13d2f583c6578037b0b65c47cd55f2ce1ce1c
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Component: DOM: Device Interfaces → Gaia::System
Product: Core → Boot2Gecko
Target Milestone: --- → Leo QE1 (5may)
Uplifted 845660 to:
v1-train: 33581942ead5d424b7626c6197c33392948019c8
Haven't fixed the queries yet, so I'm using qawanted for now. Someone needs to see if this bug also reproduces on v1.01.
Keywords: qawanted
mlevin tested this and indicates that v1.01 in unaffected here.
(In reply to Jason Smith [:jsmith] from comment #14)
> mlevin tested this and indicates that v1.01 in unaffected here.

Tested on the following:
Inari Build ID: 20130418070206
Kernel Date: Feb 21
Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/0c76ef5f8677
Gaia: 64d5096e1746bd4b08bc1bf69844d164ac961970

Call screen stays active during an active call when placed near the ear. 
Tested both speaker mode, and bluetooth mode.

NOTE: Also tested an active call in normal (speaker and bluetooth off) mode. Call screen still stayed active when Inari was placed near the ear!
(In reply to mlevin from comment #15)
> (In reply to Jason Smith [:jsmith] from comment #14)
> > mlevin tested this and indicates that v1.01 in unaffected here.
> NOTE: Also tested an active call in normal (speaker and bluetooth off) mode.
> Call screen still stayed active when Inari was placed near the ear!

Hi mlevin,

Could you make sure that your device have a calibration file for proximity sensor or it doesn't work?

Please check whether the file as below is exist or not in your device.

 /data/misc/prox/prox_threshold.txt

Thanks.
(In reply to Marco Chen [:mchen] from comment #16)
> (In reply to mlevin from comment #15)
> > (In reply to Jason Smith [:jsmith] from comment #14)
> > > mlevin tested this and indicates that v1.01 in unaffected here.
> > NOTE: Also tested an active call in normal (speaker and bluetooth off) mode.
> > Call screen still stayed active when Inari was placed near the ear!
> 
> Hi mlevin,
> 
> Could you make sure that your device have a calibration file for proximity
> sensor or it doesn't work?
> 
> Please check whether the file as below is exist or not in your device.
> 
>  /data/misc/prox/prox_threshold.txt
> 
> Thanks.

Marco,

I checked 3 of our Inari devices using DDMS-ACT (Eclipse) and under file explorer I did not see this file within the prox folder. In fact there were no files under this folder.
Blocks: 863750
(In reply to mlevin from comment #17)
> Marco,
> 
> I checked 3 of our Inari devices using DDMS-ACT (Eclipse) and under file
> explorer I did not see this file within the prox folder. In fact there were
> no files under this folder.

If you did the replace of userdata.img into your inari device then the calibration file will be gone. Please refer to the same case on Bug 857484.

You can get calibration file from
  1. inari/unagi with Android OS.
  2. Ikura with Firefox OS provided by OEM partner (bug 857484) and ask OEM partner about how to perform calibration app.

If you still can't get calibration file, please let me know. I will try to figure out whether that file can be sent to you from me.
(In reply to Marco Chen [:mchen] from comment #18)
> (In reply to mlevin from comment #17)
> > Marco,
> > 
> > I checked 3 of our Inari devices using DDMS-ACT (Eclipse) and under file
> > explorer I did not see this file within the prox folder. In fact there were
> > no files under this folder.
> 
> If you did the replace of userdata.img into your inari device then the
> calibration file will be gone. Please refer to the same case on Bug 857484.
> 
> You can get calibration file from
>   1. inari/unagi with Android OS.
>   2. Ikura with Firefox OS provided by OEM partner (bug 857484) and ask OEM
> partner about how to perform calibration app.
> 
> If you still can't get calibration file, please let me know. I will try to
> figure out whether that file can be sent to you from me.

Marco,

Still cannot get the file.

1. Can you send?
2. Why is not there after our daily flash updates?
3. How do I install it once I receive it from you?

Thanks,
Matt.
> 1. Can you send?
I need to check whether there is any legal issue prevent Mozilla send this file to you first. If there is no any legal concern I can send to you.

> 2. Why is not there after our daily flash updates?
That file is under userdata partition and our FOTA doesn't update that partition.

3. How do I install it once I receive it from you?
You just put file into /data/misc/prox/prox_threshold.txt.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: