Notification is still active when app is not

[puppykickr]

I have found a bug, I believe. ZTE 558VL Android 7.1.1 I turned the app on, and selected 'passive'.

The notification went up, and the dialog on the screen indicated that the passive jammer was activated.

The notifications, both on the status bar and the banner, were both active.

I later went into the app, and although the notification was still up, the app dialog stated that the passive jammer was not running.

I discovered that if the App Manager is cleared, then PilferShush stops working, but the notification remains unless the app is actually force stopped.

This means that the user could believe that the device is protected even when it is not.

If the jammer(s) get turned off, I would think that the notification(s) should also go off, allowing the user to know that the app is not running.

As it is now, the user has no clue unless the app dialog is checked regularly.

I have turned battery optimization off for the app, and so it should only occur when I manually touch 'clear' on the App Manager.

Just to be clear, the App Manager that I am referring to is the one built into the device (not some app I downloaded), accessible via the right hand button on the navigation bar.

After a bit more testing, I find that if the jammer(s) are turned off manually, then the App Manager is cleared, the notifications will turn off.

But the fact remains that if the app is turned off by another means, the noifications will still be active although the jammers will not be.

[kaputnikGo]

Thanks for posting. Is your phone the ZTE Axon 7 as found on gsmarena and XDA?

This is, I believe, one of the side effects of the way the app has been made. It was designed (and used) as a foreground app. The notification is literal in that it is only notifying the user that the jammer process is running. There are no actions from within the notification other than a "return to app" as a default to do something when there is a touch event. The main app activity is and should remain in control at all times and its state is (should) be the true state. If it says it is running then it should be running, if it says its not, then it should not be running, etc.

One problem is the increasingly aggressive way the android OS manages apps that run for long time periods or dont run in the foreground. Overall this is a good thing and this app tries to behave appropriately to comply with expected behaviour and following dev guidelines. So it was never intended that this app run for long periods of time. This is something that is being re-examined for a future update.

This app is tested and used on an AOSP version android and there are no "app managers", only the Settings:Apps:App Info view that is built into the OS. If the PilferShush passive jammer is running and I force stop the app from this view then the notification is killed as well. This means I'm not sure what "app manager" you are referring to but i would assume its installed as part of the ROM variant or even as part of the launcher app. It may appear under the User App Scanner found in the main nav bar menu.

Ultimately i think this issue falls within the potential jammer as a background service issue. And this is something that is still being looked into. The main concern is that it is possible to dismiss/hide a background service notifications while the jammer is running thereby causing confusion if for instance at a later date a VoIP app call is received and the caller can't hear you. This is something I cant allow to happen with this app, even as an accident.

The android OS doesnt (to my knowledge) provide an API that allows an app to determine which other app is requesting microphone access, So even with a whitelist it would require some more invasive functions in the app so that it could "guess" which running process is trying to gain access. And then hope that the delay before access is granted is handled gracefully by the requesting app. In my testing with other mic using apps, they check once at start and then a fail is either a crash, hang, disabled or even appear to record audio when it actually doesnt.

[puppykickr]

My phone is the ZTE 558VL, android version 7.1.1

I use VOIP extensively, and have never had an issue with the mic not working properly.

The issue seems to be that the notification is stating that the passive jammer is running, but when I enter the app the dialog states that it is not running.

This is regardless of the position of the jammer button.

In order for the app dialog to state that the jammer is working, the app must be force stopped (at which point the notification finally disappears), reopened, and the jammer button activated.

My biggest problem with this whole thing is that the notification clearly states that the jammer is running, even when I confirm within the app that it is not.

At that point the jammer on/off button has no effect on the status dialog or the notification.

If the notification were to be useful, then it would have to vanish when the app deactivated.

As it is now, the notification gives a false sense of security. The user has no idea if the jammer is really still running or not, regardless of the presence of the notification or what it states.

I am not complaining here, I am only telling you what is happening on my device.

Would it help to clairify the issue if I were to send a video? I should be able to make a short video to show exactly what I am trying to describe.

Grant Ryan Swan (puppykicker)

On Wed, Dec 5, 2018, 18:26 kaputnikGo <notifications@github.com wrote:

Thanks for posting. Is your phone the ZTE Axon 7 as found on gsmarena and XDA?

This is, I believe, one of the side effects of the way the app has been made. It was designed (and used) as a foreground app. The notification is literal in that it is only notifying the user that the jammer process is running. There are no actions from within the notification other than a "return to app" as a default to do something when there is a touch event. The main app activity is and should remain in control at all times and its state is (should) be the true state. If it says it is running then it should be running, if it says its not, then it should not be running, etc.

