IssueTracker

Hi, some users reported that installing "Vulkan SDK" helps with this issue. What is your GPU and its driver versions?

Could you please try stating the Emulator from the command line this way

cd C:\Users\crazy\Desktop\CODING\AndroidSDK\emulator
emulator.exe -avd Pixel_9_Pro_XL_API_33 -wipe-data -no-snapshot -verbose -feature -Vulkan

and attach its output? If you notice any popups about missing dlls please include them here.

Thank you, please try adding -gpu swangle (this is a software GPU, it will be slow), I think for whatever reason we can't talk to your GPU.

Please consider trying the latest version we have here:

https://developer.android.com/studio/emulator_archive

DEBUG | emuglConfig_get_vulkan_hardware_gpu: Physical devices count is 0

Serdar, could you please take a look?

Please check if you have crashreports and if you do consider uploading them (please attach crash ids here):

cd C:\Users\crazy\Desktop\CODING\AndroidSDK\emulator
crashreport.exe -l
crashreport.exe -u

Thank you a lot! We got the crash. I think we can't handle zero of VK devices well :) Serdar should know more why we get zero VK devices.

https://android.googlesource.com/platform/external/qemu/+/refs/heads/emu-master-dev/android/android-ui/modules/aemu-gl-init/src/android/opengl/emugl_config.cpp#525

Maybe we should return false if deviceCount is zero.

Does this look related?

https://github.com/KhronosGroup/Vulkan-Loader/issues/552

As I understand, Vulkan-Loader/issues/552 is talking about the case when there are two GPUs: an integrated AMD and a separate NVIDIA and somehow the AMD side prevents returning anything. If this is your case, I think the solution is to update the AMD GPU drivers.

Thank you for confirming this. We will fix the crash, but all we can do is to say "Your system has no Vulkan devices, update drivers or something" and exit.

Thanks for reporting this, a change is submitted (aosp/3393546) and will be available in the next canary builds of the emulator to correctly give an error for zero device cases. I'll close this one now as the booting issue is resolved with a driver update.

Thank you for your patience while our engineering team worked to resolve this issue. A fix for this issue is now available in:

• Android Emulator 35.3.11 Stable

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

Thank you for taking the time to submit feedback — we really appreciate it!

Further fixes for this issue are now available in:

• Android Emulator 35.4.5 Canary

We encourage you to try the latest update.

If you notice further issues or have questions, please file a new bug report.

There are some architectural changes coming in Lint that will fix this properly, but they will not make it into 4.2.

However, there is another workaround you can try that will be available starting in AGP 4.2 Beta 4.

Essentially you can tell Lint to "reset" the Kotlin compiler between each module analysis, thereby clearing all caches. I did not make this the default behavior because the effect on performance is unknown/risky.

To enable this behavior, either set the environment variable LINT_DO_NOT_REUSE_UAST_ENV to "true", or set the JVM system property lint.do.not.reuse.uast.env to "true". For example, you can do this from the command line:

./gradlew -Dlint.do.not.reuse.uast.env=true :app:lintDebug

Or by putting this in your gradle.properties file:

systemProp.lint.do.not.reuse.uast.env=true

Status updates:

• I'm still hoping someone can confirm whether the workaround in comment#22 worked for them in AGP 4.2.

• Starting with AGP 7.0-alpha13 the root cause of this issue should be fixed completely due to the new "partial analysis" mode (enabled by default) in which Lint analyzes modules independently and merges results along the way. It fixes the issue because Lint will no longer use the same Kotlin compiler environment to analyze multiple modules (and so the risk of stale caches is gone).

I'm still hoping someone can confirm whether the workaround in comment#22 worked for them in AGP 4.2.

This unfortunately did not work for us. We actually see lint crashes after enabling via systemProp.lint.do.not.reuse.uast.env=true. See the attached log. It's also much slower, as expected.

AGP 4.2 seems to make this error much more frequent compared to 4.1, for some reason.

comment #24 The error message is very different --- it looks like a different issue to me.

Can you file a new bug? You can add a comment here linking to it.

Sure. Without that workaround, we get the same

ERROR: package fragment is not found for module:<lint-module> is a module[ModuleDescriptorImpl@5e5e6c61] file:KtFile: LiveViewerViewData.kt

