Infeasible
Status Update
No update yet.
Comments
uc...@google.com
Same issue here
ms...@gmail.com
Same issue here
ms...@gmail.com
+1
ey...@gmail.com
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
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
ey...@gmail.com
Same problem here
ms...@gmail.com
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
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
je...@google.com
(x86 32-bit images only on that for now, as well)
je...@google.com
Thanks, Frank. Life is good again!
hu...@google.com
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.
Hope this could be a hint for Yu Ning for further investigation.
ey...@gmail.com
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"...
ms...@gmail.com
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).
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).
hu...@google.com
Thanks, it works for me:
put the text "HVF = on" in ~/.android/advancedFeatures.ini (create this file if it doesn't exist already).
put the text "HVF = on" in ~/.android/advancedFeatures.ini (create this file if it doesn't exist already).
ms...@gmail.com
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!
Thanks!
hu...@google.com
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
~$ 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
ms...@gmail.com
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.
hu...@google.com
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.
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:
And I believe the culprit is this line in XNU kernel:
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.
kl...@google.com
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?
Also, Is it possible to also trigger the fixed name from how the emulator uses HAXM ioctls?
hu...@google.com
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.
However, it depends on whether MacOS offers the needed APIs or not.
ms...@gmail.com
The above suggestion does make an API change which means QEMU needs to be modified based on HAXM version, if the suggestion is viable.
hu...@google.com
Frank, I had HAXM installed and HVM didn't work, that's why I then retried after uninstalling HAXM (and removing the kext). Now I installed HAXM again as you suggested (except that I didn't have to do any changes in Preferences > Security). HVM still doesn't work, and no matter whether HVM = on or HVM = off, I still get that "failed to initialize HAX: Invalid argument" error... No idea what I could be doing wrong, I'm editing the file via "vi ~/.android/advancedFeatures.ini" but it just doesn't make any difference what I put in there.
ey...@gmail.com
Could anyone running macOS 10.13 beta do me a favor? If you could just post the output of "uname -v", that would help a lot.
For example, on macOS 10.11:
$ uname -v
Darwin Kernel Version 15.6.0: Tue Apr 11 16:00:51 PDT 2017; root:xnu-3248.60.11.5.3~1/RELEASE_X86_64
I guess the kernel version of macOS 10.13 should begin with 17, but I just want to confirm that.
For example, on macOS 10.11:
$ uname -v
Darwin Kernel Version 15.6.0: Tue Apr 11 16:00:51 PDT 2017; root:xnu-3248.60.11.5.3~1/RELEASE_X86_64
I guess the kernel version of macOS 10.13 should begin with 17, but I just want to confirm that.
kl...@google.com
$ uname -v
Darwin Kernel Version 17.0.0: Tue Jun 13 21:06:15 PDT 2017; root:xnu-4481.0.0.1.1~1/RELEASE_X86_64
Darwin Kernel Version 17.0.0: Tue Jun 13 21:06:15 PDT 2017; root:xnu-4481.0.0.1.1~1/RELEASE_X86_64
hu...@google.com
I've been testing the 10.13 beta and the HVF workaround on a Late 2009 iMac. Turns out the CPU doesn't support HVF, I suppose that's the reason for the trouble I've been encountering:
$ sysctl kern.hv_support
kern.hv_support: 0
$ sysctl kern.hv_support
kern.hv_support: 0
ms...@gmail.com
#25: Your CPU is probably missing an Intel Virtualization Technology feature called EPT. HAXM should work without EPT, but the performance would not be great.
And thanks for the information, with which I've implemented a patch. Note that I didn't take the approach proposed in #18, because usual file APIs such as open(), close(), etc. are for use by userspace and have side effects when used on device nodes.
Instead, I came up with another hack, which is to detect the macOS (XNU kernel) version HAXM is running on, and adjust the devfs path accordingly. The assumption is that XNU kernels >= 17.0.0 do NOT require an extra character to be appended to every subdirectory name.
I'm hopeful that this will make HAXM compatible with macOS 10.13 beta. But there's no guarantee it will not break again in the future... After all, the mailing list discussion discourages creating *subdirectories* in /dev (but creating files directly under /dev should be fine). So in the long term, we should flatten the currently hierarchical devfs layout, and make corresponding changes on QEMU side.
#20: That would be neat, but I don't know if Mac provides such APIs. If we are making userspace changes anyway, we should get rid of the devfs subdirectories first.
And thanks for the information, with which I've implemented a patch. Note that I didn't take the approach proposed in #18, because usual file APIs such as open(), close(), etc. are for use by userspace and have side effects when used on device nodes.
Instead, I came up with another hack, which is to detect the macOS (XNU kernel) version HAXM is running on, and adjust the devfs path accordingly. The assumption is that XNU kernels >= 17.0.0 do NOT require an extra character to be appended to every subdirectory name.
I'm hopeful that this will make HAXM compatible with macOS 10.13 beta. But there's no guarantee it will not break again in the future... After all, the mailing list discussion discourages creating *subdirectories* in /dev (but creating files directly under /dev should be fine). So in the long term, we should flatten the currently hierarchical devfs layout, and make corresponding changes on QEMU side.
#20: That would be neat, but I don't know if Mac provides such APIs. If we are making userspace changes anyway, we should get rid of the devfs subdirectories first.
ja...@google.com
Thanks for quick update. This is an good option to me, too. Handling host OS API changes based on their version is usual practice.
jo...@gmail.com
#27: Have you tried our HAXM 6.2.0 preview release on macOS 10.13 beta? Does it work?
hu...@google.com
QA is testing the new release. He should be able to report back soon.
[Deleted User] <[Deleted User]>
I got from our QA. Booting AVD is fine now.
Description
I also tried deleting my debug.keystore, restarting AS and system(!!!) but it didn't solved.
Here is a full log from gradle:
----------------------------------------------------------------------
FAILURE: Build failed with an exception.
* What went wrong:
Execution failed for task ':chris-app:packageDemoDebug'.
> java.io.IOException: Failed to generate v1 signature
* Try:
Run with --info or --debug option to get more log output.
* Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':chris-app:packageDemoDebug'.
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:100)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:70)
at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:64)
at org.gradle.api.internal.tasks.execution.ResolveTaskOutputCachingStateExecuter.execute(ResolveTaskOutputCachingStateExecuter.java:54)
at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58)
at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:88)
at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:52)
at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52)
at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54)
at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.run(DefaultTaskGraphExecuter.java:243)
at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:197)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:107)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:236)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:225)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.processTask(DefaultTaskPlanExecutor.java:124)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.access$200(DefaultTaskPlanExecutor.java:80)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:105)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:99)
at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.execute(DefaultTaskExecutionPlan.java:625)
at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.executeWithTask(DefaultTaskExecutionPlan.java:580)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.run(DefaultTaskPlanExecutor.java:99)
at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63)
at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46)
at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55)
Caused by: org.gradle.tooling.BuildException: java.io.IOException: Failed to generate v1 signature
at com.android.build.gradle.internal.scope.OutputScope.lambda$parallelForEachOutput$10(OutputScope.java:240)
at com.android.build.gradle.internal.scope.OutputScope.parallelForEachOutput(OutputScope.java:235)
at com.android.build.gradle.internal.scope.OutputScope.parallelForEachOutput(OutputScope.java:196)
at com.android.build.gradle.internal.scope.OutputScope.parallelForEachOutput(OutputScope.java:180)
at com.android.build.gradle.tasks.PackageAndroidArtifact.doFullTaskAction(PackageAndroidArtifact.java:466)
at com.android.build.gradle.internal.tasks.IncrementalTask.taskAction(IncrementalTask.java:80)
at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:73)
at org.gradle.api.internal.project.taskfactory.DefaultTaskClassInfoStore$IncrementalTaskAction.doExecute(DefaultTaskClassInfoStore.java:168)
at org.gradle.api.internal.project.taskfactory.DefaultTaskClassInfoStore$StandardTaskAction.execute(DefaultTaskClassInfoStore.java:134)
at org.gradle.api.internal.project.taskfactory.DefaultTaskClassInfoStore$StandardTaskAction.execute(DefaultTaskClassInfoStore.java:121)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$1.run(ExecuteActionsTaskExecuter.java:122)
at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336)
at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:197)
at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:107)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:111)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:92)
... 27 more
Caused by: java.lang.RuntimeException: java.io.IOException: Failed to generate v1 signature
Caused by: java.io.IOException: Failed to generate v1 signature
at com.android.apkzlib.sign.SigningExtension.onOutputZipReadyForUpdate(SigningExtension.java:297)
at com.android.apkzlib.sign.SigningExtension.access$200(SigningExtension.java:55)
at com.android.apkzlib.sign.SigningExtension$1.lambda$beforeUpdate$2(SigningExtension.java:175)
at com.android.apkzlib.zip.ZFile.notify(ZFile.java:2099)
at com.android.apkzlib.zip.ZFile.update(ZFile.java:871)
at com.android.apkzlib.zip.ZFile.close(ZFile.java:1161)
at com.android.apkzlib.zfile.ApkZFileCreator.close(ApkZFileCreator.java:172)
at com.google.common.io.Closer.close(Closer.java:216)
at com.android.builder.internal.packaging.IncrementalPackager.close(IncrementalPackager.java:332)
at com.android.build.gradle.tasks.PackageAndroidArtifact.doTask(PackageAndroidArtifact.java:698)
at com.android.build.gradle.tasks.PackageAndroidArtifact.splitFullAction(PackageAndroidArtifact.java:520)
at com.android.build.gradle.internal.scope.OutputScope.lambda$parallelForEachOutput$6(OutputScope.java:185)
at com.android.build.gradle.internal.scope.OutputScope.lambda$parallelForEachOutput$7(OutputScope.java:202)
at com.android.build.gradle.internal.scope.OutputScope.lambda$null$8(OutputScope.java:224)
"
at com.android.apksig.internal.apk.v1.V1SchemeSigner.checkEntryNameValid(V1SchemeSigner.java:406)
at com.android.apksig.internal.apk.v1.V1SchemeSigner.generateManifestFile(V1SchemeSigner.java:373)
at com.android.apksig.internal.apk.v1.V1SchemeSigner.sign(V1SchemeSigner.java:253)
at com.android.apksig.DefaultApkSignerEngine.outputJarEntries(DefaultApkSignerEngine.java:372)
at com.android.apkzlib.sign.SigningExtension.onOutputZipReadyForUpdate(SigningExtension.java:295)
... 13 more
BUILD FAILED in 2m 49s
------------------------------------------------------------
Build: 3.0 Canary 7, AI-171.4182969, 201707142150,
AI-171.4182969, JRE 1.8.0_152-release-884-b01x64 JetBrains s.r.o, OS Mac OS X(x86_64) v10.12.6 unknown, screens 1920x1080, 1280x800; Retina
IMPORTANT: Please read