CODEWITHSUNDEEP
androidgradledependenciesarcore
Sirop4ik
Sirop4ik

Reputation: 5243

More than one file was found with OS independent path 'lib/armeabi-v7a/libarcore_sdk_jni.so'

I know there is a few similar questions on SO, but it does not work for me...

I created Android lib, that use ArCore. It was a question on SO how to don't include .so file if I use created ndk lib? There is also one answer that sounds right

https://stackoverflow.com/a/58963852/5709159

But after I putted libarcore.so files under my jniLib

enter image description here

I got such error

More than one file was found with OS independent path 'lib/armeabi-v7a/libarcore_sdk_jni.so'

So, I tried to fix it this ways

https://stackoverflow.com/a/44962630/5709159

sourceSets.main {
        jniLibs.srcDir 'src/main/jniLibs'
        jni.srcDirs = [] //disable automatic ndk-build call
    }

https://stackoverflow.com/a/56453718/5709159

packagingOptions {
    pickFirst 'src/main/jniLibs/arm64-v8a/libarcore_sdk_jni.so'
    pickFirst 'src/main/jniLibs/armeabi-v7a/libarcore_sdk_jni.so'
    pickFirst 'src/main/jniLibs/x86/libarcore_sdk_jni.so'
    pickFirst 'src/main/jniLibs/x86_64/libarcore_sdk_jni.so'
}

then this

packagingOptions {
    pickFirst 'lib/arm64-v8a/libarcore_sdk_jni.so'
    pickFirst 'lib/armeabi-v7a/libarcore_sdk_jni.so'
    pickFirst 'lib/x86/libarcore_sdk_jni.so'
    pickFirst 'lib/x86_64/libarcore_sdk_jni.so'
}

and also this packagingOptions { exclude 'lib/arm64-v8a/libarcore_sdk_jni.so' exclude 'lib/armeabi-v7a/libarcore_sdk_jni.so' exclude 'lib/x86/libarcore_sdk_jni.so' exclude 'lib/x86_64/libarcore_sdk_jni.so' }

Nothing helped.

As far as I understand issue is - I have one copy of arcore.so files under my jniLibs dir and one copy created after Build here

enter image description here

So, how to fix it?

Upvotes: 3

Views: 3276

Answers (2)

Vinod Ranga
Vinod Ranga

Reputation: 531

this solution will work

https://github.com/facebook/react-native/issues/35210#issuecomment-1304536693

adding the below code in android/gradle

  def REACT_NATIVE_VERSION = new File(['node', '--print',"JSON.parse(require('fs').readFileSync(require.resolve('react-native/package.json'), 'utf-8')).version"].execute(null, rootDir).text.trim())
configurations.all {
    resolutionStrategy {
        // Remove this override in 0.66, as a proper fix is included in react-native itself.
        force "com.facebook.react:react-native:" + REACT_NATIVE_VERSION
    }
}

Upvotes: 0

Martin Zeitler
Martin Zeitler

Reputation: 76699

You've likely added the shared .so files and build from source (or reference them otherwise).

One cannot do both at the same time, so you'd either need to build from source and delete those .so files - or delete the arcore-android-sdk module and keep the .so files. Java dependencies might also pull in native assembly, while that part of the build.gradle is missing (just browse AR core in the "External Libraries" to see what it contains, in case it exists there). Using pre-built libraries generally builds quicker and saves time - which is suggested, unless needing to edit cpp sources.

Usually one can provide the dependencies alike in this build.gradle:

dependencies {
    implementation "com.google.ar:core:1.13.0"
    natives "com.google.ar:core:1.13.0"
}

// Extracts the shared libraries from aars in the natives configuration.
// This is done so that NDK builds can access these libraries.
task extractNativeLibraries() {
    // Always extract, this ensures the native libs are updated if the version changes.
    outputs.upToDateWhen { false }
    doFirst {
        configurations.natives.files.each { f ->
            copy {
                from zipTree(f)
                into arcore_libpath
                include "jni/**/*"
            }
        }
    }
}

tasks.whenTaskAdded {
    task-> if (task.name.contains("external") && !task.name.contains("Clean")) {
        task.dependsOn(extractNativeLibraries)
    }
}

Such Gradle task could also be the reason for the duplicates, when it's not configured properly. packagingOptions are in every case the wrong approach, when the linker already doesn't know which one to link.

Upvotes: 2

Related Questions