error in this ticket occasionally (1-2% of the time?).

Oh, I misunderstood. So, using lint.do.not.reuse.uast.env is what causes the new crash? That is unfortunate, and I will investigate. Let me know if there is a sample project you can share that reproduces the issue.

Not sure if you still wanted the new bug, but here it is: https://issuetracker.google.com/issues/187851920

FYI the issue in comment #24 should be fixed by Change Ib7d4d6c9e in AGP 4.2.2.

And to confirm, lint.do.not.reuse.uast.env should no longer be needed at all in AGP 7.0+.

Thanks #29 . I am noticing that when this happens, after the error log for

package fragment is not found for module:<lintWithKotlin> is a module

There is another error

java.lang.IllegalArgumentException: Argument for @NotNull parameter 'descriptor' of org/jetbrains/kotlin/codegen/context/CodegenContext.intoPackagePart must not be null
	at org.jetbrains.kotlin.codegen.context.CodegenContext.$$$reportNull$$$0(CodegenContext.java)
	at org.jetbrains.kotlin.codegen.context.CodegenContext.intoPackagePart(CodegenContext.java)
	at org.jetbrains.kotlin.asJava.builder.LightClassDataProviderForClassOrObject$computeLightClassData$1$1.invoke(LightClassDataProvider.kt:51)
	at org.jetbrains.kotlin.asJava.builder.LightClassDataProviderForClassOrObject$computeLightClassData$1$1.invoke(LightClassDataProvider.kt:38)
	at org.jetbrains.kotlin.asJava.builder.LightClassBuilderKt.buildLightClass(LightClassBuilder.kt:64)
	at org.jetbrains.kotlin.asJava.builder.LightClassDataProviderForClassOrObject$computeLightClassData$1.invoke(LightClassDataProvider.kt:47)
	at org.jetbrains.kotlin.asJava.builder.LightClassDataProviderForClassOrObject$computeLightClassData$1.invoke(LightClassDataProvider.kt:38)
	at org.jetbrains.kotlin.cli.jvm.compiler.CliLightClassGenerationSupport.createDataHolderForClass(CliLightClassGenerationSupport.kt:64)
	at org.jetbrains.kotlin.asJava.builder.LightClassDataProviderForClassOrObject.computeLightClassData(LightClassDataProvider.kt:45)
	at org.jetbrains.kotlin.asJava.builder.LightClassDataProviderForClassOrObject.compute(LightClassDataProvider.kt:61)
	at com.intellij.psi.impl.PsiCachedValueImpl.doCompute(PsiCachedValueImpl.java:54)
	at com.intellij.util.CachedValueBase.lambda$getValueWithLock$1(CachedValueBase.java:235)
	at com.intellij.openapi.util.RecursionManager$1.doPreventingRecursion(RecursionManager.java:113)
	at com.intellij.openapi.util.RecursionManager.doPreventingRecursion(RecursionManager.java:72)
	at com.intellij.util.CachedValueBase.getValueWithLock(CachedValueBase.java:236)
	at com.intellij.psi.impl.PsiCachedValueImpl.getValue(PsiCachedValueImpl.java:43)
	at 

Does the fix address both of these?

comment #30 For those issues (package fragment is not found and Argument for @NotNull parameter...), the workaround in 4.2 is to put

systemProp.lint.do.not.reuse.uast.env=true

in your gradle.properties file as described in comment #22. Please let me know if it works or not for you.

Marking fixed in AGP 7.0.

That is, the lint.do.not.reuse.uast.env workaround should no longer be needed in AGP 7.0+. And, you should no longer see the following warnings/errors while running Lint:

ERROR: package fragment is not found for module:<lintWithKotlin>...

ERROR: Could not generate LightClass for...

java.lang.IllegalArgumentException: Argument for @NotNull parameter 'descriptor' of org/jetbrains/kotlin/codegen/context/CodegenContext.intoPackagePart must not be null

The issue is fixed due to the new "Lint partial analysis" mode (enabled by default) which creates a standalone UastEnvironment instance for each module, thereby avoiding stale caches in the Kotlin compiler frontend.

Please comment on the bug if you see any similar errors in AGP 7.0+.