Running into issue with "Entry name 'META-INF/<module>_<build type>.kotlin_module collided"

In our application, we have many modules with different names. When we upgraded to AS 4.1, android gradle plugin 4.1.0, and gradle 6.5 we have been running into errors like the following:

Entry name 'META-INF/<module>_<build type>.kotlin_module' collided

We have noticed that we have 2 or kotlin_module files under the build directory. Here is an example of the ones we have:

build/intermediates/javac/debug/classes/META-INF/<module>_debug.kotlin_module
build/tmp/kapt3/incrementalData/debug/META-INF/<module>_debug.kotlin_module
build/tmp/kotlin-classes/debug/META-INF/<module>_debug.kotlin_module

These are all found under the module folder.

I would like to figure out how we can fix the error.

3 Likes

Same problem here, it’s intermittent and some days it’s awfull.

Sometimes doing a clean / rebuild does the tricks.
Sometimes doing an invalidate & restart does the trick too.

Same platform as you, starting on Android Studio 4.1 too. We still use kotlin 1.3.72 though.
After a few hours today, I’ve tried gradle 6.6.1 and it disappeared. Put back gradle 6.5.1 and it didn’t appeared back.

A bit lost there…

2 Likes

I’m running into the same issue as well; it happens every time I try to run my app. I’m using Kotlin 1.4, AS 4.1, Gradle 6.6.1, and Android Gradle Plugin 4.1.0.

Nobody else on my team is able to replicate this behavior though, so I’m wondering what I could’ve changed locally to have caused this.

I have found that I’m able to still successfully produce an APK by running ./gradlew clean assembleDebug and then dragging the APK file onto my emulator, so I’d like to know what is different about the build process while using the standard run button.

1 Like

@vdubedout and @molmsted98 I found some more on this issue and it has to do with the new apk creator (zipflinger). https://developer.android.com/studio/releases/gradle-plugin#zipflinger you can read more there. When I ran into the issue I run the gradlew command with the --stacktrace and noticed it failed on zipflinger. I added android.useNewApkCreator=false to my gradle.properties in the project and also in my ~/.gradle/grade.properties files and it still has the same issue. I removed the cache dir under ~/.gradle/ and cleaning all the build folders and caches and nothing seems to work. Others on my team have not run into any issues. The only thing that has really changed is that I have a new mac that has a lot more memory; however, I dont think that is the issue though. I turned off most of our project optimizations and still run into the issue. I have to run ./gradlew clean <task> to get anything to run. It seems like the flag is not getting used with set to false.

1 Like

@srayhunter and @vdubedout, I finally found a definitive answer that reveals that this is the result of a bug in the AGP.

The fix for this issue is mentioned specifically in the Android Studio Canary 1 (2020.3.1.1) changelog, so updating to a Canary build is one way to fix the problem.

Another workaround to use until that change makes it into a Stable release is to add a packagingOptions rule to either exclude / pickFirst (Google did something similar here), although I haven’t been able to get that to work.

1 Like

@molmsted98 that is great to hear. I usually don’t use canary builds too much; however, I might have to give it a try. The packageOptions did not work for me at all. Hopefully zipflinger and the associated property work as well. I tried both of the following:

android.useNewApkCreator=false
android.useNewJarCreator=false

And they did not work. Well see how the update AGP works.

1 Like