Fixed
Status Update
No update yet.
Comments
ra...@google.com
Same issue here
st...@baramundi.de
Same issue here
ra...@google.com
+1
ra...@google.com
ra...@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
st...@baramundi.de
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
ra...@google.com
(x86 32-bit images only on that for now, as well)
Description
Version used: 1.0.0-alpha08
Devices/Android versions reproduced on: Moto G5s Plus, Android 7.1.1 / Huawai P20 lite, Android 8.0.0
We can reproduce a crash of the workmanager on some devices.
In our code we enqueue a UniqueWork with ExistingWorkPolicy.REPLACE, as soon as it finishes with State.SUCEEDED we enqueue it again. There is always only one job at the time.
After about 100 jobs the workmanager crashes with: java.lang.IllegalStateException: Apps may not schedule more than 100 distinct jobs.
It looks like the workmanager does not prune the finished jobs fast enough, and they count as 'sheduled' job, even if they are finished?
The crash is reproducible on the Moto G5s Plus and Huawai P20 lite. But it behaves very inconsistent, sometimes it occurs on the first run, sometimes only after a few restarts of the app. But we cannot reproduce it on the Pixel 2 XL or the emulator.
Calling pruneWork() before enqueue() doesn't fix the problem.
Reducing the result lifetime by calling keepResultsForAtLeast(..) doesn't work as well.
We provided a sample app which triggers the issue.