Same bug on Jolla 1 phone:
Upgrading to 4.4 has broken Phonehook and I can’t seem to get it to reinstall (versioning repo issues so it might get fixed at some point), it’s made me realise how brittle it is, to rely on an application for call blocking. While I appreciate what @wetab73’s trying to do here, we really, really need this building into the OS.
5 Likes
My application is ready and I use it. It has configurable whitelist and blacklist mode and it does its job. It’s Sailjail friendly, including normal access to the contacts database, etc.
However, I am not releasing it yet because besides the ofono patch so that hanging up works correctly in certain networks, there is another problem to solve:
ofono is VERY SLOW to react to the call hangup command, and in many cases it takes it long enough to hangup the call for the first ring to be heard for about 1 second. I’ve noticed that it happens very rarely (almost never) on 3G, but if 4G network is in use (which gets switched to 3G when there’s an incoming voice call) then apparently such a switch from 4G to 3G delays hanging up the call enough for the ringtone to be heard for a second or so ALMOST ALWAYS.
I’ve tried to first silence the ringtone using
QDBusMessage m = QDBusMessage::createMethodCall("org.nemomobile.voicecall",
"/calls/active",
"org.nemomobile.voicecall.VoiceCall",
"silenceRingtone");
QDBusConnection::sessionBus().call(m);
but I can’t make it work at all.
I’m currently using
org.nemomobile.voicecall.VoiceCall.hangup
to reject calls, but maybe using
org.ofono.VoiceCallManager.HangupAll
turns out to be quicker…? I’ll need to further experiment with it in order to make it quick enough to always hangup the call BEFORE it manages to start ringing. Which, I’m afraid, won’t be easy. Only then I will release my app for public use.
2 Likes
Moving the “call again” button to a different screen position so that this would not happen is a feature request I have made before.
(btw, this is generic UI issue now in the modern world of uselessly slow UIs on multi GHz cpus)
2 Likes
I used to sometimes get that with Phonehook, if it’s any consolation.
Good luck with it, and it is appreciated. Sailfish is old enough now though, that it shouldn’t need doing, I think.
These days nuisance calls are common enough these days, that it should be built into every phone OS, by default.
1 Like
It takes the OS (or more precisely ofono) too long to process the hangup command, sometimes only after the phone already started ringing… This affects all such applications - mine, Phonehook, any other… I’ve just checked Phonehook source code and it uses the same D-bus call as my app to org.nemomobile.voicecall.VoiceCall.hangup
Maybe that’s why there is no such functionality built into the OS as currently it can’t be made working 100% OK, i.e. without the ringtone sometimes being heard for a second or two (and sometimes the phone UI appearing for a fraction of a second as well).
I guess it’d need some optimizations to ofono to make it work faster in this regard.
2 Likes
Sorry, which sources?
https://openrepos.net/content/adel/phonehook-aarch64
I had assumed that since adel die an aarch64 release that it ‘just worked’.
And, sorry, are you on 4.4?
Is there a possibility to postpone the ring until all checks are made? Or even measure the average delay and modify start of the rings for all calls with delay?
For me such w/a would be enough
Well, that’s what the aforementioned
org.nemomobile.voicecall.VoiceCall.silenceRingtone
should be doing. But it doesn’t seem to work at all.
The only other idea that comes to my mind would be doing things the reverse way, i.e. disable the ringtone completely for all calls and only enable it for whitelisted / not blacklisted calls when they come. But that would be risky, because if the command to enable the ringtone somehow didn’t work sometimes (and as we can see, many things do not work as expected here), important calls could be missed.
Please note that I did NOT say that Phonehook doesn’t work or anything like that. I was talking about ofono, and how its slugishness in processing the hangup call affects applications utilizing it, including the app I wrote for myself, and also Phonehook. As @skanky confirmed, in some cases hanging up the call by Phonehook takes place so late that the phone manages to start ringing before that (which also happens with my own app, and any other relying on ofono). This is ofono’s fault, not application’s.
And when talking about Phonehook sources, I only meant that it uses the same D-Bus calls to
org.nemomobile.voicecall.VoiceCall.hangup
and
org.nemomobile.voicecall.VoiceCall.silenceRingtone
as my own application. See lines 166-176 of blocking.cpp
That’s all I said about Phonehook.
Actually, I don’t know if/how it works at the moment, because I haven’t used it since I made my own app for that.
Last time I checked, it had problems related to SailJail, including no access to contacts or communications history.
No, I’m still on 4.3.0.15. I’m holding on with the update until @dcaliste can compile for me the patched ofono version built for 4.4, without which hanging up calls doesn’t work at all with my mobile operator (rejected call comes back after a few seconds and starts ringing again, as discussed in this thread).
Thanks! I didn’t mean to ‘cast aspersions’, I just wasn’t sure where to look at existing source. Adel will probably (hope, hope) update the Sailjail perms. If not, I’ll do it at some point.
Ah, got it. Thanks. I’d been ignoring that but ofono is evil fun.
Actually, at some point I fixed Phonehook myself for Sailjail, including full correct access to contacts and comms history (it took changing paths hardcoded in the source code). It was some time ago, so I’m not sure if I still have it and if it still works, especially on 4.4. But I’ll check it, and if I didn’t delete it and it’s still working OK then I might give it to someone who could take care of it.
2 Likes
Ah, that’d be cool! Thanks for your efforts!
That makes sense, I guess. The thing for me is, I’d much rather the brief ring & UI wake-up before cancelling, than the actual call coming through, which is much more annoying of the two.
Either way, thank you for doing this.
Sure, I understand. Same for me, actually…
Well, in some spare time I’ll give my app some final polish that it still needs and test it on OS 4.4 after I update to it (which may still take some time, as I can’t imagine not to have Patchmanager working, and it is currently reported as incompatible with 4.4, so I guess I’ll hold on with the update until it’s updated for 4.4) and then I will release the app.
One note: in its current form it is a normal application, without any background daemon, so in order to work it needs to be kept minimized to a cover. Later on, I will make a version with an autostarting background service/daemon, similar to Phonehook, so that its GUI doesn’t have to be running.
1 Like
That would great, many thanks!
Patchmanager is working on 4.4
I haven’t updated any of my devices to 4.4, so no idea if it will work as is. And haven’t played with sailjail yet.
But from the discussions, I see @wetab73 have a few updates for sailjail. If you could spare the modifications to the community, we could test it and build a new version.
Though, I think building just a new app for blocking numbers (without the overlay or internet search of phonehook), would be a better way to put our efforts on.
@wetab73, would it be feasible for you to share a github/gitlab repo of your app ? I guess a few of us can help one way or another in coding and testing.
1 Like
I was of course hoping for the overlay and search functionality. But I don’t actually need the blocking 
It’s sad, but only people I know call me. Sigh.