One problem is the increasingly aggressive way the android OS manages apps that run for long time periods or dont run in the foreground. Overall this is a good thing and this app tries to behave appropriately to comply with expected behaviour and following dev guidelines. So it was never intended that this app run for long periods of time. This is something that is being re-examined for a future update.

This app is tested and used on an AOSP version android and there are no "app managers", only the Settings:Apps:App Info view that is built into the OS. If the PilferShush passive jammer is running and I force stop the app from this view then the notification is killed as well. This means I'm not sure what "app manager" you are referring to but i would assume its installed as part of the ROM variant or even as part of the launcher app. It may appear under the User App Scanner found in the main nav bar menu.

Ultimately i think this issue falls within the potential jammer as a background service issue. And this is something that is still being looked into. The main concern is that it is possible to dismiss/hide a background service notifications while the jammer is running thereby causing confusion if for instance at a later date a VoIP app call is received and the caller can't hear you. This is something I cant allow to happen with this app, even as an accident.

The android OS doesnt (to my knowledge) provide an API that allows an app to determine which other app is requesting microphone access, So even with a whitelist it would require some more invasive functions in the app so that it could "guess" which running process is trying to gain access. And then hope that the delay before access is granted is handled gracefully by the requesting app. In my testing with other mic using apps, they check once at start and then a fail is either a crash, hang, disabled or even appear to record audio when it actually doesnt.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kaputnikGo/PilferShushJammer/issues/8#issuecomment-444702676, or mute the thread https://github.com/notifications/unsubscribe-auth/AqyDf5K7LucqClt_ht-wbnbcCrvpLwqXks5u2GQugaJpZM4Y_3Va .

[puppykickr]

Also, about the issue with other apps that need the microphone from time to time, wouldn't giving PilferShush 'Phone' permissions allow for this? At least the VOIP apps should work at that point, right?

Grant Ryan Swan (puppykicker)

On Thu, Dec 6, 2018, 01:59 puppykicker <demononground@gmail.com wrote:

My phone is the ZTE 558VL, android version 7.1.1

I use VOIP extensively, and have never had an issue with the mic not working properly.

The issue seems to be that the notification is stating that the passive jammer is running, but when I enter the app the dialog states that it is not running.

This is regardless of the position of the jammer button.

In order for the app dialog to state that the jammer is working, the app must be force stopped (at which point the notification finally disappears), reopened, and the jammer button activated.

My biggest problem with this whole thing is that the notification clearly states that the jammer is running, even when I confirm within the app that it is not.

At that point the jammer on/off button has no effect on the status dialog or the notification.

If the notification were to be useful, then it would have to vanish when the app deactivated.

As it is now, the notification gives a false sense of security. The user has no idea if the jammer is really still running or not, regardless of the presence of the notification or what it states.

I am not complaining here, I am only telling you what is happening on my device.

Would it help to clairify the issue if I were to send a video? I should be able to make a short video to show exactly what I am trying to describe.

Grant Ryan Swan (puppykicker)

On Wed, Dec 5, 2018, 18:26 kaputnikGo <notifications@github.com wrote:

Thanks for posting. Is your phone the ZTE Axon 7 as found on gsmarena and XDA?

This is, I believe, one of the side effects of the way the app has been made. It was designed (and used) as a foreground app. The notification is literal in that it is only notifying the user that the jammer process is running. There are no actions from within the notification other than a "return to app" as a default to do something when there is a touch event. The main app activity is and should remain in control at all times and its state is (should) be the true state. If it says it is running then it should be running, if it says its not, then it should not be running, etc.

One problem is the increasingly aggressive way the android OS manages apps that run for long time periods or dont run in the foreground. Overall this is a good thing and this app tries to behave appropriately to comply with expected behaviour and following dev guidelines. So it was never intended that this app run for long periods of time. This is something that is being re-examined for a future update.

This app is tested and used on an AOSP version android and there are no "app managers", only the Settings:Apps:App Info view that is built into the OS. If the PilferShush passive jammer is running and I force stop the app from this view then the notification is killed as well. This means I'm not sure what "app manager" you are referring to but i would assume its installed as part of the ROM variant or even as part of the launcher app. It may appear under the User App Scanner found in the main nav bar menu.

