IssueTracker

Could you attach a video of this happening ?

I'll try to get more details, but wanted to bring it up at least.

Please specify your OS, CPU, GPU, the emulator version, the system image you use and how your start the emulator (standalone or embedded into AS).

Hi okynk91, thank you for screen recording, we will investigate. I see you run the emulator in the AS window. Could you please try running it in its own window (see the attached screenshot)?

I see only canary reports above. For me, this also happens in stable; Giraffe patch 4. Started after updating to latest emulator and it happens every 20-30 minutes or so. Restarting the emulator fixes it for a while. Will try running in its own window.

Android Studio Giraffe | 2022.3.1 Patch 4
Build #AI-223.8836.35.2231.11090377, built on November 13, 2023
Runtime version: 17.0.6+0-b2043.56-10027231 amd64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
Windows 11 10.0
GC: G1 Young Generation, G1 Old Generation
Memory: 12288M
Cores: 12
Registry:
    ide.experimental.ui.inter.font=true
    external.system.auto.import.disabled=true
    debugger.new.tool.window.layout=true
    ide.text.editor.with.preview.show.floating.toolbar=false
    ide.instant.shutdown=false
    ide.experimental.ui=true

Non-Bundled Plugins:
    detekt (2.2.0)
    manjaro.mpb (1.8)
    com.intellij.lang.jsgraphql (4.0.1-222)
    com.navigatetomodule (0.32)
    com.developerphil.adbidea (1.6.12)

I'm having the same issue - everything works fine when the emulator is in it's own window. It seems that when in tool window, it just does not refresh the screen content - the system and apps work fine and when I use layout inspector on frozen emulator I can see the UI in real time when it's being inspected. The emulator also respons to touch events and other types of events normally, it just does not update UI.

Android Studio Iguana | 2023.2.1 Canary 15
Build #AI-232.10227.8.2321.11145877, built on November 27, 2023
Runtime version: 17.0.9+0-17.0.9b1000.46-11084592 aarch64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
macOS 14.1.1
GC: G1 Young Generation, G1 Old Generation
Memory: 8192M
Cores: 12
Metal Rendering is ON
Registry:
    ide.experimental.ui=true

Non-Bundled Plugins:
    com.github.mokkapps.codesnapintellijextension (1.0.4)
    com.developerphil.adbidea (1.6.11)
    com.github.dinbtechit.vscodetheme (1.10.7)
    mobi.hsz.idea.gitignore (4.5.2)

Hi folks, if UI freezes for you could you please put your emulator version here? You can find it in emulator's extended panel, Help > About. It should look like 34.1.12-11146273.

Mine is 34.1.11-11086671, freezing when docked inside Studio. I've been using it in a separate window since this issue and it hasn't frozen again. ("Frozen" as mentioned above: not updating until you manually switch between panels, then 1 new frame is shown).

Looks like our gRPC endpoint is not responding to new screenshot events from the renderer, causing studio not to update it's ui. It doesn't appear to be happening on TOT (in canary).

To be clear there are 2 possible causes we can investigate further:

• The emulator is producing frames, but Android Studio is not picking them up and displaying them.
• The emulator gRPC engine is not receiving frame events from the graphics engine, and therefor not producing frames.

Given that users report that the issue arose with a new emulator version, independently of studio, we should start with #2.

Ok, might have a local repro:

