kaputnikGo / PilferShushJammer

Light Android AOSP application to test microphone jamming techniques to combat Cross-Device Tracking (XDT)
219 stars 25 forks source link

Question about "audioRecord buffer read lock" #52

Open LalOpen opened 1 year ago

LalOpen commented 1 year ago

Hello! I do not understand the option for the Passive Jammer Settings "Enable audioRecord buffer read lock (more CPU) I understand it would use more resources, but what does that option allow ? Should I enable it if I want to be sure microphone jamming is active ?

Thank you for your answer !

kaputnikGo commented 1 year ago

in the code: https://github.com/kaputnikGo/PilferShushJammer/blob/9c751c646a030170bdd67145b85ce9e78cf03f85/app/src/main/java/cityfreqs/com/pilfershushjammer/jammers/PassiveJammer.java#L142C25-L142C102

// returns either 0, number of shorts read, or an error code - not audio data int audioStatus = audioRecord.read(buffer, 0, audioBundle.getInt(AudioSettings.AUDIO_BUNDLE_KEYS[4]));

which means here that audioRecord.read accesses the audio buffer at the hardware level and returns a status integer (not the actual audio) as to its success. This read is part of a continuous jamming loop so it would use slightly more CPU and battery which is why its optional. Whether it provides any more blocking would be down to the specific phone, its version of the OS and any other system apps etc. Sadly you would need to test it yourself as there are too many variables.

The Pilfershush Jammer app works on the principle that only a single user app can access the microphone at any one time which (based on the AOSP source code) should mean that Pilfershush running the passive jammer should be able to lock out any other app from accessing the microphone. The audioRecord buffer read function is there to provide a better chance at success.

It should be noted that the Android OS itself (from 10 upwards), assorted system apps (voice assistants etc) and other more aggressive user apps (spyware) have all been trying to get around this. So, again, you would need to test it yourself. Personally i don't think the audioRecord buffer read uses too much CPU or battery, especially when compared to so many other user apps that are constantly opening connections to the internet etc.