Status Update
Comments
bo...@google.com <bo...@google.com> #2
The attached Build Scan log shows that the emulator process crashed unexpectedly. Could you rerun your task with --info
and -Pandroid.experimental.testOptions.managedDevices.emulator.showKernelLogging=true
to get more information about the emualtor process logs?
[Deleted User] <[Deleted User]> #4
No idea why the scan does not contain log information, here you are:
hs...@google.com <hs...@google.com> #5
The link in --info
and -Pandroid.experimental.testOptions.managedDevices.emulator.showKernelLogging=true
, the emulator process output its kernel logging to stdout. Do you see any stacktrace or segfault in the log?
[Deleted User] <[Deleted User]> #6
That's strange, the repo and the build is public... But I attached the logs as file
hs...@google.com <hs...@google.com> #7
I looked into the logs and it turns out, the runner didn't have enough disk space. I guess the root cause is the Gradle update causing another Gradle major version (and its new transform-4) folder to cache was too much. Anyway, a better error message of the exit code of GMD would be helpful.
yo...@intel.com <yo...@intel.com> #8
Thanks for uploading the log! Yes, the emulator kernel log says the issue was the insufficient disk space:
2024-04-02T18:31:45.7078429Z ERROR | Not enough space to create userdata partition. Available: 7177.027344 MB at /home/runner/.config/.android/avd/gradle-managed/dev34_aosp_atd_x86_64_Pixel_2.avd, need 7372.800000 MB.
Also, I agreed that GMD should diagnose errors and can provide better messages.
Let me rename this issue's title to improve the error message for disk space error.
hs...@google.com <hs...@google.com> #9
I've added a fix that will surface all error messages from the emulator in the exception when it closes unexpectedly.
pj...@google.com <pj...@google.com> #10
Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:
- Android Studio Meerkat | 2024.3.1 Canary 2
- Android Gradle Plugin 8.9.0-alpha02
We encourage you to try the latest update.
If you notice further issues or have questions, please file a new bug report.
Thank you for taking the time to submit feedback — we really appreciate it!
sa...@google.com <sa...@google.com> #11
Emulator Version:31.2.8
pj...@google.com <pj...@google.com>
sa...@gmail.com <sa...@gmail.com> #12
my all old virsine link sarvice all fil remove parmanetly
yo...@intel.com <yo...@intel.com> #13
Discussed with our developer team, HAXM relies on the QEMU super I/O initialization. From the HAXM perspective, it is not a block bug. If this issue would not block your side, maybe you can close it here. For sure thing, we will monitor and dig more when we have resource.
su...@gmail.com <su...@gmail.com> #14
pe...@gmail.com <pe...@gmail.com> #15
20 May 2022 Cum 20:43 tarihinde peripr08 <buganizer-system@google.com> şunu
yazdı:
de...@gmail.com <de...@gmail.com> #18 Restricted+
to...@gmail.com <to...@gmail.com> #19
Just filing a bug 🐛 and the details of the activity is very disturbing for the reason that I am not going to be able to get much accomplished with the obstruction and redirection of the implications of the activity of the reprogrammed Android.
Description
The CL causing the problem is the same one as Roman(rkir@) found in
I am going to revert the CL for the moment so that it won't impact emulator experience. However, I hope Intel can take a look as such "vcpu shutdown request" could be a potential bug.