3 ms·

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

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.

kllrnohj 7y ago
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.
- altShiftDev 7y ago
  > 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.
  - kllrnohj 7y ago
    > 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.
newnewpdro 7y ago
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.
jayd16 7y ago
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.

kllrnohj 7y ago

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.

altShiftDev 7y ago
> 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.
- kllrnohj 7y ago
  > 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.

newnewpdro 7y ago

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.

jayd16 7y ago

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.