Fixed
Status Update
No update yet.
Comments
il...@google.com
il...@google.com
ap...@google.com
Update: I was able to downgrade to 32.1.10 and I can confirm it's smooth again. The issue is indeed in emulator version 33.1.1
ap...@google.com
It's happening to me too and I also confirm that reverting to 32.1.10 fixes the issue.
We should have an easier way of reverting versions. AS should allow picking the version similarly to how we already do for the other tools in SDK manager.
We should have an easier way of reverting versions. AS should allow picking the version similarly to how we already do for the other tools in SDK manager.
ga...@gmail.com
Hi,
would you try to turn on hardware GPU rendering (instead of auto GPU) and see if it fixes this issue?
would you try to turn on hardware GPU rendering (instead of auto GPU) and see if it fixes this issue?
fo...@google.com
Hi,
I'm currently not able to change this option, it is greyed out.
I'm currently not able to change this option, it is greyed out.
ap...@google.com
Hi,
there are 2 ways to set it:
1. use a google_apis image (instead of google_apis_playstore). it will re-enable the option.
2. go to your avd folder (usually located in ~/.android/avd/your_avd_name.avd/), open config.ini and hardware-qemu.ini, then modify those lines:
hw.gpu.enabled=yes
hw.gpu.mode=host
there are 2 ways to set it:
1. use a google_apis image (instead of google_apis_playstore). it will re-enable the option.
2. go to your avd folder (usually located in ~/.android/avd/your_avd_name.avd/), open config.ini and hardware-qemu.ini, then modify those lines:
hw.gpu.enabled=yes
hw.gpu.mode=host
ap...@google.com
Hi,
Yes, option 2 fixes the issue (which also persists on 33.1.2 btw). Even though I get a warning when I start the emulator (see attachments).
Will this option be enabled "out of the box" in a future version?
Yes, option 2 fixes the issue (which also persists on 33.1.2 btw). Even though I get a warning when I start the emulator (see attachments).
Will this option be enabled "out of the box" in a future version?
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.