Issues With Signal, Was Working Fine
seniorm0ment opened this issue · comments
I use Signal for a lot of my calls (There's no way to set it as the default dialer), but it used to work fine no issues for months. Pilfer was kept in passive mode, and when I called someone or someone called me through Signal (or default phone) they could hear me no problems.
But lately (past like 2 days maybe) not sure what changed, haven't seen any updates or anything but they can't seem to hear me through Signal unless I disable PilferShush and call them back, Not sure what's going on.
Coming back just to comment, I have not fixed the issue but I saw I wasn't on the latest version, I was on 4.1.2, so I upgraded the 4.2.0 and the issue still persists.
Just wanted to be clear, it doesn't seem to be related to your latest update because the issue was happening on the previous.
But again, it never used to do it on the same version, so I'm honestly a little unsure what happened or changed?
It's an LGv40 running Android 9
Its quite possible that the jammer wasn't working properly for 9.x a few versions ago due to the lack of MediaRecorder instance. So what you are now getting is proper function as per how Android OS allows only one user app to access the microphone at a time. I use Signal as well and have given it Telephony permission, this may elevate Signal to privileged access and allow it to gracefully bump the jammer off the mic. But if it doesn't for you then its probable that Signal is behaving just as a typical user app would and therefore is jammed, as per intention.
To my knowledge I don't recall it updating between when it worked and started having issues, and I believe it both worked then stopped working on 4.1.2 as stated above.
What exactly are you referring to as the Telephony permission though?
Telephony or Telephone. Means that a user app can access the gsm/lte etc phone call part of the phone. Would/should mean that it can bump off any other user app using the mic.
How exactly do you go about giving it Telephony permission? I don't recall ever coming across an option to do this in Android or Signal.
If I go to a user not using signal, I can still call them with the icon in signal, it passes through to the stock dialer app. And the stock dialer works and all. It's just when calling people in Signal (to users who use Signal).
In your Apps permissions page you will find a list of requested/granted permissions. Stock dialer is a system app that will boot any user app off the mic. signal as a user app will not. that is how its supposed to work and is working. you will have to stop the passive jammer when making a signal user app call.
Just checked, Signal has phone permissions, and it has default message app permission. I can't set is as default phone on my device. I actually did request for this to be a feature on Signal community but it hasn't gotten a lot of attraction, doubt it's a concern of theirs anytime soon.
Maybe is it possible for you to give an option to allow it to bump default messenger as well if it's open? Not sure what abilities you can use as far as whitelisting goes, I assume it has no clue what apps are trying to access microphone. But if you could have it detect the defaults opened in forground, again maybe give an option to pause on open of default messenger (and I say option because not everyone may trust their messenger or be making calls through it like Signal)
Any updates with this?
I guess specifically with the latter part of my last post
There is no direct java API method i'm aware of that can poll the OS and return the name of a process is requesting use of the microphone. The only info the jammer app can automatically attain is when its own request to access the microphone is denied with a returned error integer. This integer is not very informative...
To do the sort of thing you are asking about would require some extra permissions/methods such as get all running processes, which ones have mic permission and maintain a userapp database etc. At this stage, for me, any sort of whitelisting like this would mean that the jammer app becomes too invasive.
I know this doesn't help you but i have kept this issue open as it is a good idea that may end up being implemented one day despite the misgivings mentioned above. Also, the minimum API for the jammer app may be bumped up from the current 4.3 to 6.x in which case a lot of things held back from being included in the app are possible, such as auto boot and whitelisting...
Also, Android is changing its behaviours for microphone/audio access from 9.x upwards and that is of more immediate concern for me and this jammer app as it is based entirely around exploiting a particular API function of single userapp access of the microphone at a time. Android has now at API 10 enabled concurrent access...
I know this doesn't help you but i have kept this issue open as it is a good idea that may end up being implemented one day despite the misgivings mentioned above. Also, the minimum API for the jammer app may be bumped up from the current 4.3 to 6.x in which case a lot of things held back from being included in the app are possible, such as auto boot and whitelisting...
Good to know, I was just curious I stated the "default messaging app" because I saw in the docs and previous comments the app seems to have no issues detecting the "default dialer" so I figured maybe there was something with it being a default app that it's able to detect in it's current state. The issue being Signal can't be set as the default dialer but can be messenger if you see where I'm getting at there.
Also, Android is changing its behaviours for microphone/audio access from 9.x upwards and that is of more immediate concern for me and this jammer app as it is based entirely around exploiting a particular API function of single userapp access of the microphone at a time. Android has now at API 10 enabled concurrent access...
Rip, that sounds stupid I don't know why they would do that.. I can't imagine a single time anyone would use the microphone for multiple applications at once, unless it was something where you wanted to record with an external mic and the internal.. but this seems way to permissive for something like that.
Can't imagine any way around that unless Pilfer can block all microphone access and whitelist apps. But that doesn't seem likely without root functionality. Idk. Don't get me wrong, I get Googled Android is not the best solution for privacy, but not all devices can be rooted and/or flashed with custom roms, so pilfer does give a minor sense of privacy even if fairly pseudo seeing it's software based.
I agree. The best for a worse-case googled android scenario is that the user of the phone is "aware" of what is going on with their phone and can control it. Ultimately i think this is where I aim this jammer app to have as its lowest common userbase.
The concurrent use is an extension of allowing a userapp to record audio while also allowing a hotword detector app (such as google, shazam etc) to "listen in" checking for the hot word phrase and then take over the mic and do whatever processing it does next. There is also some priority measuring for the type of app that wishes to access the mic and whether it can boot others off the mic, but documentation is a bit thin at present. This may also be linked to the endless requests for call recording functions to be added to the java API; which can be done at the native code level by rerouting audio through an intermediary but it is exceptionally rare.
The concurrent use is an extension of allowing a userapp to record audio while also allowing a hotword detector app (such as google, shazam etc) to "listen in" checking for the hot word phrase and then take over the mic and do whatever processing it does next. There is also some priority measuring for the type of app that wishes to access the mic and whether it can boot others off the mic, but documentation is a bit thin at present. This may also be linked to the endless requests for call recording functions to be added to the java API; which can be done at the native code level by rerouting audio through an intermediary but it is exceptionally rare.
Ah this makes sense I guess, nothing I'd ever use as I don't even use the voice assistants but I get where they're going with the idea. It definitely seemed a bit too permissive still imo, so I definitely hope they kinda refine that. I guess we'll see when docs get more added, but I definitely hope to see the best that can be done with this app. To my knowledge you're the only person who has an application that does this, at least without root. I kinda get why, but again, imo it's better than nothing.
Thanks for the feedback too. Its funny but this app started out as a near ultra high frequency jammer and is now primarily a general purpose microphone blocker.
Remember, even if you dont actively use voice assistants, that type of code is still present in google search and some of the google android libraries that are part of Google Apps. Sadly there is no way in java API that i have found to check for either HOTWORD = 1999 (always-on software hotword detection) or AUDIO_SOURCE_VOICE_RECOGNITION = 6, so i have to limit my searching to SDK name signatures known by me (currently 46).
An idea for this would be to not make the notification go away when you click stop passive, to make it easier to toggle on and off when you get a call on signal for example.
Glad to see some activity with the app, thanks!
Unfortunately i can't rely on a full notification on android 4.x and upwards. Currently the notification is an integral part of the background passive jamming service which is the only way to get a relatively long time audio process running in android. and part of this api requirement is that a notification is posted which can be permanently dismissed by the user should they want to. the toggle part of the notification isn't visible or even available in some android versions, so i can barely rely on it it to even simply inform the user that the jammer is running. As soon as the passive jammer is stopped, the service is destroyed taking the notification with it.
So sadly, this idea is bundled with all the other good ideas that would be great to implement if there was consistency over the range of Android APIs that this app is installed on. its very frustrating.
Thanks Google .-.
I hate to bring it up again, but wouldn't using a device administrator solve the issue?
A camera blocking app I use uses a device administrator, and the user can toggle the service off and on with a quick setting tile.
Couldn't this same method (including the notification) be used in Pilfershush?
Device Administrator for camera and some other things is being reduced in function for Android 9 with warnings to then being nuked in Android 10 with Exceptions.
From a design point of view, PilferShush is trying to allow user control over certain functions that are, at the API level, seemingly benign, but in practice are routinely abused by adtech, corporates, governments et al. So for this motivational reason I am reluctant to give the app any over-the-top powers with respect to its simple purpose: blocking the microphone.
Another point is that automated responses to automated abuses conflate the problem. It also removes human agency from using the device and in effect, as far as I'm concerned, makes the human redundant. Which could be seen as ironic given all that computers and software are meant to provide. But the idealism of 1980s "Silicon Valley" is alien compared to today's IoT landscape of ubiquitous surveillance computers that have disappeared into the background and are deployed by thoroughly untrustworthy for-profit corporations.
I wish there was an allow Application setting so I could actually use Signal, since the sound quality is better and overall just works excellently in place of normal cellular communication.
Currently there is no way of definitively knowing which particular application is accessing the microphone at any time without some very low level access to the underlying OS (ie root access). So at the best it would be a guess. There is a change in Android 10/11 api that now has notifications when another system/user app is going to take over the microphone (see https://source.android.com/compatibility/android-cdd#5_4_5_concurrent_capture ) but that only allows identifying the type of app and even then only by association.