<--snip-->
13:40:09.646634 140674645149376 DEBUG   MultiDisplay.cpp:239               | getMultiDisplay 0 x 0 y 0 w 1080 h 2220 dpi 0 flag 0 enable 1
13:40:09.653825 140674645149376 DEBUG   MultiDisplay.cpp:239               | getMultiDisplay 0 x 0 y 0 w 1080 h 2220 dpi 0 flag 0 enable 1
13:40:09.653869 140674645149376 DEBUG   EmulatorService.cpp:1034           | Screenshot 612x1258 (xAxis: -4.7500019073486328), pixels: 2309688 in 7197 us.
13:40:09.653900 140674636756672 DEBUG   MultiDisplay.cpp:239               | getMultiDisplay 0 x 0 y 0 w 1080 h 2220 dpi 0 flag 0 enable 1
13:40:09.653979 140674636756672 DEBUG   EmulatorService.cpp:1009           | Allocation of string object. 0 < 2302248
13:40:09.654023 140675121952448 DEBUG   MultiDisplay.cpp:239               | getMultiDisplay 0 x 0 y 0 w 1080 h 2220 dpi 0 flag 0 enable 1
13:40:09.670349 140674636756672 DEBUG   MultiDisplay.cpp:239               | getMultiDisplay 0 x 0 y 0 w 1080 h 2220 dpi 0 flag 0 enable 1
13:40:09.670385 140674636756672 DEBUG   EmulatorService.cpp:1034           | Screenshot 611x1256 (xAxis: -4.7500019073486328), pixels: 2302248 in 12423 us.
13:40:09.670465 140675121952448 DEBUG   MultiDisplay.cpp:239               | getMultiDisplay 0 x 0 y 0 w 1080 h 2220 dpi 0 flag 0 enable 1
13:41:37.682536 140674628363968 DEBUG   MultiDisplay.cpp:239               | getMultiDisplay 0 x 0 y 0 w 1080 h 2220 dpi 0 flag 0 enable 1 (4585x)
13:41:37.682596 140674628363968 DEBUG   LoggingInterceptor.cpp:84          | from: , start: 1701898897682243, rcvTime: 75, sndTime: 150, rcv: 24, snd: 24, rcv_cnt: 1, snd_cnt: 1, OK , /android.emulation.control.EmulatorController/getVmState() -> [state: RUNNING]
13:41:37.685011 140675121952448 DEBUG   MultiDisplay.cpp:239               | getMultiDisplay 0 x 0 y 0 w 1080 h 2220 dpi 0 flag 0 enable 1

No new frames are being produced.. Let's see if we can attach a debugger.

Surprise #1: Multiple threads are waiting to register itself with the graphics engine..

thread #130, name = 'grpcpp_sync_ser'
android::base::ConditionVariable::wait(this=0x000055b207cae5d0, userLock=0x000055b207cae578) at ConditionVariable.h:146:9
    frame #5: 0x00007ff253c0157b libandroid-emu-metrics.so`android::base::MessageChannelBase::beforeWrite(this=0x000055b207cae558) at MessageChannel.cpp:52:19
    frame #6: 0x000055b206d2e683 qemu-system-x86_64`android::base::CallbackRegistry::registerCallback(void (*)(void*), void*) [inlined] android::base::MessageChannel<android::base::CallbackRegistry::ForwarderMessage, 64ul>::send(this=<unavailable>, msg=<unavailable>) at MessageChannel.h:122:28
    frame #7: 0x000055b206d2e67e qemu-system-x86_64`android::base::CallbackRegistry::registerCallback(this=<unavailable>, messageAvailable=<unavailable>, opaque=<unavailable>) at CallbackRegistry.cpp:53:15
    frame #8: 0x000055b206e9734b qemu-system-x86_64`android::emulation::control::EmulatorControllerImpl::streamScreenshot(grpc::ServerContext*, android::emulation::control::ImageFormat const*, grpc::ServerWriter<android::emulation::control::Image>*) [inlined] std::__1::__unique_if<android::emulation::control::EventWaiter>::__unique_single std::__1::make_unique[abi:v170000]<android::emulation::control::EventWaiter, void (*)(void (*)(void*), void*), void (*)(void*)>(__args=<unavailable>, __args=<unavailable>) at unique_ptr.h:686:30
    frame #9: 0x000055b206e97326 qemu-system-x86_64`android::emulation::control::EmulatorControllerImpl::streamScreenshot(this=0x000055b20d9e2000, context=0x000055b236aeec10, request=0x000055b239a84870, writer=0x00007ff166c1bd88) at EmulatorService.cpp:717:23
