Fix a race-condition that returns incorrect foreground call
The existing logic for maintaining the foreground call considers calls
in the held state. This causes a race condition when there are two
calls in the calls list, one in held state and one in dialing state.
The calls are maintained in a concurrent hash map in CallsManager and
iterated in a for loop to check and then decide on the foreground
call. Depending on the order in which the calls are present in this
data structure, the issue is seen. If the dialing call is present before
the held call in the list, the foreground call is overwritten to be the
held call.
The symptom of this issue is when ringback tone for an add call scenario
is not played in certain devices. This is because the logic for Ringback
tones makes sure that the call for which ringtone has to be played is
the foreground call. In the race condition, the foreground call points to
the held call and hence the ringtone for call in dialing state is not
played.
The fix for the issue to skip the calls in held state to be considered as
candidates for the foreground call.
Change-Id: Ia227da48728e4be87601a8faa07f94ad7bdbd2e5
CRs-Fixed: 913581
1 file changed