Proximity sensor is used before incoming call is answered

<awe> there's no direct signal
<awe> however if you monitor the call list
<awe> I think the data you need is conveyed in the Call properties
<sforshee> awe, so we'd have to poll it?
<awe> you'd need to monitor the call list, and once you have an associated call ID, you can monitor signals everytime the properties for that Call change
<awe> sforshee, I haven't looked at it too closely, you may be able to monitor the call list in a similar manner
<awe> so step 1 is figure out if a call has been created
<awe> and step 2 is watch for PropertyChanged events for any calls and if the status is active, you have an active call

I'm not sure this is solvable in powerd based on the signals from ofono. We have two different types of signals we can get. First comes from VoiceCallManager, CallAdded and CallRemoved. This is what we are using now. However, this is problematic because CallAdded fires when the incoming call is ringing, before you pick-up. That is in the purpose of this bug. We want proximity sensor enabled only when a call is active.

With that in mind, I looked into the PropertyChanged signal from VoiceCall. There are relevant States there that should solve this problem, namely "active" -> the call is in progress and "disconnected" -> the call hung-up. We also wrote code to use the state "alerting" which means that the outbound call is ringing, a point at which you'd probably have the phone up to your ear. This code all works great, until you deal with multiple calls.

As it turns out, when you take a call from party A, and then party B dials your number, you will only get 1 Active state change and 2 Disconnect state changes. We had planned on using a simple counter to track how many calls were in progress, if none were in progress, we'd disable the sensor, if > 0 were, we'd enable it. However since we only get 1 active signal in the case where you are on a call and another one comes in, the counter method will not work. Since each call is it's own object, I expected to get active signals from both calls.

Here is the dbus output, interspersed with what was happening.

(here I accept the incoming call)
signal sender=:1.25 -> dest=(null destination) serial=311 path=/ril_0/voicecall01; interface=org.ofono.VoiceCall; member=PropertyChanged
   string "State"
   variant string "active"
signal sender=:1.25 -> dest=(null destination) serial=312 path=/ril_0/voicecall01; interface=org.ofono.VoiceCall; member=PropertyChanged
   string "StartTime"
   variant string "2013-06-13T21:01:39+0000"

(here I accept the second incoming call, note there's no signals)

(here I hangup the first call)
signal sender=:1.25 -> dest=(null destination) serial=324 path=/ril_0/voicecall01; interface=org.ofono.VoiceCall; member=DisconnectReason
   string "remote"
signal sender=:1.25 -> dest=(null destination) serial=325 path=/ril_0/voicecall01; interface=org.ofono.VoiceCall; member=PropertyChanged
   string "State"
   variant string "disconnected"

(finally I hang up the second call)

signal sender=:1.25 -> dest=(null destination) serial=330 path=/ril_0/voicecall02; interface=org.ofono.VoiceCall; member=DisconnectReason
   string "remote"
signal sender=:1.25 -> dest=(null destination) serial=331 path=/ril_0/voicecall02; interface=org.ofono.VoiceCall; member=PropertyChanged
   string "State"
   variant string "disconnected"

Seth has reported that getting the phone to pick-up two calls does not always work, so keep that in mind when trying it.

After more investigation it was determined that the 2nd call really is not accepted. It has a 0 second log time and no signal. The ofono code looks good, so the issue appears to be simply that the phone cannot handle picking up a 2nd call. The changes were modified to handle only 1 call and a new bug, https://bugs.launchpad.net/powerd/+bug/1191033, was filed to track dealing with > 1 call.