High Battery Usage HTC U12+
Opened this issue · 3 comments
Hi, I really like the concept of this app. I don't trust my phone, nor do I trust a lot of apps! I want to use this app but I can't because of the excessive battery usage with your claim of 0% processor usage. If you could advise on app settings (if any) or provide an update to resolve this I'd be very appreciative.
As mentioned my device is an HTC U12+ which runs Android v9.0
hi there, yes reports of high battery use are a concern. The problem lies in tracing where it is coming from, or what is causing it. For this explanation you can check the source here:
https://github.com/kaputnikGo/PilferShushJammer/blob/master/app/src/main/java/cityfreqs/com/pilfershushjammer/jammers/PassiveJammer.java
With the passive jammer running in default mode (ie with no changed settings, just as it is at first install) the two java Android functions that are called are:
audioRecord.startRecording();
and
placeboRecorder.prepare();
The first one, audioRecord.starRecording(), despite its name, doesn't actually record anything. Recording only occurs with the function audioRecord.read(void* buffer, size_t userSize) - which is never called by this app. What it does is tell the lower levels of the software (android OS, hardware firmware etc) to prepare the microphone in readiness for eventually copying the audio data to an internal buffer during the read() function:
if (native_start(MediaSyncEvent.SYNC_EVENT_NONE, 0) == SUCCESS)
status_t start(int [AudioSystem::sync_event_t] event, int triggerSession)
This process would use some battery power beyond the control of the PilferShush app because it is providing an analog to digital conversion (ADC) of audio, but with the type of microphone I would imagine that would be very low if not negligible. It should be less than the power used to make a phone call over 3/4g where essentially the only power drain is the mic, the speaker, some DSP processing and the radio. But this particular process is required for PilferShush to effectively gain and maintain access to the microphone and to therefore jam/block other apps from accessing it.
The placeboRecorder.prepare() method is named from the MediaRecorder object and is necessary for the Jammer to work in the background with phones running Android 28 and up. The prepare() function only checks that a nominated file is named and accessible for the MediaRecorder to write audio data to. That file is created as an empty file called "PilferShushPlacebo.raw" but is never written to. Recording audio only occurs here with placeboRecorder.start() function which is never called by this app. This process in and of itself doesn't access the microphone yet, only the AudioRecord method above does that, so its not adding any processing or battery drain.
This is my first guess at the start point for battery drain, the microphone hardware running ADC to its internal buffer and how efficiently that code is performing.
When the passive jammer is running it runs via a service which has to be maintained in a running state by Android. Its allowed to run in the background while other apps are running and also when the screen is off and the phone is in an idle state. What happens here depends on the version of android, any carrier, retailer add-ons or any changes made to the basic underlying android os by whoever sells or makes the phone handset. An example from a while ago was someone's phone had an "App Manager" app installed by the handset manufacturer which force killed any long running apps regardless of whether they were behaving as per the android developer guidelines (which i try to do). There are also "Battery Manager" apps that do this too.
So this is probably my second guess as to a source of battery drain for you - a running background service and its effect on the OS as a whole.
Another source of battery use may be a conflict being caused by other record audio apps constantly trying to access the microphone. On one tainted dev device i use the google voice search app is constantly trying to gain access to the mic when the jammer is running. i don't know level of battery drain this causes and how much of the system is staying awake trying to process the repeatedly denied requests. Another tainted dev phone i have is so badly made it is basically just constantly spewing out error messages directly after boot even when nothing is happening with the phone - this is active cpu use, just from sitting idle.
For a reference, here is a screenshot taken of the CPU profiler running in Android Studio that is observing the app running the passive jammer in the background on a LineageOS android 10 phone with minimal google apps installed (including voice search). It profiles the app's actual cpu use which in the image covers 55 mins and shows 0% CPU, 36.4 MB, network N/A, energy none:
On the Settings and Battery Usage section of android a running passive jammer typically shows the level of battery use that should be similar to the System use:
This part of the settings even offer an (estimated) assessment of power drain (degree of accuracy is unknown), here showing after over 3 hours of use has only drawn 12mAh (note CPU use is only 3 mins which is the time it was being used to set the passive and then go to background with phone screen off):
At this stage I have no way of knowing why you are seeing a high battery drain, other than have you run the phone with an adb debugger attached and you can see all the system messages and copy paste some here (checking and redacting any potential identifying phrases or names etc). At least you can compare your phone use to the various elements here in this answer and see where a possible cause may be.
If you can, and are able, to provide more info then I am more than happy to help try figure this out.
Update: am going to release 4.5.2 soon that has some bugfixes in it and one of them may see a reduction in system process use due to a Process_VoIP call made by AudioALSA/AudioSPELayer on the zero data audio buffer when passive jammer is running. This is caused by audio source VOICE_COMM being used to attempt to prioritise background passive jamming over other audio apps that may try gain access to the microphone.
Update: am going to release 4.5.2 soon that has some bugfixes in it and one of them may see a reduction in system process use due to a Process_VoIP call made by AudioALSA/AudioSPELayer on the zero data audio buffer when passive jammer is running. This is caused by audio source VOICE_COMM being used to attempt to prioritise background passive jamming over other audio apps that may try gain access to the microphone.
Awesome, thanks for letting me know I'll keep an eye out for the update and will test to see if it makes a positive difference. I'm on 4.5.0 ATM and will certainly install the 4.5.2 update.