When I added my MPP library to an Android project as a dependency, I started getting `More than one ...

# multiplatform

[nestserau]

When I added my MPP library to an Android project as a dependency, I started getting More than one file was found with OS independent path when trying to build it. Googled it up a little bit, and came up with this workaround (to be placed in the build.gradle of the library consumer):

android {
        packagingOptions {
             pickFirst 'META-INF/ktor-http.kotlin_module'
             pickFirst 'META-INF/kotlinx-io.kotlin_module'
             pickFirst 'META-INF/atomicfu.kotlin_module'
             pickFirst 'META-INF/ktor-utils.kotlin_module'
             pickFirst 'META-INF/kotlinx-coroutines-io.kotlin_module'
             pickFirst 'META-INF/ktor-client-core.kotlin_module'
    }
}

Now the compiler is happy. But is there no other solution? Not a deal breaker for me, but would like to address the core of the issue instead of having this floppy workaround.

[nestserau]

Figured this works just as well:

packagingOptions {
        pickFirst 'META-INF/*.kotlin_module'
    }

I think I’ll live with it for the time being.

[ribesg]

I have the same issue. I’m wondering if this multiple files are actually different or not.

[ribesg]

- If they’re all the same, then why do we have to pick one? The build system should see that they’re the same and pick any

[ribesg]

- If they’re not all the same, then picking the first one may be a very random solution

[nestserau]

I have read (https://stackoverflow.com/questions/54438064/an-error-after-adding-a-library-to-the-android-project-more-than-one-file-was-f) that that META-INF files are not needed at all for the APK. So I guess any way you can shut the compiler up is the best one.

[yshrsmz]

you can use exclude instead of pickFirst

[ribesg]

Yeah I guess it’s better to exclude them if you don’t need them, no need to bloat the apk

[nestserau]

Agreed.

[h0tk3y]

If you use kotlin-reflect, then the absence of these *.kotlin_module files may interfere with accessing reflection of top-level declarations. So you may want to include them into the APK but maybe provide different names for them. However, the conflicting names are most likely an issue on the library side. Ideally, the module name conflicts should be resolved in the libraries side.

[nestserau]

The problem is, I don’t understand what causes this issue on the library side.

[nestserau]

But I don’t use reflection, so that sort of not an issue for me right now.