Does anyone know what changes have been introduced on SFOS 5.x which prevent the signal in question from working?
In my own application, which I’ve been using for many years, I use it to determine when there is an incoming call by connecting the lineIdChanged signal to onIncomingCall() slot, which then further processes it:
result = QDBusConnection::sessionBus().connect(“”, “/calls/active”, “org.nemomobile.voicecall.VoiceCall”, “lineIdChanged”, this, SLOT(onIncomingCall(const QDBusMessage&)));
It used to work perfectly fine on SFOS 4.x (I still have it working perfectly fine on the 10 III with SFOS 4.6.x.x onboard) whereas it no longer works on SFOS 5.x (three different devices), and I can’t find why it is so. I am successfully connected to the onIncomingCall() slot (well, at least result returns true) but the lineIdChanged signal is never emitted.
Does it take some additional permissions on SFOS 5.0 compared to 4.x, or has this DBus call been blocked from being used in applications? Sailjail? What can I do to make it work again? It is an application for solely my own private use, so any way to make it work would be good - even restricting Sailjail from blocking this functionality, if that’s the case.
Yes, that’s one of my suspects . And I tried to analyze the changes on github, but I can’t find anything that might make it stop working….
One thing that I remembered and that suggests that special rights / permissions may now be needed was the following sentence that @dcalistewrote here some time ago about the then newly introduced call filtering feature:
I can’t find any further information about it anywhere, though. I already PM’ed Damien, hopefully he would be able to shed some light on it.
As far as I remember, the lineIdChanged signal is not emitted anymore since the line id actually does not change during the call. It is set at construction and not changed after.
Maybe the best is to listen to the statusChanged signal on any object on the org.nemomobile.voicecall.VoiceCall. When a call is incoming, this signal is emitted with the STATUS_INCOMING (value 5), see abstractvoicecallhandler.h in voicecall/lib/src, for an object with a path like /calls/<uid> ?
Oh, that would explain everything Silly me! I should have tested it instantly, prior to looking any deeper and suspecting Sailjail et al…
As you suggested, I will change it to whatever else can signal a new call (no matter if incoming or outgoing) and then see if I can further process it.
Thank you so much Damien! I will test it and report back!
The original issue seems to be resolved. But, reading about the changes in voicecall-manager, Ofono, and similar components always make me suspect that they are the root cause of a still present bug preventing to make a call ( Contact app / telephone history - #38 by pawel.spoon ). My question: is telephone stack (ofono), released as open source and somebody with enough knowledge could inspect it - as from this thread I understand that some of you have enough knowledge?
Just like Damien wrote above, the actual problem was that the lineIdChanged signal is not emitted anymore on OS 5.x. Instead, one can use onStatusChanged signal. So I ended up with the following code, which works perfectly fine on OS 5.x:
void MyApp::listenForCalls() {
QDBusConnection::sessionBus().connect("", "", "org.nemomobile.voicecall.VoiceCall", "statusChanged", this, SLOT(onStatusChanged(const QDBusMessage&)));
}
void MyApp::onStatusChanged(const QDBusMessage &message) {
QString status = message.arguments().at(0).toString(); // get call status from QDBusMessage, incoming call is value 5
if (status == "5") { // it's an incoming call
QString path = message.path(); // get path of the object to extract call details from
QDBusInterface call("org.nemomobile.voicecall", path, "org.nemomobile.voicecall.VoiceCall", QDBusConnection::sessionBus());
QString lineId = call.property("lineId").toString(); // get calling number
}
}
Thank you VERY MUCH Damien for all your help and guidance!
. And I tried to analyze the changes on github, but I can’t find anything that might make it stop working….
Silly me! I should have tested it instantly, prior to looking any deeper and suspecting Sailjail et al…