Why is Android Studio's Emulator always listening to my microphone? | Hacker News Reader

Why is Android Studio's Emulator always listening to my microphone?

stackoverflow.com

79 pointsZenbit_UX25 comments

Doesn't the Android emulator run in QEMU? And doesn't qemu actually emulate a Soundcard? So it makes sense that when the emulator starts and boots the kernel in the VM it will probe the devices and act as an audio in&out pass thru, like the virtual SD card, or like the network connection or everything else really...

Coding a special SDK image to adapt to the host system permissions doesnt make any sense. Android will always have access to hardware, and you're testing that it will work on Android, not on an emulator...

It wouldn't be an accurate Android emulator without that feature.

I wonder if AI would detect this as sarcasm or not.

I wonder if this is how an AI would respond when it meets an exception

glares

It just enables the microphone at emulated device instantiation time. Easier than enabling/and disabling it at runtime.

https://android.googlesource.com/platform/external/qemu/+/a7...

Why is a 1 year old stack overflow question (with no answers) being reposted to HN?

(Also, I cannot replicate this by the way)

I thought HN audience was smart and not manipulated by inflammatory headlines.

Isn't the emulator emulating devices having a microphone like phones and such? It seems rational for it to plumb the host's microphone into the emulated one, so such features may be tested etc.

It keeps the microphone actively listening even if no apps are using it / have requested access.

This isn't something that any other app needing microphone does.

Case in point: if you use Chrome, and start a Google Hangouts calls, the website will request mic access. Only then will it activate the mic, and it will deactivate after the call.

Android Studio does or the emulator does?

If Android Studio does then I'd be more up in arms. For the emulator to do that, I'd assume it's just a matter of laziness on the part of the developers. The emulator probably just opens the audio junk at startup and doesn't bother with the rigamarole of opening and closing it as needed - it's a device emulator intended for development use, they probably don't expect it to be running constantly unattended on a developers workstation.

File a bug upstream, if it's closed with EWONTFIX, then break out the tinfoil hats and shout from the hill tops.

The Android Studio Emulator emulates a full x86 system running Android, from the kernel up. There isn't a way to only listen if an app needs it, because the emulator doesn't work at that level.

What the emulator could do would be to add an "Emulate microphone" checkbox, but that probably isn't high on Google's priority list.

It would be rational if you used an app that required the microphone, or if you allowed it permissions. By your logic it also seems rational if an android phone used it's microphone 100% of the time just in case you need to make a phone call.

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.

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.

The same happens with the iOS Simulator. I noticed when developing an app (that doesn't need any microphone permissions itself), my noise cancelling headphones would stop the noise cancelling feature, like it happens when calling someone and using the microphone. Resetting the permissions and denying “fixed” the issue for me.

Can't understand why the Simulator needs it.

Welcome to modern computing.

>I received a pop up in which Android Studio requests permission to access my microphone.

Uh? What OS shows that? Perhaps a newer Mac OS?

Since Micro Snitch is referenced in one of the comments, yes.

https://www.obdev.at/products/microsnitch/index.html

Yes, OSX 10.14.5 but I've seen this issue on 10.12 and believe it's likely all versions.

There is a certain sense of poetic justice that developers of Android applications be subjected to invasive spyware, since that describes the vast majority of applications those developers create.

At this point I avoid all apps that aren't from F-Droid. Both Google and Amazon's android app stores are packed to the gills with software that wants to spy on me and advertise to me.

This seems rather off topic and unproductive to the effort of solving the SO ticket. I highly doubt it's a matter of Google spying on developers, more likely a bug or weird interaction with the OS.

> "unproductive to the effort of solving the SO ticket."

That's an odd thing to object to. I have no interest in resolving the SO ticket. Google doesn't pay me to fix their problems and nor am I inclined to donate my labor to a for-profit corporation.

Reply on news.ycombinator.com