Battery Usage 3.xx about pilfershushjammer

[kaputnikGo]

Interesting (and annoying huh). Version 3 uses background services to run the jammers so it may be something to do with the way these operate. I also use LineageOS so i can test on some devices. I dont think MicroG should have any impact as the PilferShush app uses no libraries or frameworks other than the androidX appcompat and legacy libs for backwards compatibility to android 4.3

But in the meantime the last ver 2 build is still available to install from the git repo here: https://github.com/kaputnikGo/PilferShushJammer/releases/tag/2.2.5

[kaputnikGo]

I just performed a quick test on two devices running lineageOS with passive jamming and both are reporting 0 CPU use and a steady memory footprint, which confirms what the app itself is doing. However it may be that the device hardware is still making a hardware buffer read and/or memcpy which may be why theres some cpu use and battery drain on your phone. Which model phone and which lineageOS version are you using?

Thanks for your reply and for the link to the latest ver 2 build. I will use that until this is resolved.

The device I'm having the issue with is the Moto Surnia. It's running LineageOS 14.1 for Surnia. (I'm using the latest build, but I upgrade quite often and this has been happening for quite a while)

[kaputnikGo]

I will be building a newer version (3.0.4) which will have an options switch in the About menu dialog. this will turn off the bufferRead in the hope that this is the culprit causing CPU cycles at the hardware level.
As you are OK with installing builds from this repo i will make this new version available here in a day or so for testing if you would be interested in installing it and seeing how it works for you.

The preference for me at the moment is to keep the background services running as it is the preferred method for android and it seems to stand up against a lot of the "Application Manager" type apps that run on the many variations of roms and builds etc and force quit any app that runs over a period of time.

Sounds good. I'll be happy to test the new build when it is available.

[kaputnikGo]

Hi, I have updated the app now to version 3.1.0 and made the release available here on the releases page. In some days or maybe week FDroid will automatically pick up this new release and then build it themselves for release on the fdroid repo. So remember that the build signatures will differ between my builds (here on github) and theirs on the store.

The main thing is a change in the way the passive jammer works as discussed above.This new method runs by default so you wouldn't need to change any settings after install. There is, however, an option switch in the About menu dialog that can enable/disable the old method of running (known as "buffer read lock").

Hopefully this results in an improved battery performance for you. But there is still a number of things that can cause battery use that may be beyond what I am able to fix within a user installed app.

Below is the image of the About dialog.

Thank you. I will download the new release now and let you know if it solves the issue.

[kaputnikGo]

Test device with defaults for LineageOS battery management shows the PilferShush Jammer app running the 3.1.0 release passive jammer with phone in sleep has similar power drain as the underlying OS. So hopefully this is what your phone should demonstrate. Bear in mind that this test device has no sim and was not connected to internet via WiFi during this test.
image below of battery usage window:

Mine shows as 1% (same as version 2.xx) so it looks like this solved the issue.

I wanted to give it a day of normal usage so I could report back accurately.

Thanks again for your help and the amazing work you've done with this app.

[kaputnikGo]

Excellent, thats good news! :)

Just wanted to let you know that I've been having the same issue with battery usage on 3.1.1. I just downgraded to 3.1.0.

[kaputnikGo]

Do you have the battery stats for what you are seeing? you don't have to screenshot the battery use window if you don't want to - I am mainly interested in comparing the percentages of PilferShush Jammer (when running passive), LineageOS, Phone idle and AndroidOS as can be seen in the image above.

Phone idle always has the same battery usage as PilferShush when using a version that has the battery usage issues. (It's something I noticed quite a while back when this first started happening, sorry I forgot to mention it) When using a non-battery-draining version of PilferShush, both Phone Idle and PilferShush have no noticeable battery usage.

I would provide a screenshot, but it wouldn't be accurate since when I downgraded the app, it removed it from the battery report.

[kaputnikGo]

The Phone Idle stat should reflect how much background work the phone is doing when its not being actively used and the screen is off. How a given device and ROM build behave when a phone is in idle is variable. But I would expect PilferShush with a foreground (background) service to have a similar battery use as Phone Idle.

The 2.x version of PilferShush never ran as a service and hence would not do any background work therefore no Phone Idle battery use. This meant that the app ran as a foreground app and as soon as the user either minimised the app (return to homescreen), opened a different app or just let the screen turn off then PilferShush would more than likely be "closed" by either the OS or any management apps that govern battery/CPU use. This would mean that any jamming would stop. To overcome this, as per Android dev recommendation docs, the jammers were moved to a foreground service.

Even though PilferShush is using no cpu as it is doing no "work", it still drains battery as it is running a background service to ensure that the OS keeps it running. But i would recommend using the latest PilferShush version so you can be reasonably sure it is running when you want it to run and only run it when you think you may need it.

To help determine this need the PilferShush app has a "User apps Summary" function that prints some relevant info about user apps on the device sorted as -

RECORD: has record audio permission
BOOT: has automatically start app at boot permission
SERVICES: has some background/foreground services
RECEIVERS: can listen for system and/or app broadcasts
NUHF SDK: contains the package signature of known NUHF/ACR tracker sdks

Having a "true" in these 5 categories would be a warning that an app has a known tracker SDK, that runs a background service (such as to periodically access the microphone) , runs a broadcast receiver to listen to key events (such as phone on, have detected audio at microphone), has boot permission to ensure that app is always running and, finally, has permission to record audio.

Ultimately this all gets to the fundamental conceptual problem of running an app (PilferShush) to turn off certain capabilities of a device designed to allow the types of functions (audio recording) that are run in such a way (without user awareness) for the purpose of tracking (via inaudible audio signals) that prompt a person to install the (PilferShush) app in the first place.