If we have a single held call, then it should be possible to hang it up
with 'Hangup' even if active calls exist. Only if multiple held calls
or a waiting call exists should we disallow the request due to possible
side-effects.
Some hardware returns an empty mcc/mnc operator during an operator scan
when no operators are found (e.g. on an LTE dongle in a non-LTE area).
This results in oFono mistaking trying to update a non-existent operator
object.
For reference:
ofonod[27532]: Device: < \r\n+NWSTATEIND: 4\r\n\r\n+COPS:
(0,"","","",255),,(0-4),(0-2)\r\n\r
\nOK\r\n
process 27532: arguments to dbus_message_new_signal() were incorrect,
assertion "_dbus_check_
is_valid_path (path)" failed in file dbus-message.c line 1289.
This is normally a bug in some application using the D-Bus library.
D-Bus not built with -rdynamic so unable to print a backtrace
For handled commands, in case the terminal response is not reported by
the modem, we must set the cancel_cmd variable so the command is
canceled properly.
This patch also modifies the behavior so that pending_cmd is freed,
since stk_proactive_command_cancel expects cancel_cmd to be set if
pending_cmd is not NULL.
Fix PTS test TP/TWC/BV-03-I [Call Waiting- Hold Active/Retrieve
Waiting Call or Held].
PTS test fails after receiving intermediate update of callheld indicator
with value 0 (no held call) before it receives update to value 1
(active and held calls). This is due to the non-atomic update of calls
status after call swap (moving first call to active state before moving
second one to hold state).
HFP 1.5 spec specifies that an update of callheld indicator to 1 should
be sent after AT+CHLD=2 command.
As oFono emulator sends +CIEV only if the indicator value changes, we
need to use an intermediate state for callheld indicator (2, all calls on
hold).
So, in case of multiple active calls, or an active call with an active
mutiparty call, force update of callheld indicator to 2.