You could setup debugging and monitor all the traffic from the phone over a long period of time. Inspect it and confirm (or deny) your hypothesis.
This wouldn't be conclusive since it would be pretty easy to just hide these payloads in some other traffic stream to a compromised node, which is a super common way cyberthreat command and control functions. If the user never initiates a connection to the host, the payloads just wait around so as not to generate suspicious traffic.
Obviously the threat model for advertising is a bit different, but there's no reason someone trying to hide this functionality wouldn't take similar steps.
Oh sure, you could be extra careful and attempt to detect any obfuscation or encrypted payloads that weren't decrypted. Then there's the concern that the malware watches for this behaviour and you'll need to further modify the environment.
Should the notification tell you when an app uses your mic when not inside the app?
Oh wait, it can't if one bypasses the API.
They are, so, why bother?
You can't prove a negative.
I can prove by evidence that there is no milk in this cup.
That’s such a widely used concept and it’s erroneous. You can’t ALWAYS prove a negative. But if you’re able to prove a mutually exclusive positive to the negative condition, then you’ve proven it. For example, proving it is daytime where I’m standing also proves it is not nighttime where I’m standing.
There are circumstances where a negative cannot be practically proven, or without an absurd amount of work. But all you really need to do is empirically demonstrate the negative is the likeliest reasonable scenario and that’s usually good enough, except to someone obstinately trying to stay with their position and therefore demands absolute unequivocal proof - which is a rarity entirely.
You can't prove a universal negative.
You can prove specific negatives by providing counter evidence. Thing like "I am not a woman" by proving "I am a man".
That depends on how conclusive you need your proof to be.
For example, you could run your phone software in an emulator and prove that your emulated microphone isn’t being accessed except when it should, because all attempts to access hardware are provided by your emulator. You would simply detect if this happens.
You could debug the kernel on device to detect request to access the microphone hardware and correlate this data with user activities to show that it’s quite unlikely you’re being monitored.
Perhaps you could insert physical probes into a real physical device to detect whether the application processor wakes up to service that data when you are speaking. If it doesn’t wake up, then you can reasonably argue that the data must not be getting stored or processed.
In general, irrefutable proof will be difficult to acquire. As far as we know, most phones don’t listen to the microphone and record audio while the screen is locked. They have a coprocessor that does this but it wouldn’t have the memory to record more than a second or two and is used mainly for hotword detection.
Put your phone in a Faraday bag for an extended period of time, then check what kind of ads you get.
