2:23 p.m.
added new DBUS methods RegisterAgent and UnregisterAgent to
Networkmonitor interface so that any client of ofono can register for
serving cell updates. Added new agent interface NetworkMonitorAgent
with two methods, ServingCellInformationChanged and Release.
---
doc/networkmonitor-api.txt | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/doc/networkmonitor-api.txt b/doc/networkmonitor-api.txt
index ddace7e..0855329 100644
--- a/doc/networkmonitor-api.txt
+++ b/doc/networkmonitor-api.txt
@@ -22,6 +22,34 @@ Methods a{sv} GetServingCellInformation()
are available, their valid value ranges and
applicability to different cell types.
+ void RegisterAgent(object path)
+
+ Registers an agent which will be called whenever the
+ modem registers to or moves to a new cell.
+
+ void UnregisterAgent(object path)
+
+ Unregisters an agent.
+
+NetworkMonitorAgent Hierarchy [experimental]
+=============================
+
+Service unique name
+Interface org.ofono.NetworkMonitorAgent
+Object path freely definable
+
+Methods void ServingCellInformationChanged(a{sv})
+
+ This method is called whenever the serving cell
+ information has been updated.
+
+ Possible Errors: None
+
+ void Release() [noreply]
+
+ Agent is being released, possibly because of oFono
+ terminating, NetworkMonitor interface is being torn
+ down or modem off. No UnregisterAgent call is needed.
Network Monitor Property Types
==============================
--
1.9.1
2:23 p.m.
New subject: [PATCH 2/7] include: added enable_periodic_update in netmon driver
Defining new method in ofono_netmon_driver,
enable_periodic_update useful to get periodic update
on serving cell information.
---
include/netmon.h | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/include/netmon.h b/include/netmon.h
index 72090c3..c8fcafa 100644
--- a/include/netmon.h
+++ b/include/netmon.h
@@ -39,6 +39,10 @@ struct ofono_netmon_driver {
void (*remove)(struct ofono_netmon *netmon);
void (*request_update)(struct ofono_netmon *netmon,
ofono_netmon_cb_t cb, void *data);
+ void (*enable_periodic_update)(struct ofono_netmon *netmon,
+ unsigned int enable,
+ unsigned int period,
+ ofono_netmon_cb_t cb, void *data);
};
enum ofono_netmon_cell_type {
--
1.9.1
2:23 p.m.
New subject: [PATCH 3/7] include: added NetworkMonitorAgent interface
---
include/dbus.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/dbus.h b/include/dbus.h
index cf68ae5..a6519c7 100644
--- a/include/dbus.h
+++ b/include/dbus.h
@@ -61,6 +61,7 @@ extern "C" {
#define OFONO_HANDSFREE_INTERFACE OFONO_SERVICE ".Handsfree"
#define OFONO_SIRI_INTERFACE OFONO_SERVICE ".Siri"
#define OFONO_NETMON_INTERFACE OFONO_SERVICE ".NetworkMonitor"
+#define OFONO_NETMON_AGENT_INTERFACE OFONO_SERVICE ".NetworkMonitorAgent"
#define OFONO_LTE_INTERFACE OFONO_SERVICE ".LongTermEvolution"
/* CDMA Interfaces */
--
1.9.1
2:23 p.m.
New subject: [PATCH 4/7] netmon: core changes for network monitor agent
Added implementation for RegisterAgent and UnregisterAgent in
NetworkMonitor interface and added netmonagent source file for agent
implemention.
---
Makefile.am | 3 +-
src/netmon.c | 126 ++++++++++++++++++++++++++++++++++++++++++++++++++++--
src/netmonagent.c | 122 ++++++++++++++++++++++++++++++++++++++++++++++++++++
src/netmonagent.h | 23 ++++++++++
src/ofono.conf | 1 +
5 files changed, 270 insertions(+), 5 deletions(-)
create mode 100644 src/netmonagent.c
create mode 100644 src/netmonagent.h
diff --git a/Makefile.am b/Makefile.am
index 658e152..fbc4d6d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -626,7 +626,8 @@ src_ofonod_SOURCES = $(builtin_sources) $(gatchat_sources)
src/ofono.ver \
src/cdma-provision.c src/handsfree.c \
src/handsfree-audio.c src/bluetooth.h \
src/hfp.h src/siri.c \
- src/netmon.c src/lte.c
+ src/netmon.c src/lte.c \
+ src/netmonagent.c src/netmonagent.h
src_ofonod_LDADD = gdbus/libgdbus-internal.la $(builtin_libadd) \
@GLIB_LIBS@ @DBUS_LIBS@ -ldl
diff --git a/src/netmon.c b/src/netmon.c
index 6476783..3a49587 100644
--- a/src/netmon.c
+++ b/src/netmon.c
@@ -34,6 +34,7 @@
#include <gdbus.h>
#include "ofono.h"
+#include "netmonagent.h"
#define CELL_INFO_DICT_APPEND(p_dict, key, info, type, dbus_type) do { \
type value; \
@@ -51,6 +52,7 @@ struct ofono_netmon {
DBusMessage *reply;
void *driver_data;
struct ofono_atom *atom;
+ struct netmon_agent *agent;
};
static const char *cell_type_to_tech_name(enum ofono_netmon_cell_type type)
@@ -72,6 +74,7 @@ void ofono_netmon_serving_cell_notify(struct ofono_netmon *netmon,
int info_type, ...)
{
va_list arglist;
+ DBusMessage *agent_notify = NULL;
DBusMessageIter iter;
DBusMessageIter dict;
enum ofono_netmon_info next_info_type = info_type;
@@ -79,12 +82,17 @@ void ofono_netmon_serving_cell_notify(struct ofono_netmon *netmon,
char *mcc;
char *mnc;
int intval;
- netmon->reply = dbus_message_new_method_return(netmon->pending);
- if (netmon->reply == NULL)
- return;
+ if (netmon->pending != NULL) {
+ netmon->reply = dbus_message_new_method_return(netmon->pending);
+ dbus_message_iter_init_append(netmon->reply, &iter);
+ } else if (netmon->agent != NULL) {
+ agent_notify = netmon_agent_new_method_call(netmon->agent,
+ "ServingCellInformationChanged");
- dbus_message_iter_init_append(netmon->reply, &iter);
+ dbus_message_iter_init_append(agent_notify, &iter);
+ } else
+ return;
dbus_message_iter_open_container(&iter, DBUS_TYPE_ARRAY,
OFONO_PROPERTIES_ARRAY_SIGNATURE,
@@ -243,6 +251,9 @@ done:
va_end(arglist);
dbus_message_iter_close_container(&iter, &dict);
+
+ if (agent_notify)
+ netmon_agent_send_no_reply(netmon->agent, agent_notify);
}
static void serving_cell_info_callback(const struct ofono_error *error,
@@ -291,10 +302,117 @@ static DBusMessage *netmon_get_serving_cell_info(DBusConnection
*conn,
return NULL;
}
+static void periodic_updates_enabled_cb(const struct ofono_error *error,
+ void *data)
+{
+ struct ofono_netmon *netmon = data;
+
+ if (error->type != OFONO_ERROR_TYPE_NO_ERROR) {
+ ofono_error("Error enabling periodic updates");
+
+ netmon_agent_free(netmon->agent);
+ return;
+ }
+}
+
+static void periodic_updates_disabled_cb(const struct ofono_error *error,
+ void *data)
+{
+ if (error->type != OFONO_ERROR_TYPE_NO_ERROR)
+ ofono_error("Error disabling periodic updates");
+}
+
+static void agent_removed_cb(gpointer user_data)
+{
+ struct ofono_netmon *netmon = user_data;
+
+ netmon->agent = NULL;
+
+ netmon->driver->enable_periodic_update(netmon, 0, 0,
+ periodic_updates_disabled_cb,
+ NULL);
+}
+
+static DBusMessage *netmon_register_agent(DBusConnection *conn,
+ DBusMessage *msg, void *data)
+{
+ struct ofono_netmon *netmon = data;
+ const char *agent_path;
+ const unsigned int enable = 1;
+ unsigned int period;
+
+ if (netmon->agent)
+ return __ofono_error_busy(msg);
+
+ if (!netmon->driver->enable_periodic_update)
+ return __ofono_error_not_implemented(msg);
+
+ if (dbus_message_get_args(msg, NULL,
+ DBUS_TYPE_OBJECT_PATH, &agent_path,
+ DBUS_TYPE_UINT32, &period,
+ DBUS_TYPE_INVALID) == FALSE)
+ return __ofono_error_invalid_args(msg);
+
+ if (!__ofono_dbus_valid_object_path(agent_path))
+ return __ofono_error_invalid_format(msg);
+
+ if (!period)
+ return __ofono_error_invalid_args(msg);
+
+ /* minimum period is 5 seconds, to avoid frequent updates*/
+ if (period < 5)
+ period = 5;
+
+ netmon->agent = netmon_agent_new(agent_path,
+ dbus_message_get_sender(msg));
+
+ if (netmon->agent == NULL)
+ return __ofono_error_failed(msg);
+
+ netmon_agent_set_removed_notify(netmon->agent, agent_removed_cb, netmon);
+
+ netmon->driver->enable_periodic_update(netmon, enable, period,
+ periodic_updates_enabled_cb, netmon);
+
+ return dbus_message_new_method_return(msg);
+}
+
+static DBusMessage *netmon_unregister_agent(DBusConnection *conn,
+ DBusMessage *msg, void *data)
+{
+ struct ofono_netmon *netmon = data;
+ const char *agent_path;
+ const char *agent_bus = dbus_message_get_sender(msg);
+
+ if (!netmon->driver->enable_periodic_update)
+ return __ofono_error_not_implemented(msg);
+
+ if (dbus_message_get_args(msg, NULL,
+ DBUS_TYPE_OBJECT_PATH, &agent_path,
+ DBUS_TYPE_INVALID) == FALSE)
+ return __ofono_error_invalid_args(msg);
+
+ if (netmon->agent == NULL)
+ return __ofono_error_failed(msg);
+
+ if (!netmon_agent_matches(netmon->agent, agent_path, agent_bus))
+ return __ofono_error_access_denied(msg);
+
+ netmon_agent_free(netmon->agent);
+
+ return dbus_message_new_method_return(msg);
+}
+
static const GDBusMethodTable netmon_methods[] = {
{ GDBUS_ASYNC_METHOD("GetServingCellInformation",
NULL, GDBUS_ARGS({ "cellinfo", "a{sv}" }),
netmon_get_serving_cell_info) },
+ { GDBUS_METHOD("RegisterAgent",
+ GDBUS_ARGS({ "path", "o"}, { "period", "u"}),
NULL,
+ netmon_register_agent) },
+ { GDBUS_METHOD("UnregisterAgent",
+ GDBUS_ARGS({ "agent", "o" }), NULL,
+ netmon_unregister_agent) },
{ }
};
diff --git a/src/netmonagent.c b/src/netmonagent.c
new file mode 100644
index 0000000..ab6f050
--- /dev/null
+++ b/src/netmonagent.c
@@ -0,0 +1,122 @@
+#ifdef HAVE_CONFIG_H
+#include <config.h>
+#endif
+
+#define _GNU_SOURCE
+#include <stdint.h>
+#include <string.h>
+#include <errno.h>
+
+#include <glib.h>
+#include <gdbus.h>
+
+#include "ofono.h"
+#include "netmonagent.h"
+
+struct netmon_agent {
+ char *path;
+ char *bus;
+ guint disconnect_watch;
+ ofono_destroy_func removed_cb;
+ void *removed_data;
+};
+
+DBusMessage *netmon_agent_new_method_call(struct netmon_agent *agent,
+ const char *method)
+{
+ DBusMessage *msg = dbus_message_new_method_call(agent->bus,
+ agent->path,
+ OFONO_NETMON_AGENT_INTERFACE,
+ method);
+
+ return msg;
+}
+
+void netmon_agent_send_no_reply(struct netmon_agent *agent,
+ DBusMessage *message)
+{
+ DBusConnection *conn = ofono_dbus_get_connection();
+
+ dbus_message_set_no_reply(message, TRUE);
+
+ g_dbus_send_message(conn, message);
+}
+
+static inline void netmon_agent_send_release(struct netmon_agent *agent)
+{
+ DBusMessage *msg = netmon_agent_new_method_call(agent, "Release");
+
+ netmon_agent_send_no_reply(agent, msg);
+}
+
+ofono_bool_t netmon_agent_matches(struct netmon_agent *agent,
+ const char *path, const char *sender)
+{
+ return g_str_equal(agent->path, path) &&
+ g_str_equal(agent->bus, sender);
+}
+
+ofono_bool_t netmon_agent_sender_matches(struct netmon_agent *agent,
+ const char *sender)
+{
+ return g_str_equal(agent->bus, sender);
+}
+
+void netmon_agent_set_removed_notify(struct netmon_agent *agent,
+ ofono_destroy_func destroy,
+ void *user_data)
+{
+ agent->removed_cb = destroy;
+ agent->removed_data = user_data;
+}
+
+void netmon_agent_free(struct netmon_agent *agent)
+{
+ DBusConnection *conn = ofono_dbus_get_connection();
+
+ if (agent == NULL)
+ return;
+
+ if (agent->disconnect_watch) {
+ netmon_agent_send_release(agent);
+ g_dbus_remove_watch(conn, agent->disconnect_watch);
+ agent->disconnect_watch = 0;
+ }
+
+ if (agent->removed_cb)
+ agent->removed_cb(agent->removed_data);
+
+ g_free(agent->path);
+ g_free(agent->bus);
+ g_free(agent);
+}
+
+static void netmon_agent_disconnect_cb(DBusConnection *conn, void *user_data)
+{
+ struct netmon_agent *agent = user_data;
+
+ ofono_debug("Agent excited without calling UnregisterAgent");
+
+ agent->disconnect_watch = 0;
+
+ netmon_agent_free(agent);
+}
+
+struct netmon_agent *netmon_agent_new(const char *path,
+ const char *sender)
+{
+ struct netmon_agent *agent = g_try_new0(struct netmon_agent, 1);
+ DBusConnection *conn = ofono_dbus_get_connection();
+
+ if (agent == NULL)
+ return NULL;
+
+ agent->bus = g_strdup(sender);
+ agent->path = g_strdup(path);
+
+ agent->disconnect_watch = g_dbus_add_disconnect_watch(conn, sender,
+ netmon_agent_disconnect_cb,
+ agent, NULL);
+
+ return agent;
+}
diff --git a/src/netmonagent.h b/src/netmonagent.h
new file mode 100644
index 0000000..f64a503
--- /dev/null
+++ b/src/netmonagent.h
@@ -0,0 +1,23 @@
+struct netmon_agent;
+
+struct netmon_agent *netmon_agent_new(const char *path, const char *sender);
+
+void netmon_agent_free(struct netmon_agent *agent);
+
+void netmon_agent_set_removed_notify(struct netmon_agent *agent,
+ ofono_destroy_func removed_cb,
+ void *user_data);
+
+ofono_bool_t netmon_agent_matches(struct netmon_agent *agent,
+ const char *path, const char *sender);
+
+ofono_bool_t netmon_agent_sender_matches(struct netmon_agent *agent,
+ const char *sender);
+
+DBusMessage *netmon_agent_new_method_call(struct netmon_agent *netmon,
+ const char *method);
+
+void netmon_agent_send_no_reply(struct netmon_agent *agent,
+ DBusMessage *message);
+
+void netmon_agent_test(struct netmon_agent *agent);
diff --git a/src/ofono.conf b/src/ofono.conf
index ed56d3b..61e0bde 100644
--- a/src/ofono.conf
+++ b/src/ofono.conf
@@ -15,6 +15,7 @@
<allow send_interface="org.ofono.SmartMessagingAgent"/>
<allow send_interface="org.ofono.PositioningRequestAgent"/>
<allow send_interface="org.ofono.HandsfreeAudioAgent"/>
+ <allow send_interface="org.ofono.NetworkMonitorAgent"/>
</policy>
<policy at_console="true">
--
1.9.1
2:23 p.m.
New subject: [PATCH 5/7] gril: added RIL constants for cell info list
added RIL_REQUEST_SET_UNSOL_CELL_INFO_LIST_RATE and
RIL_UNSOL_CELL_INFO_LIST and corresponding string
conversion
---
gril/grilutil.c | 4 ++++
gril/ril_constants.h | 2 ++
2 files changed, 6 insertions(+)
diff --git a/gril/grilutil.c b/gril/grilutil.c
index 9e7cd31..89a6d6f 100644
--- a/gril/grilutil.c
+++ b/gril/grilutil.c
@@ -338,6 +338,8 @@ const char *ril_request_id_to_string(int req)
return "RIL_REQUEST_GET_CELL_INFO_LIST";
case RIL_REQUEST_SET_INITIAL_ATTACH_APN:
return "RIL_REQUEST_SET_INITIAL_ATTACH_APN";
+ case RIL_REQUEST_SET_UNSOL_CELL_INFO_LIST_RATE:
+ return "RIL_REQUEST_SET_UNSOL_CELL_INFO_LIST_RATE";
default:
return "<INVALID>";
}
@@ -416,6 +418,8 @@ const char *ril_unsol_request_to_string(int request)
return "UNSOL_EXIT_EMERGENCY_CALLBACK_MODE";
case RIL_UNSOL_RIL_CONNECTED:
return "UNSOL_RIL_CONNECTED";
+ case RIL_UNSOL_CELL_INFO_LIST:
+ return "RIL_UNSOL_CELL_INFO_LIST";
default:
return "<unknown request>";
}
diff --git a/gril/ril_constants.h b/gril/ril_constants.h
index cbc596e..b707136 100644
--- a/gril/ril_constants.h
+++ b/gril/ril_constants.h
@@ -348,6 +348,7 @@
#define RIL_REQUEST_STK_SEND_ENVELOPE_WITH_STATUS 107
#define RIL_REQUEST_VOICE_RADIO_TECH 108
#define RIL_REQUEST_GET_CELL_INFO_LIST 109
+#define RIL_REQUEST_SET_UNSOL_CELL_INFO_LIST_RATE 110
#define RIL_REQUEST_SET_INITIAL_ATTACH_APN 111
/* RIL Unsolicited Messages */
@@ -388,6 +389,7 @@
#define RIL_UNSOL_EXIT_EMERGENCY_CALLBACK_MODE 1033
#define RIL_UNSOL_RIL_CONNECTED 1034
#define RIL_UNSOL_VOICE_RADIO_TECH_CHANGED 1035
+#define RIL_UNSOL_CELL_INFO_LIST 1036
/* Suplementary services Service class*/
#define SERVICE_CLASS_NONE 0
--
1.9.1
2:23 p.m.
New subject: [PATCH 6/7] rilmodem: driver changes for netmon agent
Rilmodem driver updated to handle enabling
and disabling periodic serving cell updates
---
drivers/rilmodem/netmon.c | 98 +++++++++++++++++++++++++++++++++++++++++------
1 file changed, 87 insertions(+), 11 deletions(-)
diff --git a/drivers/rilmodem/netmon.c b/drivers/rilmodem/netmon.c
index f7f7c28..a1e5f6c 100644
--- a/drivers/rilmodem/netmon.c
+++ b/drivers/rilmodem/netmon.c
@@ -61,6 +61,9 @@
/* size of RIL_CellInfoTdscdma */
#define NETMON_RIL_CELLINFO_SIZE_TDSCDMA 24
+#define MSECS_RATE_INVALID (0x7fffffff)
+#define SECS_TO_MSECS(x) ((x) * 1000)
+
struct netmon_data {
GRil *ril;
};
@@ -96,11 +99,9 @@ static int ril_cell_type_to_size(int cell_type)
return 0;
}
-static void ril_netmon_update_cb(struct ril_msg *message, gpointer user_data)
+static int process_cellinfo_list(struct ril_msg *message,
+ struct ofono_netmon *netmon)
{
- struct cb_data *cbd = user_data;
- ofono_netmon_cb_t cb = cbd->cb;
- struct ofono_netmon *netmon = cbd->data;
struct parcel rilp;
int skip_len;
int cell_info_cnt;
@@ -114,7 +115,7 @@ static void ril_netmon_update_cb(struct ril_msg *message, gpointer
user_data)
int i, j;
if (message->error != RIL_E_SUCCESS)
- goto error;
+ return OFONO_ERROR_TYPE_FAILURE;
g_ril_init_parcel(message, &rilp);
@@ -146,7 +147,7 @@ static void ril_netmon_update_cb(struct ril_msg *message, gpointer
user_data)
}
if (!registered)
- goto error;
+ return OFONO_ERROR_TYPE_FAILURE;
if (cell_type == NETMON_RIL_CELLINFO_TYPE_GSM) {
mcc = parcel_r_int32(&rilp);
@@ -216,17 +217,53 @@ static void ril_netmon_update_cb(struct ril_msg *message, gpointer
user_data)
OFONO_NETMON_INFO_BER, ber,
OFONO_NETMON_INFO_INVALID);
- } else {
- goto error;
}
- CALLBACK_WITH_SUCCESS(cb, cbd->data);
- return;
+ return OFONO_ERROR_TYPE_NO_ERROR;
+}
+
+static void ril_netmon_update_cb(struct ril_msg *message, gpointer user_data)
+{
+ struct cb_data *cbd = user_data;
+ ofono_netmon_cb_t cb = cbd->cb;
+ struct ofono_netmon *netmon = cbd->data;
+
+ if (process_cellinfo_list(message, netmon) ==
+ OFONO_ERROR_TYPE_NO_ERROR) {
+ CALLBACK_WITH_SUCCESS(cb, cbd->data);
+ return;
+ }
-error:
CALLBACK_WITH_FAILURE(cb, cbd->data);
}
+static void ril_cellinfo_notify(struct ril_msg *message, gpointer user_data)
+{
+ struct ofono_netmon *netmon = user_data;
+
+ process_cellinfo_list(message, netmon);
+}
+
+static void setup_cell_info_notify(struct ofono_netmon *netmon)
+{
+ struct netmon_data *nmd = ofono_netmon_get_data(netmon);
+ struct parcel rilp;
+
+ parcel_init(&rilp);
+
+ parcel_w_int32(&rilp, 1); /* Number of elements */
+
+ parcel_w_int32(&rilp, MSECS_RATE_INVALID);
+
+ if (g_ril_send(nmd->ril, RIL_REQUEST_SET_UNSOL_CELL_INFO_LIST_RATE,
+ &rilp, NULL, NULL, NULL) == 0)
+ ofono_error("%s: setup failed\n", __func__);
+
+ if (g_ril_register(nmd->ril, RIL_UNSOL_CELL_INFO_LIST,
+ ril_cellinfo_notify, netmon) == 0)
+ ofono_error("%s: setup failed\n", __func__);
+}
+
static int ril_netmon_probe(struct ofono_netmon *netmon,
unsigned int vendor, void *user)
{
@@ -237,6 +274,8 @@ static int ril_netmon_probe(struct ofono_netmon *netmon,
ofono_netmon_set_data(netmon, ud);
+ setup_cell_info_notify(netmon);
+
g_idle_add(ril_delayed_register, netmon);
return 0;
@@ -264,11 +303,48 @@ static void ril_netmon_request_update(struct ofono_netmon *netmon,
CALLBACK_WITH_FAILURE(cb, data);
}
+static void periodic_update_cb(struct ril_msg *message, gpointer user_data)
+{
+ struct cb_data *cbd = user_data;
+ ofono_netmon_cb_t cb = cbd->cb;
+
+ if (message->error != RIL_E_SUCCESS)
+ CALLBACK_WITH_FAILURE(cb, cbd->data);
+
+ CALLBACK_WITH_SUCCESS(cb, cbd->data);
+}
+
+static void ril_netmon_periodic_update(struct ofono_netmon *netmon,
+ unsigned int enable, unsigned int period,
+ ofono_netmon_cb_t cb, void *data)
+{
+ struct netmon_data *nmd = ofono_netmon_get_data(netmon);
+ struct cb_data *cbd = cb_data_new(cb, data, nmd);
+ struct parcel rilp;
+
+ parcel_init(&rilp);
+
+ parcel_w_int32(&rilp, 1); /* Number of elements */
+
+ if (enable)
+ parcel_w_int32(&rilp, SECS_TO_MSECS(period));
+ else
+ parcel_w_int32(&rilp, MSECS_RATE_INVALID);
+
+ if (g_ril_send(nmd->ril, RIL_REQUEST_SET_UNSOL_CELL_INFO_LIST_RATE,
+ &rilp, periodic_update_cb, cbd, g_free) > 0)
+ return;
+
+ g_free(cbd);
+ CALLBACK_WITH_FAILURE(cb, cbd->data);
+}
+
static struct ofono_netmon_driver driver = {
.name = RILMODEM,
.probe = ril_netmon_probe,
.remove = ril_netmon_remove,
.request_update = ril_netmon_request_update,
+ .enable_periodic_update = ril_netmon_periodic_update,
};
void ril_netmon_init(void)
--
1.9.1
2:23 p.m.
New subject: [PATCH 7/7] test: added script to test serving cell agent
---
Makefile.am | 4 +-
test/test-serving-cell-info | 98 +++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 101 insertions(+), 1 deletion(-)
create mode 100644 test/test-serving-cell-info
diff --git a/Makefile.am b/Makefile.am
index fbc4d6d..c46e85a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -780,7 +780,9 @@ test_scripts = test/backtrace \
test/list-allowed-access-points \
test/enable-throttling \
test/disable-throttling \
- test/set-lte-property
+ test/set-lte-property \
+ test/test-serving-cell-info
+
if TEST
testdir = $(pkglibdir)/test
diff --git a/test/test-serving-cell-info b/test/test-serving-cell-info
new file mode 100644
index 0000000..de9cb7b
--- /dev/null
+++ b/test/test-serving-cell-info
@@ -0,0 +1,98 @@
+#!/usr/bin/python3
+
+from gi.repository import GLib
+
+import sys
+import dbus
+import dbus.service
+import dbus.mainloop.glib
+
+NETMON_INTERFACE = "org.ofono.NetworkMonitor"
+AGENT_INTERFACE = "org.ofono.NetworkMonitorAgent"
+
+class NetworkMonitorAgent(dbus.service.Object):
+ @dbus.service.method(AGENT_INTERFACE,
+ in_signature="", out_signature="")
+ def Release(self):
+ print("Agent Released")
+ mainloop.quit()
+
+ @dbus.service.method(AGENT_INTERFACE,
+ in_signature="a{sv}", out_signature="")
+ def ServingCellInformationChanged(self, servingcell):
+ print("ServingCellInformationChanged notification recieved")
+
+ tech = 'Technology'
+ mcc = 'MobileCountryCode'
+ mnc = 'MobileNetworkCode'
+ lac = 'LocationAreaCode'
+ cid = 'CellId'
+ psc = 'PrimaryScramblingCode'
+ rssi = 'Strength'
+ ber = 'BitErrorRate'
+
+ if tech in servingcell:
+ print(" [ Radio Access Technology = %s]" \
+ % (servingcell[tech]))
+
+ if mcc in servingcell:
+ print(" [ Mobile Country Code = %s]" \
+ % (servingcell[mcc]))
+
+ if mnc in servingcell:
+ print(" [ Mobile Network Code = %s]" \
+ % (servingcell[mnc]))
+
+ if lac in servingcell:
+ print(" [ Location Area Code = %d]" \
+ % (servingcell[lac]))
+
+ if cid in servingcell:
+ print(" [ Cell Identity = %d]" \
+ % (servingcell[cid]))
+
+ if psc in servingcell:
+ print(" [ Primary Scrambling Code = %d]" \
+ % (servingcell[psc]))
+
+ if rssi in servingcell:
+ print(" [ Signal Strength = %d]" \
+ % (servingcell[rssi]))
+
+ if ber in servingcell:
+ print(" [ Bit Error Rate = %d]" \
+ % (servingcell[ber]))
+
+ print('')
+
+if __name__ == '__main__':
+ dbus.mainloop.glib.DBusGMainLoop(set_as_default=True)
+
+ if len(sys.argv) < 2:
+ print("Usage: %s <update_period_in_seconds>" %\
+ (sys.argv[0]))
+ sys.exit(1)
+
+ bus = dbus.SystemBus()
+ manager = dbus.Interface(bus.get_object("org.ofono", "/"),
+ "org.ofono.Manager")
+
+ modems = manager.GetModems()
+ path = modems[0][0]
+ nm = dbus.Interface(bus.get_object('org.ofono', path),
+ NETMON_INTERFACE)
+
+ path = "/test/netmonagent"
+ agent = NetworkMonitorAgent(bus, path)
+
+ try:
+ period = int(sys.argv[1])
+ except:
+ print("Error: Invalid argument %s" % (sys.argv[1]))
+ sys.exit(1)
+
+ nm.RegisterAgent(path, period)
+ print("Agent registered")
+ mainloop = GLib.MainLoop()
+ mainloop.run()
+
--
1.9.1
7:47 p.m.
On 09/07/2017 06:23 AM, Nishanth V wrote:
added new DBUS methods RegisterAgent and UnregisterAgent to
Networkmonitor interface so that any client of ofono can register for
serving cell updates. Added new agent interface NetworkMonitorAgent
with two methods, ServingCellInformationChanged and Release.
My spontaneous reaction to this is that it feels like the wrong
approach. Why not make the properties actual DBus properties and
provide PropertiesChanged events for them? That begets you the same
functionality for "free".
It's interesting that you posted this now because I've spent the last
week grumbling over this API myself as I'm putting support for the
NetworkMonitor interface into the QMI modem class. My thoughts:
i) There's duplicate information all over the place. MNC, LAC, etc.
are provided in three different interefaces: NetworkRegistration,
NetworkMonitor, and NetworkOperator.
ii) The NetworkOperator interface caught me off guard as it appeared
out of nowhere! There is no documentation for the interface and the
implementation seems to be missing from most device classes.
iii) The polled nature of the NetworkMonitor object surprised me. This
seems like a natural case for notifications and the patch series in this
email thread underscores this fact.
iv) For QMI, at least, the NetworkRegistration atom is monitoring
asynchronous events that contain essentially all the information needed
by the NetworkMonitor atom. The NetworkRegistration atom could just
save these values and provide the NetworkMonitor interface in the same
module instead of having an additional netmon module, but:
a) We end up monitoring unnecessary state in case nobody is actually
listening to the NetworkMonitor updates. This seems to have a
negligible impact on performance so it probably does not matter.
b) ofono does not use this approach anywhere else that I can see...
every atom/interface is provided in it's own module.
v) Point iv) applies to the NetworkOperator interface, as well, if we
decide to implement it... should we?
vi) I suspect that other device classes (AT, etc.) provide asynchronous
network quality updates, as well; if they do not, however, then it seems
natural to move the polling of this state into the device class driver.
Sorry for hijacking this for a bit of QMI implementation discussion but
it seems relevant in trying to understand what it is that the
NetworkMonitor interface is supposed to be.
Thoughts?
/Jonas
---
doc/networkmonitor-api.txt | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/doc/networkmonitor-api.txt b/doc/networkmonitor-api.txt
index ddace7e..0855329 100644
--- a/doc/networkmonitor-api.txt
+++ b/doc/networkmonitor-api.txt
@@ -22,6 +22,34 @@ Methods a{sv} GetServingCellInformation()
are available, their valid value ranges and
applicability to different cell types.
+ void RegisterAgent(object path)
+
+ Registers an agent which will be called whenever the
+ modem registers to or moves to a new cell.
+
+ void UnregisterAgent(object path)
+
+ Unregisters an agent.
+
+NetworkMonitorAgent Hierarchy [experimental]
+=============================
+
+Service unique name
+Interface org.ofono.NetworkMonitorAgent
+Object path freely definable
+
+Methods void ServingCellInformationChanged(a{sv})
+
+ This method is called whenever the serving cell
+ information has been updated.
+
+ Possible Errors: None
+
+ void Release() [noreply]
+
+ Agent is being released, possibly because of oFono
+ terminating, NetworkMonitor interface is being torn
+ down or modem off. No UnregisterAgent call is needed.
Network Monitor Property Types
==============================
11:06 p.m.
On 07/09/17 12:47, Jonas Bonn wrote:
On 09/07/2017 06:23 AM, Nishanth V wrote:
> added new DBUS methods RegisterAgent and UnregisterAgent to
> Networkmonitor interface so that any client of ofono can register for
> serving cell updates. Added new agent interface NetworkMonitorAgent
> with two methods, ServingCellInformationChanged and Release.
My spontaneous reaction to this is that it feels like the wrong
approach. Why not make the properties actual DBus properties and
provide PropertiesChanged events for them? That begets you the same
functionality for "free".
The implementation also seems to limit the number of clients receiving
those cell change notifications to just one. Why? In real life more than
one process may need those.
Cheers,
-Slava
2:05 a.m.
Hi Slava,
On 09/07/2017 08:06 AM, Slava Monich wrote:
On 07/09/17 12:47, Jonas Bonn wrote:
> On 09/07/2017 06:23 AM, Nishanth V wrote:
>> added new DBUS methods RegisterAgent and UnregisterAgent to
>> Networkmonitor interface so that any client of ofono can register for
>> serving cell updates. Added new agent interface NetworkMonitorAgent
>> with two methods, ServingCellInformationChanged and Release.
>
> My spontaneous reaction to this is that it feels like the wrong
> approach. Why not make the properties actual DBus properties and
> provide PropertiesChanged events for them? That begets you the same
> functionality for "free".
The implementation also seems to limit the number of clients receiving
those cell change notifications to just one. Why? In real life more than
one process may need those.
You keep saying that, but never provide concrete scenarios how this
could be 'useful'? I am tempted to simply ignore such feedback in the
future.
For now I don't see why we would want to have multiple agents registered
and to keep the implementation simple we will only support one.
Regards,
-Denis
3:11 a.m.
On 07/09/17 19:05, Denis Kenzior wrote:
Hi Slava,
On 09/07/2017 08:06 AM, Slava Monich wrote:
> On 07/09/17 12:47, Jonas Bonn wrote:
>> On 09/07/2017 06:23 AM, Nishanth V wrote:
>>> added new DBUS methods RegisterAgent and UnregisterAgent to
>>> Networkmonitor interface so that any client of ofono can register for
>>> serving cell updates. Added new agent interface NetworkMonitorAgent
>>> with two methods, ServingCellInformationChanged and Release.
>>
>> My spontaneous reaction to this is that it feels like the wrong
>> approach. Why not make the properties actual DBus properties and
>> provide PropertiesChanged events for them? That begets you the same
>> functionality for "free".
>
> The implementation also seems to limit the number of clients
> receiving those cell change notifications to just one. Why? In real
> life more than one process may need those.
>
You keep saying that, but never provide concrete scenarios how this
could be 'useful'? I am tempted to simply ignore such feedback in the
future.
In the Sailfish OS case, one is the positioning helper, and there's the
factory test app. That makes it at least two. The factory test app often
plays the role of the second client since it's touching pretty much all
the important interfaces in the system. And there are 3rd party apps
which we don't control.
For now I don't see why we would want to have multiple agents
registered and to keep the implementation simple we will only support
one.
That's fine, we are using a different interface for getting cell
information anyway. Go ahead and ignore the feedback.
Cheers,
-Slava
Regards,
-Denis
3:30 a.m.
Hi Slava,
In the Sailfish OS case, one is the positioning helper, and there's the
factory test app. That makes it at least two. The factory test app often
plays the role of the second client since it's touching pretty much all
the important interfaces in the system. And there are 3rd party apps
which we don't control.
See? This wasn't that hard ;)
How does the factory test app use this info? Does it need actual
periodic updates or can it simply obtain this via the method call?
I'm open to the idea of supporting multiple agents. We do have to
figure out who dictates the periodic update interval. One approach
might be to have a single master agent and multiple observer agents.
Feel free to propose something.
Regards,
-Denis
7:30 p.m.
Hi Denis,
Hi Slava,
>
> In the Sailfish OS case, one is the positioning helper, and there's
> the factory test app. That makes it at least two. The factory test
> app often plays the role of the second client since it's touching
> pretty much all the important interfaces in the system. And there are
> 3rd party apps which we don't control.
See? This wasn't that hard ;)
How does the factory test app use this info? Does it need actual
periodic updates or can it simply obtain this via the method call?
Our RIL plugin decides on the update rate internally, based on the
device state (limiting the rate when the screen turns off).
Different clients have different needs - some need updates only when the
screen is on (if they are just displaying something on the screen) and
some may always need updates (a background task collecting some data or
whatever). The optimal solution may be quite specific to the environment
where ofono is used.
I'm open to the idea of supporting multiple agents. We do have
to
figure out who dictates the periodic update interval. One approach
might be to have a single master agent and multiple observer agents.
Feel free to propose something.
You (correctly) said that the agent approach saves some system resources
by not sending unnecessary signals if no one is interested in this
information. However, in all other cases the agent (method call)
approach is less efficient than signals.
ofono calls dbus-daemon, the daemon calls the agent, each call has a
reply, so the total number of D-Bus packets per notification comes to
4*n where n is the number of agents (or 2*n if the caller sets
NO_REPLY_EXPECTED flag).
If you are using signals, the number of packets involved is n+1 (one
packet from ofono to the daemon and then one to each interested client).
Obviously, (n+1) > 2*n (let alone 4*n) if and only if n = 0. Not to
mention that signals are significantly easier to use than (especially,
multiple) agents.
That said, this NetworkMonitor thing is what it is and you decide how it
works. If it doesn't suit our needs (and it doesn't) I just implement my
own (and I did). I'm not in the mood to argue whose implementation is
better. Everything can be done in so many different ways, so let a
hundred flowers bloom.
Cheers,
-Slava
Regards,
-Denis
7:47 p.m.
On 09/09/2017 11:30 AM, Slava Monich wrote:
Hi Denis,
> Hi Slava,
>>
>> In the Sailfish OS case, one is the positioning helper, and there's
>> the factory test app. That makes it at least two. The factory test
>> app often plays the role of the second client since it's touching
>> pretty much all the important interfaces in the system. And there
>> are 3rd party apps which we don't control.
>
> See? This wasn't that hard ;)
>
> How does the factory test app use this info? Does it need actual
> periodic updates or can it simply obtain this via the method call?
>
Our RIL plugin decides on the update rate internally, based on the
device state (limiting the rate when the screen turns off).
Different clients have different needs - some need updates only when
the screen is on (if they are just displaying something on the screen)
and some may always need updates (a background task collecting some
data or whatever). The optimal solution may be quite specific to the
environment where ofono is used.
> I'm open to the idea of supporting multiple agents. We do have to
> figure out who dictates the periodic update interval. One approach
> might be to have a single master agent and multiple observer agents.
> Feel free to propose something.
You (correctly) said that the agent approach saves some system
resources by not sending unnecessary signals if no one is interested
in this information. However, in all other cases the agent (method
call) approach is less efficient than signals.
ofono calls dbus-daemon, the daemon calls the agent, each call has a
reply, so the total number of D-Bus packets per notification comes to
4*n where n is the number of agents (or 2*n if the caller sets
NO_REPLY_EXPECTED flag).
If you are using signals, the number of packets involved is n+1 (one
packet from ofono to the daemon and then one to each interested
client). Obviously, (n+1) > 2*n (let alone 4*n) if and only if n = 0.
Not to mention that signals are significantly easier to use than
(especially, multiple) agents.
That said, this NetworkMonitor thing is what it is and you decide how
it works. If it doesn't suit our needs (and it doesn't) I just
implement my own (and I did). I'm not in the mood to argue whose
implementation is better. Everything can be done in so many different
ways, so let a hundred flowers bloom.
That last paragraph is a masterpiece! Well said!
Why not create a second interface .AsynchNetworkMonitor that sends
PropertyChanged signals. This interface can be disabled by default, but
can be requested by setting to
org.ofono.Modem.AsynchronousNetworkMonitorEnabled to 'true', at which
point the interface is created on the modem object...?
/Jonas
Cheers,
-Slava
>
> Regards,
> -Denis
>
_______________________________________________
ofono mailing list
ofono(a)ofono.org
https://lists.ofono.org/mailman/listinfo/ofono
2:15 a.m.
Hi Jonas,
Why not create a second interface .AsynchNetworkMonitor that sends
PropertyChanged signals. This interface can be disabled by default, but
can be requested by setting to
org.ofono.Modem.AsynchronousNetworkMonitorEnabled to 'true', at which
point the interface is created on the modem object...?
You're of course free to do anything you want, but it doesn't mean
upstream will take it :) I refer you to our design philosophy document
(found in doc/ofono-paper.txt), Section 4.2 and 4.3. What you propose
goes fully against that philosophy.
Regards,
-Denis
2:11 a.m.
Hi Slava,
On 09/09/2017 04:30 AM, Slava Monich wrote:
Hi Denis,
> Hi Slava,
>>
>> In the Sailfish OS case, one is the positioning helper, and there's
>> the factory test app. That makes it at least two. The factory test
>> app often plays the role of the second client since it's touching
>> pretty much all the important interfaces in the system. And there are
>> 3rd party apps which we don't control.
>
> See? This wasn't that hard ;)
>
> How does the factory test app use this info? Does it need actual
> periodic updates or can it simply obtain this via the method call?
>
Our RIL plugin decides on the update rate internally, based on the
device state (limiting the rate when the screen turns off).
And hopefully you understand why hard-coding the behavior in a plugin is
not a solution for upstream? Our solution must be generic enough where
any behavior can be implemented, perhaps with a bit more pain on the
integrator side. But the advantage is that it works for every piece of
hardware that has support for a particular feature.
You have the advantage that you have control or can assume how stuff
works on your platform. Hence you can implement such simplistic
behavior of turning serving cell updates to every minute with screen off
/ every 1 second with screen on. Unfortunately upstream cannot make
such assumptions, cannot rely on hacks and has to implement proper
solutions.
Different clients have different needs - some need updates only when the
screen is on (if they are just displaying something on the screen) and
some may always need updates (a background task collecting some data or
whatever). The optimal solution may be quite specific to the environment
where ofono is used.
Agreed. Upstream will try to provide APIs to enable you to do that. If
some API doesn't cover your needs, then feel free to contribute and make
things better. Complaining and then taking your ball and going home is
not conducive to upstream paying attention to your needs. Only through
active contribution can you influence things. Just saying...
> I'm open to the idea of supporting multiple agents. We do have to
> figure out who dictates the periodic update interval. One approach
> might be to have a single master agent and multiple observer agents.
> Feel free to propose something.
You (correctly) said that the agent approach saves some system resources
by not sending unnecessary signals if no one is interested in this
information. However, in all other cases the agent (method call)
approach is less efficient than signals.
ofono calls dbus-daemon, the daemon calls the agent, each call has a
reply, so the total number of D-Bus packets per notification comes to
4*n where n is the number of agents (or 2*n if the caller sets
NO_REPLY_EXPECTED flag).
Which we do by the way. The ServingCellInformationChanged method call
is already sent as noreply. It was not marked thus in the
documentation. It was an oversight that has been now fixed.
If you are using signals, the number of packets involved is n+1 (one
packet from ofono to the daemon and then one to each interested client).
Obviously, (n+1) > 2*n (let alone 4*n) if and only if n = 0. Not to
mention that signals are significantly easier to use than (especially,
multiple) agents.
I don't know what you're arguing here. Yes in an idealized world having
n agents is less efficient than having a signal with n observers.
Multicast is more efficient. No ****.
But do realize things are never so simple. You do have to pay a cost
for this, through complex signal matching data structures, having to set
up proper Match rules with dbus-daemon, and unsubscribing from such
signals is sometimes not possible. Some clients simply don't do this
properly, and a signal ends up being blasted out to way more clients
than your idealized model. But I digress as this isn't what was being
argued.
Jonas wanted all these to be actual properties. So a PropertyChanged
signal would be emitted for each and every one. Given that we have 20
odd properties defined, sending a signal for each one vs a single method
call out to the agent is more efficient. Yes we can perform comparisons
and only emit properties that changed. But most of these are signal
related, and so are extremely variable. The chance that they don't
change between updates is tiny.
Which by the way is what your vaunted 'own' implementation does. So its
not sending 1 signal per update either, is it? You might want to fix
that as it doesn't fit your ideal world view ;)
So regardless of how you look at it, the agent approach is more
efficient than having everything as a property. That was my original point.
And by the way, the agent approach lets us figure out when a client has
died and updates are no longer needed. So we can intelligently turn off
communication with the modem and not waste resources. We can also more
easily control access permissions (as in which application can enable
updates in the first place) via the security framework. Those are huge
design advantages in our view.
That said, this NetworkMonitor thing is what it is and you decide how it
works. If it doesn't suit our needs (and it doesn't) I just implement my
own (and I did). I'm not in the mood to argue whose implementation is
better. Everything can be done in so many different ways, so let a
hundred flowers bloom.
And again I see you taking your ball and going home ;)
Regards,
-Denis
2:03 a.m.
Hi Jonas,
On 09/07/2017 04:47 AM, Jonas Bonn wrote:
On 09/07/2017 06:23 AM, Nishanth V wrote:
> added new DBUS methods RegisterAgent and UnregisterAgent to
> Networkmonitor interface so that any client of ofono can register for
> serving cell updates. Added new agent interface NetworkMonitorAgent
> with two methods, ServingCellInformationChanged and Release.
My spontaneous reaction to this is that it feels like the wrong
approach. Why not make the properties actual DBus properties and
provide PropertiesChanged events for them? That begets you the same
functionality for "free".
Because most clients don't care about these properties, so there's no
sense in broadcasting them out to the wide world. Even if nobody
actually subscribes to the PropertyChanged signal on this interface we
still must send messages to the dbus daemon, and that means extra
context switches, extra cpu time, etc.
Besides, this interface will be eventually expanded to cover neighbor
cells as well. And that can get quite chatty.
It's interesting that you posted this now because I've spent the last
week grumbling over this API myself as I'm putting support for the
NetworkMonitor interface into the QMI modem class. My thoughts:
i) There's duplicate information all over the place. MNC, LAC, etc.
are provided in three different interefaces: NetworkRegistration,
NetworkMonitor, and NetworkOperator.
Why is this a problem? And strictly speaking NetworkOperator only
provides MNC/MCC which can be different from the current serving cell.
This can be used by the user to select a particular operator to register
with.
ii) The NetworkOperator interface caught me off guard as it appeared
out of nowhere! There is no documentation for the interface and the
implementation seems to be missing from most device classes.
You might want to read doc/network-api.txt more carefully then :) It
has been documented since 2009. Note that there is no 1:1
correspondence between atoms and interfaces. NetworkOperator does not
have an underlying atom and is managed entirely by netreg.
iii) The polled nature of the NetworkMonitor object surprised me.
This
seems like a natural case for notifications and the patch series in this
email thread underscores this fact.
Polled? The GetServingCellInformation() method call is polled. But it
isn't meant to be used often. The agent version leaves it up to the
driver on how to implement the periodic update. We looked at a few AT
command specifications for this and while some of them support true
unsolicited notifications, most don't. For example, XMM 71xx modems
only support direct query and periodic mode while others only support
direct query.
The interface is quite experimental and the exact semantics of the
period parameter need to be figured out. I suspect it is mostly going
to be a hint that the application can provide for how often the updates
are needed. If true unsolicited notifications are supported then the
driver can ignore it.
iv) For QMI, at least, the NetworkRegistration atom is monitoring
asynchronous events that contain essentially all the information needed
by the NetworkMonitor atom. The NetworkRegistration atom could just
save these values and provide the NetworkMonitor interface in the same
module instead of having an additional netmon module, but:
Unfortunately we have more than QMI modems to worry about. All this is
generally done via proprietary AT commands, so having it inside the
netreg atom will not work.
Also consider that we will not be able to support this for all hardware,
either due to lack of support in the firmware or lack of documentation.
So having this on a separate atom/interface makes it easy for
applications to adjust their behavior. E.g. if the interface is
present, then one can count on the functionality being there. If not
present, then behave accordingly.
a) We end up monitoring unnecessary state in case nobody is actually
listening to the NetworkMonitor updates. This seems to have a
negligible impact on performance so it probably does not matter.
Well, you could enable / register to these notifications only if
periodic updates have been enabled...
b) ofono does not use this approach anywhere else that I can see...
every atom/interface is provided in it's own module.
This is preferred. Besides, qmi_service_register can support multiple
clients, no?
v) Point iv) applies to the NetworkOperator interface, as well, if we
decide to implement it... should we?
I won't comment until you familiarize yourself with src/netreg.c
vi) I suspect that other device classes (AT, etc.) provide asynchronous
network quality updates, as well; if they do not, however, then it seems
natural to move the polling of this state into the device class driver.
See above. Many of them don't.
Sorry for hijacking this for a bit of QMI implementation discussion
but
it seems relevant in trying to understand what it is that the
NetworkMonitor interface is supposed to be.
Don't be sorry, it is nice that others are looking at this and providing
feedback.
Regards,
-Denis
6:11 a.m.
Hi Nishanth,
On 09/06/2017 11:23 PM, Nishanth V wrote:
added new DBUS methods RegisterAgent and UnregisterAgent to
Networkmonitor interface so that any client of ofono can register for
serving cell updates. Added new agent interface NetworkMonitorAgent
with two methods, ServingCellInformationChanged and Release.
---
doc/networkmonitor-api.txt | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
All patches in this series have been applied, thanks.
Regards,
-Denis
1835
days inactive
1837
days old
17 comments
4 participants
participants (4)
-
Denis Kenzior -
Jonas Bonn -
Nishanth V -
Slava Monich