thread #131, name = 'grpcpp_sync_ser'
    frame #0: 0x00007ff251ca3156 libc.so.6`__futex_abstimed_wait_common at futex-internal.c:57:12
    frame #1: 0x00007ff251ca3118 libc.so.6`__futex_abstimed_wait_common(futex_word=0x000055b207cae5f8, expected=0, clockid=<unavailable>, abstime=0x0000000000000000, private=<unavailable>, cancel=<unavailable>) at futex-internal.c:87:9
    frame #2: 0x00007ff251ca5818 libc.so.6`___pthread_cond_wait at pthread_cond_wait.c:503:10
    frame #3: 0x00007ff251ca5740 libc.so.6`___pthread_cond_wait(cond=0x000055b207cae5d0, mutex=0x000055b207cae578) at pthread_cond_wait.c:618:10
    frame #4: 0x00007ff253c0158b libandroid-emu-metrics.so`android::base::MessageChannelBase::beforeWrite() [inlined] android::base::ConditionVariable::wait(this=0x000055b207cae5d0, userLock=0x000055b207cae578) at ConditionVariable.h:146:9
    frame #5: 0x00007ff253c0157b libandroid-emu-metrics.so`android::base::MessageChannelBase::beforeWrite(this=0x000055b207cae558) at MessageChannel.cpp:52:19
    frame #6: 0x000055b206d2e683 qemu-system-x86_64`android::base::CallbackRegistry::registerCallback(void (*)(void*), void*) [inlined] android::base::MessageChannel<android::base::CallbackRegistry::ForwarderMessage, 64ul>::send(this=<unavailable>, msg=<unavailable>) at MessageChannel.h:122:28
    frame #7: 0x000055b206d2e67e qemu-system-x86_64`android::base::CallbackRegistry::registerCallback(this=<unavailable>, messageAvailable=<unavailable>, opaque=<unavailable>) at CallbackRegistry.cpp:53:15
    frame #8: 0x000055b206e9734b qemu-system-x86_64`android::emulation::control::EmulatorControllerImpl::streamScreenshot(grpc::ServerContext*, android::emulation::control::ImageFormat const*, grpc::ServerWriter<android::emulation::control::Image>*) [inlined] std::__1::__unique_if<android::emulation::control::EventWaiter>::__unique_single std::__1::make_unique[abi:v170000]<android::emulation::control::EventWaiter, void (*)(void (*)(void*), void*), void (*)(void*)>(__args=<unavailable>, __args=<unavailable>) at unique_ptr.h:686:30
    frame #9: 0x000055b206e97326 qemu-system-x86_64`android::emulation::control::EmulatorControllerImpl::streamScreenshot(this=0x000055b20d9e2000, context=0x000055b236af2e10, request=0x000055b20c672870, writer=0x00007ff16d04fd88) at EmulatorService.cpp:717:23
   thread #132, name = 'grpcpp_sync_ser'
    frame #0: 0x00007ff251ca3156 libc.so.6`__futex_abstimed_wait_common at futex-internal.c:57:12
    frame #1: 0x00007ff251ca3118 libc.so.6`__futex_abstimed_wait_common(futex_word=0x000055b207cae5f8, expected=0, clockid=<unavailable>, abstime=0x0000000000000000, private=<unavailable>, cancel=<unavailable>) at futex-internal.c:87:9
    frame #2: 0x00007ff251ca5818 libc.so.6`___pthread_cond_wait at pthread_cond_wait.c:503:10
    frame #3: 0x00007ff251ca5740 libc.so.6`___pthread_cond_wait(cond=0x000055b207cae5d0, mutex=0x000055b207cae578) at pthread_cond_wait.c:618:10
    frame #4: 0x00007ff253c0158b libandroid-emu-metrics.so`android::base::MessageChannelBase::beforeWrite() [inlined] android::base::ConditionVariable::wait(this=0x000055b207cae5d0, userLock=0x000055b207cae578) at ConditionVariable.h:146:9
    frame #5: 0x00007ff253c0157b libandroid-emu-metrics.so`android::base::MessageChannelBase::beforeWrite(this=0x000055b207cae558) at MessageChannel.cpp:52:19
    frame #6: 0x000055b206d2e683 qemu-system-x86_64`android::base::CallbackRegistry::registerCallback(void (*)(void*), void*) [inlined] android::base::MessageChannel<android::base::CallbackRegistry::ForwarderMessage, 64ul>::send(this=<unavailable>, msg=<unavailable>) at MessageChannel.h:122:28
    frame #7: 0x000055b206d2e67e qemu-system-x86_64`android::base::CallbackRegistry::registerCallback(this=<unavailable>, messageAvailable=<unavailable>, opaque=<unavailable>) at CallbackRegistry.cpp:53:15
    frame #8: 0x000055b206e9734b qemu-system-x86_64`android::emulation::control::EmulatorControllerImpl::streamScreenshot(grpc::ServerContext*, android::emulation::control::ImageFormat const*, grpc::ServerWriter<android::emulation::control::Image>*) [inlined] std::__1::__unique_if<android::emulation::control::EventWaiter>::__unique_single std::__1::make_unique[abi:v170000]<android::emulation::control::EventWaiter, void (*)(void (*)(void*), void*), void (*)(void*)>(__args=<unavailable>, __args=<unavailable>) at unique_ptr.h:686:30
    frame #9: 0x000055b206e97326 qemu-system-x86_64`android::emulation::control::EmulatorControllerImpl::streamScreenshot(this=0x000055b20d9e2000, context=0x000055b236aec810, request=0x000055b2399e8870, writer=0x00007ff1813fbd88) at EmulatorService.cpp:717:23
 

