Fixed
Status Update
No update yet.
Comments
il...@google.com
il...@google.com
ap...@google.com
Same issue here
ap...@google.com
Same issue here
ga...@gmail.com
+1
fo...@google.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
ap...@google.com
Same problem here
ap...@google.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
Description
When defining an explicit deep-link using NavDeepLinkBuilder, only a single Argument bundle can be provided for every Fragment destination inferred from XML. This can cause conflicts between arguments of the same name shared by different Destinations, and no argument verification is performed, so it's possible for parent Fragments to crash at navigateUp() time.
Request: A NavDeepLinkBuilder api that allows composition of explicit [destId, args] pairs to construct a destination stack. Preferably, accepting NavDirections as the parameter, so existing SafeArgs generated wrappers can be reused for argument safety.