Ultimately i think this issue falls within the potential jammer as a background service issue. And this is something that is still being looked into. The main concern is that it is possible to dismiss/hide a background service notifications while the jammer is running thereby causing confusion if for instance at a later date a VoIP app call is received and the caller can't hear you. This is something I cant allow to happen with this app, even as an accident.

The android OS doesnt (to my knowledge) provide an API that allows an app to determine which other app is requesting microphone access, So even with a whitelist it would require some more invasive functions in the app so that it could "guess" which running process is trying to gain access. And then hope that the delay before access is granted is handled gracefully by the requesting app. In my testing with other mic using apps, they check once at start and then a fail is either a crash, hang, disabled or even appear to record audio when it actually doesnt.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kaputnikGo/PilferShushJammer/issues/8#issuecomment-444702676, or mute the thread https://github.com/notifications/unsubscribe-auth/AqyDf5K7LucqClt_ht-wbnbcCrvpLwqXks5u2GQugaJpZM4Y_3Va .

[kaputnikGo]

hang on, if the passive jammer is running you are still able to make VoIP calls? if this is so can you tell me which VoIP app you use so i can test against it, thanks.

also, these issues are hopefully going to be no longer a problem with the re-write of the jammer as a foreground service.

[kaputnikGo]

Aight, the app (version 3.0.1) is now updated to run services which now means the state should be reliable, the notifications accurate and behaviours proper. Its pushed to google play but if you are getting on fdroid that may take a little longer. Hopefully this version works for you, and thanks for the issue reports :)

[puppykickr]

There are two VOIP apps that I have used without needing to turn PilferShush off.

Telegram

Dingtone

Maybe they override any other app that has access to the microphone when they are active?

The idea that they seem to be not affected makes me wonder if PilferShush was functioning on my device after all, considering that I only recently noticed the discrepancy between the app dialog and the notification statement.

My girlfriend has an identical device, and has these same apps as well.

The other week, she called the home phone from her cell, and she could hear me but I could not hear her.

She was not using VOIP, however. She was on cellular.

[kaputnikGo]

Its quite possible that PilferShush hasnt been working properly as per your previous posts - this is hopefully fixed now with the latest update.

However, whether or not a VoIP app gets blocked can be down to several things: whether the VoIP app is making a phone call or a data call.

The expected behaviour is the phone call (android.permission.CALL_PHONE) should automatically bump PilferShush off from blocking the microphone as it is basically invoking the android phone app with " Intent callIntent = new Intent(Intent.ACTION_CALL);". I assume this type of call would only occur if you are calling a landline or mobile phone number of someone that doesnt have the VoIP app.

The data call ( VoIP to VoIP ) should get blocked by PilferShush as it is not a phone call as such but is simply requesting microphone access as per any other user app that records audio (android.permission.RECORD_AUDIO).

How any VoIP app behaves if it doesnt get microphone access is unknown by me. But I do have the telegram app so i can test how it works.

[puppykickr]

I have not yet tested the VOIP apps with the new version, but will soon and leave a note.

The new version has cleared up the other issues that I had.

If I need to turn the app off manually to make a VOIP call, that is just fine with me, as it shows that PilferShush is indeed working.

[kaputnikGo]

Excellent, thank you again for the help with this!

[puppykickr]

OK.

Another few days, and I have discovered that after the passive jammer has been on, the app dialog is saying that an interruption, requested by Audio Focus, has occurred.

I thought little of this, but did notice that each time I enter the app, it is noted again, so that multiple instances are showing.

Now today, I see this, and out of curiosity engage the active jammer.

The dialog and sounds show the active jammer to be working.

Then I disengage the passive, and the active.

The dialog and notifications respond correctly, however the sounds of the active jammer are continuing on!

I am listening to them in amusement as I type this email.

The notification is off and the app dialog states that both jammers are off.

Just letting you know what is going on.

Grant Ryan Swan (puppykicker)

On Mon, Dec 17, 2018, 05:17 kaputnikGo <notifications@github.com wrote:

Excellent, thank you again for the help with this!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kaputnikGo/PilferShushJammer/issues/8#issuecomment-447810546, or mute the thread https://github.com/notifications/unsubscribe-auth/AqyDf779UrHblhkCRyIlEfyYTwkKsWSAks5u531QgaJpZM4Y_3Va .

[kaputnikGo]

i think i know what that is. The app originally used the audio focus request as a means to engage/disengage the jammers but that was removed for the passive when the it started using a service. the dialog remains as part of the resume function that needs fixing but it depends on VoIP behaviours etc. I think i have enough info now to make some assumptions. i think i will end up giving all control over to the user and hope they dont hide notifications and know to stop a jammer for wanted calls etc..