Just wanted to add I've been experiencing this as well on an M1 Mac. For me running the app in release mode works fine. If you build and run in Debug and have the debugger attached, then the frames are not updating.

However this only happens in Canary:

Android Studio Iguana | 2023.2.1 Canary 17
Build #AI-232.10227.8.2321.11191411, built on December 7, 2023
Runtime version: 17.0.9+0-17.0.9b1087.7-11185874 aarch64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
macOS 14.2
GC: G1 Young Generation, G1 Old Generation
Memory: 3072M
Cores: 10
Metal Rendering is ON
Registry:
    debugger.new.tool.window.layout=true
    ide.instant.shutdown=false
    ide.experimental.ui=true

If I run the same exact emulator version 34.1.13-11169323, in current Stable:

Android Studio Hedgehog | 2023.1.1
Build #AI-231.9392.1.2311.11076708, built on November 9, 2023
Runtime version: 17.0.7+0-17.0.7b1000.6-10550314 aarch64
VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o.
macOS 14.2
GC: G1 Young Generation, G1 Old Generation
Memory: 3072M
Cores: 10
Metal Rendering is ON
Registry:
    external.system.auto.import.disabled=true
    debugger.new.tool.window.layout=true
    ide.text.editor.with.preview.show.floating.toolbar=false
    ide.instant.shutdown=false
    ide.experimental.ui=true

It does not have this issue.

Worth noting that the pop-out mode doesn't affect this.

Fix is in with https://android-review.git.corp.google.com/c/platform/external/qemu/+/2863491

https://android-review.git.corp.google.com/c/platform/external/qemu/+/2874534

what version of emulator should this be in?

Still seeing this issue with 34.1.15-11228956 in AS Hedgehog 2023.1.1 patch 1

FWIW Not seeing this issue anymore in latest canaries/beta.

I'm having this issue still.

Android Studio Iguana | 2023.2.1 Build #AI-232.10227.8.2321.11479570, built on February 22, 2024 Runtime version: 17.0.9+0--11185874 amd64 VM: OpenJDK 64-Bit Server VM by JetBrains s.r.o. Windows 11.0

Android emulator version 34.1.18.0

This should be fixed in 34.1.19, please update and let us know.

Note

From now till end of Feb 2024, we are migrating to using a separate task item to track postmortem status, instead of using the original fixed bug. You may run into unexpected issues as we iron out the wrinkles in the automated workflow. Any questions or feedback, please email: android-hygiene-autobug-filer@.

Thank you for your patience and support.

Unfortunately, I don't have an update as it works for me (somewhat slow, yes).

Hi

In case anybody is still experimenting a crash with https://ci.android.com/builds/submitted/10914596/emulator-mac_aarch64_gfxstream/latest/sdk-repo-darwin_aarch64-emulator-10914596.zip , please consider running just after the crash the command

• crashreport -l to see if a local crash has been created
• crashreport -u to upload the crash (if any). It will give a crash report-id, and please enter the crashid as a comment of this bug. It will help us if you can also say what you were doing during the crash, and if you were using a specific webcam

crashreport being part of the zipfile sdk-repo-darwin_aarch64-emulator-10914596.zip

We were able to reproduce the crashes on different MacOS running Sonoma before the fix in 10914596, but since the fix, the emulator is not crashing anymore in our tests on Sonoma.

Thanks

You want to download the file (sdk-repo-darwin_aarch64-emulator-10914596.zip) and

xattr -d com.apple.quarantine sdk-repo-darwin_aarch64-emulator-10914596.zip

then unzip it.

So how do I open it?

Start it from the console, e.g. ANDROID_SDK_ROOT=/Users/rforzani22/Library/Android/sdk ./emulator -avd YOUR_AVD -wipe-data -no-snapshot -camera-back webcam0

Hi skergx, thank you for the feedback. What CPU do you run on?

We are working on a better patch (the performance should be about as before and should also work on non-Max CPUs as we see here), the build should be available today-tomorrow.

