Obsolete
Status Update
No update yet.
Comments
[Deleted User] <[Deleted User]>
Hi
Might not be so much help but
I opened an issue too regarding emulator being slow (I notice my CPU usage high)
https://issuetracker.google.com/issues/109758959
I saw you use HAXM 7.2.0.
That came out recently (this month) and because I moved to a new laptop I had installed 7.2.0.
My old laptop (which was a lower spec) used 6.X.X (I cannot remember the exact version) and the emulator ran fine
I am just theory crafting however, trying to see a pattern between the issues, I do not have concrete proof of it being the new HAXM only that it is the biggest difference between my old and new laptop
Cheers
Might not be so much help but
I opened an issue too regarding emulator being slow (I notice my CPU usage high)
I saw you use HAXM 7.2.0.
That came out recently (this month) and because I moved to a new laptop I had installed 7.2.0.
My old laptop (which was a lower spec) used 6.X.X (I cannot remember the exact version) and the emulator ran fine
I am just theory crafting however, trying to see a pattern between the issues, I do not have concrete proof of it being the new HAXM only that it is the biggest difference between my old and new laptop
Cheers
lf...@google.com
#2: The user is using HVF so it is not a HAXM specific issue.
Can you make sure it is not a guest process taking lots of CPU? You can check by going into adb shell and running top.
Can you make sure it is not a guest process taking lots of CPU? You can check by going into adb shell and running top.
de...@gmail.com
I can see a couple of audio-related processes as the top consuming ones, `audioserver` (`android.hardware.audio@2.0-service`) and `audioserver` (`audioserver`).
is...@google.com
jp...@google.com
Closing this bug as obsolete in the previous description (old API, obsolete MacOS versions, old versions of the emulator).
Note that there are still some conditions where the CPU usage will be high, especially during GMS update at the first boot time, but the original conditions of this bug are now obsolete
Description
Build: 3.1.2, AI-173.4720617, 201804132127,
AI-173.4720617, JRE 1.8.0_152-release-1024-b01x64 JetBrains s.r.o, OS Mac OS X(x86_64) v10.13.4 unknown, screens 1680x1050; Retina
Android Gradle Plugin: 3.0.1
Gradle: 4.7
NDK: from local.properties: (not specified); latest from SDK: (not found);
LLDB: pinned revision 3.1 not found; latest from SDK: (package not found);
CMake: from local.properties: (not specified); latest from SDK: (not found); from PATH: (not found);
Emulator Version (Emulator--> Extended Controls--> Emulator Version): 27.2.9-477 (HVF 10.13.0)
HAXM / KVM Version: 7.2.0
Android SDK Tools: 28.0.0
Host Operating System: macOS High Sierra 10.13.4
CPU Manufacturer: Intel
Steps to Reproduce Bug:
1. Open the emulator
2. Check "Activity Monitor" for CPU usage
3. Notice that the CPU usage is extremely high (+150%) and the culprit is qemu-system-i386.exe
Expected Behavior:
The CPU should not be taken over by the emulator.
Observed Behavior:
The CPU is taken over by the emulator.
Additional notes:
See this SO question
In particular these two answers: