1127113 - Not able to answer an incoming call

Status: RESOLVED WORKSFORME

(Firefox OS Graveyard :: Gaia::Dialer, defect)

Description

[Anshul]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.93 Safari/537.36

Steps to reproduce:

Power cycle the device and camp on the net work
Make a MT call to the device
Answer the call from device



Actual results:

Call answer option isn't working.


Expected results:

Call should be answered

Comment 1

[Anshul]

Attachment: android main logs

Comment 2

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

Needinfo Doug to investigate. 
Please call out if more information you need.

Comment 3

[Johan Lorenzo [:jlorenzo]]

Per the blocking flag and the metabug, I assume 2.2 is impacted. I am not able to reproduce on our last 2.2 internal build[1]. Anshul, would you mind giving more details about the build you tested? 

Clearing the nom while we have more details and are able to reproduce on our builds.

[1] Gaia-Rev        46b590648007d51a0406b21b1d6f98eba8e3898e
Gecko-Rev       https://hg.mozilla.org/releases/mozilla-b2g37_v2_2/rev/b03afde7e699
Build-ID        20150128162504
Version         37.0a2
Device-Name     flame
FW-Release      4.4.2
FW-Incremental  eng.cltbld.20150128.201416
FW-Date         Wed Jan 28 20:14:27 EST 2015
Bootloader      L1TC000118D0

Comment 4

[Anshul]

Gecko: b09b5066607b72a24db42d7c54b03a2824eea39f
Gaia: 46b590648007d51a0406b21b1d6f98eba8e3898e

Comment 5

[Johan Lorenzo [:jlorenzo]]

These commits are dated from 2 days ago. No smoketest reports called this issue out on the Flame since. Closing as invalid. Please reopen if you have more information.

Comment 6

[Anshul]

I am still seeing the issue so reopening to get someone from development team at Moz to take a look.

Comment 7

[Wesley Huang [:wesley_huang] (EPM) (NI me)]

triage: so far no one from Mozilla can reproduce. could you please share precise STR and then renominate?

Comment 8

[Anshul]

So finally I got to the bottom of the issue. The issue is that we are still using the old audio manager interface and not the new one introduced by bug 1072868. Which is all fine except that on the new hardware calling SetMicrophoneMute when the call is dialed or is incoming throws an error instead of ignoring the operation. This new behavior is technically more accurate as there is no reason dialer should be trying to mute the microphone when a call is being dialed. 

With bug 1072868 there is a check at [1] that ignores if the audio state is the same and therefore the issue is not seen. I am going to be filing a gaia bug to not call set microphone muted.

[1] http://lxr.mozilla.org/mozilla-central/source/dom/telephony/gonk/TelephonyAudioService.js#91