Hmm well in terms of where the bug originated, the OS probably does have constant access to the microphone. App permissions are just that. They are permissions for apps granted by the OS. The OS doesn't ask permission of itself. They could do the work in the emulator to forward the ad-hoc approval through to the host OS but they probably didn't.

Always-on hotword recognition is a normal thing phones do. Even if the emulator is only requesting mic access when an app uses it, that would still actually be "basically always" unless you are using a no-Google image. Which isn't the recommended image.

> Always-on hotword recognition is a normal thing phones do.

I wouldn't call that normal at all, nor does your theory address the issue of the permissions request being explicitly denied while still gaining access.

> I wouldn't call that normal at all

What would you call it then? It's a thing 99% of modern phones do (Android & iOS). If that's not "normal" then what is "normal" in your world?

> nor does your theory address the issue of the permissions request being explicitly denied while still gaining access

My theory was not intended to address what is obviously an OSX bug. The theory is _why_ it was asking. Why it managed to get access anyway after being denied is just a straight up permission bug in OSX and has nothing to do with Android Studio or the emulator.

No, an android phone is expected to be powered on and used constantly by random users. A device emulator bundled with a developer suite is an entirely different context. The charitable assumption here is just that laziness and deadlines prevailed, it opens it once and leaves it open, they don't expect the emulator to be run constantly, and it's expected that the code your emulator is running is what you're developing, the burden of security is quite low when it comes to developer's tools, there's a tremendous amount of implied trust.