I shared my local build with our next patch to fix this issue.

This is our second version:

https://ci.android.com/builds/submitted/10937044/emulator-mac_aarch64_gfxstream/latest/sdk-repo-darwin_aarch64-emulator-10937044.zip

Hi clerici.m89, thank you for the update. Could you please try (our first fix):

https://ci.android.com/builds/submitted/10914596/emulator-mac_aarch64_gfxstream/latest/sdk-repo-darwin_aarch64-emulator-10914596.zip

Hi Andi, the Android Emulator is released independently from the Android Studio. The 32.x.x version is EOL, 33.x.x will be promoted to stable soon and the webcam fixes will be available there.

also the image has different size as before, at least with obs before sonoma i was seeing a cropped image out of the 1280x720 but now i can see it full size on the emulator screen.

In the first fix there is no scale function, I crop and put black everywhere I have no pixels for. When we have the scale function, we crop a smaller image and resize to fill all requested pixels.

Hi Andi, thank you for reporting this. I think this is a different problem here as 10914596 does not change anything related to opening the device and 10937044 probably missed even more around this case.

I am marking this as "fixed" for our internal release process. We are still looking into it. The changes should be available in 34.1.7 (canary) and 33.1.21 (stable).

The Emulator is release independently from the Android Studio. This fix is available in the Emulator 34.1.11 which is shipped with the Android Studio Iguana (2023.2.1 Canary 14).

If the Emulator is released independently, I would expect that it would also be updated in SDK Manager for prior versions of Android Studio, no?

We ship the emulator through several channels (stable, canary, beta), if you are on the stable channel, you will get the emulator updates later. Consider getting https://developer.android.com/studio/preview for faster updates.

The fix does work with the actual webcam but it BREAKS the virtual webcam. Here's the error message:

ERROR   | -[MacCamera captureOutput:didOutputSampleBuffer:fromConnection:]: error in allocate rotateInputBuffer_: -21602
ERROR   | -[MacCamera captureOutput:didOutputSampleBuffer:fromConnection:]: error in allocate rotateInputBuffer_: -21602
 (127x)
ERROR   | _camera_client_query_frame: Unable to obtain first video frame from the camera '7626645E-4425-469E-9D8B-97E0FA59AC75' in 2001 milliseconds: Undefined error: 0.

Please help take a look

Also got the same error as above comment. The 34.1.11 breaks emulator with virtual cam on Sonoma.

error in allocate rotateInputBuffer_: -21602

This one is fixed in https://ci.android.com/builds/submitted/11125189/emulator-mac_aarch64_gfxstream/latest/sdk-repo-darwin_aarch64-emulator-11125189.zip

This one is fixed in https://ci.android.com/builds/submitted/11125189/emulator-mac_aarch64_gfxstream/latest/sdk-repo-darwin_aarch64-emulator-11125189.zip

This one works, thank you! Will this new version be released anytime soon?

This one works, thank you! Will this new version be released anytime soon?

Please try our latest stable push (33.1.23).

Hi Timar, please file a new bug with repro steps and screenshots. Please specify the Android Studio version, the Emulator version and the system image you use.

Timar, file a new bug into the Android Studio component.

You can try the latest Emulator version from https://developer.android.com/studio/emulator_archive

If the performance is still bad, you could try fixing this yourself and send us your patch. The Emulator is open source, this is what we changed: https://android.googlesource.com/platform/external/qemu/+log/refs/heads/emu-master-dev/android/android-emu/android/camera/camera-capture-mac.m

still poor performance after opening camera.

Hi industrialstrengthdatasystems, if you can build Emulator yourself, please try this patch: https://android-review.googlesource.com/c/platform/external/qemu/+/3093185

luunguyen0811, this is tracked in https://issuetracker.google.com/issues/325814592

Hi folks, please try this build for improved webcam (while it is open) performance:

https://ci.android.com/builds/submitted/11871170/emulator-mac_aarch64_gfxstream/latest/sdk-repo-darwin_aarch64-emulator-11871170.zip

A newer build to try:

https://ci.android.com/builds/submitted/11887261/emulator-mac_aarch64_gfxstream/latest/sdk-repo-darwin_aarch64-emulator-11887261.zip

Hi bien2k4. Unfortunately, MacOS camera experts are in short supply here :) Thank you for reporting that the issue does not repro on Ventura.

BTW, the camera performance issue is tracked here: https://issuetracker.google.com/issues/325814592