IssueTracker

Same issue here

Same issue here

+1

Me too.

emulator: WARNING: encryption is off
Hax is enabled
Hax ram_size 0x60000000
Failed to open vm 3
Failed to create HAX VM
No accelerator found.
failed to initialize HAX: Invalid argument

Same problem here

Hi all,

Thanks for bringing this to our attention. We are working with Intel on how to fix it, and have reproduced the problem in-house as well. Currently there doesn't seem to be a simple workaround. It also looks like macOS 10.13 added new security features that block kernel extensions such as HAXM without explicit user intervention, so we will need to streamline the install part as well.

In the meantime, we've tested Hypervisor.Framework which seems to work on 10.13. Try running the emulator on Canary channel 26.1.x (API 25/26 recommended) with Hypervisor.Framework; put the text "HVF = on" in ~/.android/advancedFeatures.ini (create this file if it doesn't exist already).

Frank

(x86 32-bit images only on that for now, as well)

Worked perfect, thanks

Thanks, Frank. Life is good again!

A further investigation from google side revealed something abnormal with the device file created by Intel HAXM. It is expected that HAXM will create a device file representing VMs under "/dev/hax_vm/vmXX" where XX is VM ID. However, on high sierra, the device file created is put under "/dev/hax*/vmXX". The "*" here definitely suggests something unusual, which is not a typical file or directory name. Since there should be changes to HAXM binary so far, High Sierra should be changing something that HAXM should be adapted to.
Hope this could be a hint for Yu Ning for further investigation.

Could you please provide some step-by-step instructions on how to enable Hypervisor.Framework? Adding "HVF = on" in ~/.android/advancedFeatures.ini didn't have any effect for me, I'm still getting "failed to initialize HAX: Invalid argument"...

That's weird, can you supply the faulting AVD's config.ini?

You'll need to run it on a 32-bit x86 AVD, as we don't support running Hypervisor.Framework on 64-bit x86 AVD's currently.

Here is what I do:

1. Go to AVD Manager
2. Create a new AVD (API level 25 or 26 recommended):
    a. "Create Virtual Device" > "Next" (Nexus 5X should be selected)
    b. Image description: should be "Android 7.1.1" or "Android API 26" images in there that are not grayed out; if not, click the "Download" link and try the process again.
    c. Make sure it is a x86 (not x86_64) image.
3. Finish the AVD creation process (Default settings should work)
4. Start the AVD (hit the "play" button on the AVD manager for the AVD you just created).

Thanks, it works for me:

put the text "HVF = on" in ~/.android/advancedFeatures.ini (create this file if it doesn't exist already).

I'm from HAXM team, Yu and i have discussed this issue, and i think we have came up with a solution for it.  new HAXM will be release after fixing it.

Thanks!

That's good news, because I can't get HVF to work. It's as if the entry in advancedFeatures.ini was ignored.

~$ cat .android/advancedFeatures.ini
HVF = on

~$ Library/Android/sdk/tools/emulator -version
Android emulator version 26.1.2.0 (build_id 4077558) (CL:500db745bd44dbc6000413b5e8969d83216ff7cd)

~$ Library/Android/sdk/tools/emulator @Nexus_5X_API_26
emulator: ERROR: x86 emulation currently requires hardware acceleration!
Please ensure Intel HAXM is properly installed and usable.
CPU acceleration status: HAXM is not installed on this machine

Exactly the same output with HVF = off.

Using Android Studio 3.0 Canary 5

Ralf, you might need to first install HAXM in order to get HVF to work. That might involve 1) a trip to $ANDROID_SDK_ROOT/extras/intel and running the installer manually 2) going to Preferences > Security and allowing any recently blocked kernel extension to allow to install, and then running the HAXM installer again.

We haven't reproduced the issue due to lack of a macOS 10.13 environment, but we investigated the issue today based on information in this thread, especially #11. Our current hypothesis is that macOS 10.13 beta fixes a bug in the XNU (Darwin) kernel, which results in a behavior change in a kernel API used by HAXM for creating VM device nodes (/dev/hax_vm/vm<vm_id>). So HAXM needs to adapt to that.

Details:
1. HAXM driver calls BSD API devfs_make_node() to create /dev/hax_vm/vm<vm_id>. This API requires a path relative to /dev/, so if vm_id = 1, HAXM will pass "hax_vm*/vm01" to it.
2. Why the asterisk? I thought it was an unnecessary wildcard, but if I remove it, on macOS 10.10 (probably <= 10.12), I get /dev/hax_v/vm01 instead, i.e. the XNU implementation of devfs_make_node() "eats" the last character of every subdirectory along the path. It turns out this bug has been around for quite a while:
https://lists.apple.com/archives/darwin-kernel/2007/Dec/msg00072.html
And I believe the culprit is this line in XNU kernel:
https://github.com/opensource-apple/xnu/blob/master/bsd/miscfs/devfs/devfs_tree.c#L331
There's no 10.13 branch in that GitHub project, but my guess is Apple somehow finally decided to fix this bug.
3. We are yet to come up with an elegant solution, but as #15 suggested, we should be able to implement a hack: call the API with an extra character (e.g. '*') first, check if the resulting path contains that extra character, and if so, undo the first call and make a second call without the extra character. We'll try this solution on Monday if there's no better idea.

Thanks Yu for the detailed report. That's a pretty serious bug that would break a bunch of other kernel exts as well, hmm. The mailing list discussion seems to discourage creating things in /dev/; would there be a way to get HAXM to be in another directory and have it work across all versions then?

Also, Is it possible to also trigger the fixed name from how the emulator uses HAXM ioctls?

Maybe HAXM can borrow the way KVM works. When asked for creating a VM, KVM returned file handle directly by the creation ioctl. Right now, HAXM needs two steps. A creation ioctl and an open call to get that handle.
However, it depends on whether MacOS offers the needed APIs or not.