The next update is to focus on the active jammer as it is both noisy, inefficient and presently not a useful jamming technique for the user. One of the major problems with android is the java method of AudioTrack for making sounds is really quite a bit crap, most apps will use a native library of some sort to bypass the java. So now im thinking about whether or not i want to import a whole library just to make some simple sine waves...

thanks for the help!

[puppykickr]

Any time. I enjoy testing apps.

I might not be the brightest bulb in the box, but I can give feedback on real life issues from a consumer point of view.

I also am interested in simple to use security apps, such as this one.

Is there any point in time where a camera jammer is possible or could be implemented?

[kaputnikGo]

Well its very appreciated thank you. The only way for a dev to understand how their app is behaving in use is through direct feedback and the occasional crash reports that google play issue. There are so many versions of android and so many variants that there really isnt a guarantee of any function working as intended.

As for a camera jammer, i dont really know much about the camera api. The only tracker references to cameras that i have seen while researching hidden microphone use is that they can use the front facing camera to take photos of the user. The other use i have seen is with scanning the photos folder for filenames, dates and numbers etc.

There maybe something on f-droid.org that is suitable. otherwise put a sticker over the front facing camera(s) :)

[kaputnikGo]

Actually, this: https://developer.android.com/guide/topics/admin/device-admin leads to this: https://developer.android.com/reference/android/app/admin/DevicePolicyManager

which has a public void setCameraDisabled (ComponentName admin, boolean disabled)

[puppykickr]

Thank you very much.

Although there really wasnt anything there I could use, I saw 'device administrator' and went on a search.

From there I found several apps that have device administer rights over the camera.

Unfortunately, none on F-Droid.

I found two that I like well, and am trying them out.

I have a nifty little app from F-Droid called Microphone, which actually uses the microphone on your phone like one on a PA system.

It give feedback readilly on the built in speaker, but works just fine through bluetooth, or any other system that allows distance between the microphone and the speaker.

So far, it appears that PilferShush is working.

If PilferShush is engaged (passive) the microphone is not working.

If Microphone app is engaged first, then PilferShush, I get a dialog stating something to the effect of 'Passive jammer not initializing, possibly because the microphone is in use.'

I think this is how you want it to perform, if I am correct.

I checked these camera apps the same way, both with the built in camera app and other apps I have that use the camera.

Maybe it is possible to integrate a device administrator for both the camera and the microphone.

A notification, and possibly an icon or two in the quick settings, would be a very convenient way for the user to access control when necessary.

Administrator control would also stop your app from being shut down by the device, allowing it to run continuously, if I am not mistaken, correct?

It seems that this could solve some issues.

There are a few apps on the PlayStore that have both camera and microphone blocking, but they have ads or require payment.

Your app seems to be the only microphone jammer on F-Droid, and I found no camera blockers at all.

If your app were to have both of these options yours would be the only one of its kind on F-Droid.

Grant Ryan Swan (puppykicker)

On Fri, Dec 21, 2018, 16:49 kaputnikGo <notifications@github.com wrote:

Actually, this: https://developer.android.com/guide/topics/admin/device-admin leads to this: https://developer.android.com/reference/android/app/admin/DevicePolicyManager

which has a public void setCameraDisabled (ComponentName admin, boolean disabled)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/kaputnikGo/PilferShushJammer/issues/8#issuecomment-449517566, or mute the thread https://github.com/notifications/unsubscribe-auth/AqyDf_XBDIBmnP9g5c5cSXQh_17Kvxokks5u7WWCgaJpZM4Y_3Va .

[kaputnikGo]

Correct, when you use the Microphone app first and then try PilferShush it will not be able to work as the Android system currently only allows one user installed app access to the mic at a time. The system voice call app (not VoIP) will kick all apps off the mic. This design feature is the entire reason that Pilfershush can exist.

Adding a camera block switch to the PilferShush app is relatively simple, maybe having it engage when the passive jammer is engaged as well. But having device admin rights im not sure about yet. the addition of extra permissions is one thing i am trying to avoid. An example is to give the app internet permissions and access so that updates to the SDK list could take place independent of app updates via the stores. this would also require storage read/write access. But i think it safer and easier to continue this way as new SDKs seem to only be uncovered at the rate that updates occur anyway.

More research. next update i will include a menu switch for camera blocking to see how it goes.