Upgrade to ofono 1.17
Some of the commits look quite useful and yet the whole thing doesn't seem to be particularly destructive (unlike what started happening after 1.17).
See merge request !24
Accept push notifications regardless of the origin port, as some
operators do not insert there the WAP connectionless session service
port, and use random values instead.
Private connection should be properly closed with dbus_connection_close
otherwise libdbus exits with the following error:
'The last reference on a connection was dropped without closing the
connection. This is a bug in an application. See
dbus_connection_unref() documentation for details. Most likely, the
application was supposed to call dbus_connection_close(), since this
is a private connection.'
Passing NULL format parameter to vsnprintf results in invalid argument
error on glibc. But with some other libc libraries (musl and uClibc)
this results in dereferencing NULL pointer and crash due to
segmentation fault.
GDBusClient currently hard-codes "/" as the remote ObjectManager path.
This is generally incorrect, as an application can choose to expose an
ObjectManager at any well-known path. This patch fixes this by allowing
the user to pass in the ObjectManager path by introducing a new
conctructor "g_dbus_client_new_full".
The client code currently issues GetManagedObjects if new handlers are
set via g_dbus_client_set_proxy_handlers. An application may set these
to NULL before unref'ing a client or to simply prevent further events.
Hence, there is no need to refresh objects or properties if all handlers
are NULL.
If daemon gets disconnected from D-Bus sender is NULL. Watches that
was explicitly added with NULL sender (ie disconnected_signal in
g_dbus_set_disconnect_function) should be called anyway.
If g_dbus_client_set_proxy_handlers gets called from within a
proxy_removed callback, the code may end up refreshing the proxy's
properties and incorrectly access the client's proxy_list as it gets
freed. This patch fixes this, so that get_managed_objects does nothing
if it gets called during a service disconnect.
Fix eternal loop loop with roaming SIM
When ofono core is asking gprs driver to detach (because data roaming is disabled), it's expecting data registration status to change. If that doesn't happen, it starts all over again.
See merge request !22
When ofono core is asking gprs driver to detach (because data
roaming is disabled), it's expecting data registration status
to change. If that doesn't happen, it starts all over again.
Return cached IMEI values from query_serial
Those are always queried at startup and they never change. There's no reason to perform RIL query for IMEI more than once.
See merge request !21
There is no need to wait for the network state status, the network
may already be operational. Without cid range, attempts to activate
connection context will fail with org.ofono.Error.NotImplemented
Fixed a few issues mostly affecting startup and slowing down sim initialization
1. Don't submit the initial network state request if RIL says that radio is off. I have the impression that RIL doesn't like it; besides it won't work anyway. Instead, wait for radio on or for the network state change event, whichever comes first.
2. When the network state or sim status event occurs and the corresponding query is scheduled to be retried after a failure, retry it right away (i.e. don't wait for the retry timeout to expire).
Requires libgrilio 1.0.6 (already merged) which includes the bug fix for retries happening 1000 times too often (which rild might not like too).
See merge request !19
Handle more cause values for call control.
Quite many normal disconnect causes defined in 3GPP TS 24.008 Annex H
are not handled and are thus treated as errors. telepathy-ring would
then play "network out of order" tone, when "busy" tone would be more
appropriate. Add all the call control cause values not defined in ril.h
(but defined in Annex H) here and handle them appropriately.
See merge request !20
Quite many normal disconnect causes defined in 3GPP TS 24.008 Annex H
are not handled and are thus treated as errors. telepathy-ring would
then play "network out of order" tone, when "busy" tone would be more
appropriate. Add all the call control cause values not defined in ril.h
(but defined in Annex H) here and handle them appropriately.
If we don't do it, bad things may happen (like the enabled and
apparently powered on modem never registering on the network).
This may have something to do with certain pieces of radio
circuitry being shared by all modems.
Use different SET_UICC_SUBSCRIPTION codes for different RIL versions
RIL_REQUEST_SET_UICC_SUBSCRIPTION is 115 in RIL version 9 (or earlier) and 122 in RIL version 10 and later. Since we don't know in advance which RIL version we are dealing with, we need to make the decision at runtime.
See merge request !17
RIL_REQUEST_SET_UICC_SUBSCRIPTION is 115 in RIL version 9 (or earlier)
and 122 in RIL version 10 and later. Since we don't know in advance which
RIL version we are dealing with, we need to make the decision at runtime.
