Android Studio: How to Fix ‘A failure occurred while executing MergeNativeLibsTask$MergeNativeLibsTaskWorkAction’

When building in Android Studio, you may see the error “A failure occurred while executing MergeNativeLibsTask$MergeNativeLibsTaskWorkAction”. This error indicates that the Android Gradle Plugin failed while merging native libraries (.so files) to be included in the app. Because the error message itself often does not directly identify the cause, it is important to check the detailed message displayed immediately after it.

What the error means

Android apps may contain .so files under paths such as lib/arm64-v8a/ or lib/armeabi-v7a/ due to the NDK, CMake, JNI, or dependencies such as advertising SDKs, game SDKs, and image-processing SDKs. During the build, the Android Gradle Plugin gathers these files, but if multiple .so files exist at the same path or packaging settings conflict, the MergeNativeLibsTask process can fail.

Execution failed for task ':app:mergeDebugNativeLibs'.
> A failure occurred while executing MergeNativeLibsTask$MergeNativeLibsTaskWorkAction

Main causes

1. The same .so file is included in multiple dependencies

If multiple AARs or SDKs contain the same native library, they may conflict when they are placed at the same path. Duplicate libc++_shared.so files are a common example.

2. The same library is added from both jniLibs and CMake

If an .so file manually placed in src/main/jniLibs is also automatically packaged from CMake or a dependency AAR, the same library may be included twice.

3. An old SDK or dependency is not compatible with the current Android Gradle Plugin

Older AARs or NDK-related libraries may not be compatible with the current packaging behavior, which can cause problems during the native-library merge process.

4. The packaging configuration is inappropriate

The build may fail when duplicated .so files require pickFirsts or excludes settings but they are not configured, or when an old packagingOptions configuration remains in the project.

5. The build cache or intermediate outputs are corrupted

After changing dependencies, old intermediate outputs may remain and cause the merge process to fail because they no longer match the current configuration.

How to check the cause

1. Check the detailed message immediately after the error

First, open Build Output and check not only the MergeNativeLibsTaskWorkAction line but also the following several lines.

./gradlew assembleDebug --stacktrace

On Windows, run the following command.

gradlew.bat assembleDebug --stacktrace

If necessary, add --info to view more detailed logs.

./gradlew assembleDebug --info

2. Check dependencies

Display the dependency tree to identify which libraries are bringing native files into the project.

./gradlew app:dependencies

Check whether the same SDK is included both as a direct dependency and a transitive dependency, or whether multiple SDKs with similar functions have been added.

3. Check the jniLibs folders

If manually added .so files exist in folders such as the following, check whether the same files are also included by dependencies.

app/src/main/jniLibs/arm64-v8a/
app/src/main/jniLibs/armeabi-v7a/
app/src/main/jniLibs/x86/
app/src/main/jniLibs/x86_64/

Solutions

Method 1. Organize the sources of duplicated .so files

The most reliable solution is to avoid including the same .so file through multiple paths. If a library automatically included from CMake or an AAR is also manually placed in jniLibs, remove the unnecessary copy.

Method 2. Configure packaging pickFirsts

If the same .so file is included from multiple dependencies and you clearly know that selecting either one is safe, you can use pickFirsts.

Groovy DSL example:

android {
    packaging {
        jniLibs {
            pickFirsts += ['**/libc++_shared.so']
        }
    }
}

Kotlin DSL example:

android {
    packaging {
        jniLibs {
            pickFirsts += "**/libc++_shared.so"
        }
    }
}

Method 3. Exclude unnecessary native libraries

If you know that a specific .so file does not need to be included in the app, you can exclude it with excludes.

android {
    packaging {
        jniLibs {
            excludes += ['**/unnecessary-library.so']
        }
    }
}

However, excluding an .so file required at runtime can cause errors such as UnsatisfiedLinkError, so do not casually exclude libraries whose purpose you do not understand.

Method 4. Update SDKs and dependencies

If you are using an old SDK, update it to the latest version or to a version compatible with the current Android Gradle Plugin. In particular, when multiple SDKs include the same C++ runtime, updating the SDKs may resolve the duplication.

Method 5. Remove unnecessary dependencies

Check build.gradle or build.gradle.kts and make sure the same library is not declared in multiple versions.

dependencies {
    implementation 'com.example:library:latest-version'
}

If a directly declared dependency conflicts with a transitive dependency brought in by another SDK, consider aligning dependency versions or removing unnecessary dependencies.

Method 6. Clean and rebuild

After fixing the configuration, remove intermediate outputs and rebuild the project.

./gradlew clean
./gradlew assembleDebug

In Android Studio, you can also run Build → Clean Project and then Build → Rebuild Project.

Notes

• MergeNativeLibsTaskWorkAction is a higher-level failure message, so do not determine the cause from this single line alone.
• For duplication errors, it is important to identify which dependencies are bringing in the same .so file.
• pickFirsts is convenient, but selecting one of different binaries unconditionally can lead to runtime crashes.
• If the problem started immediately after changing the NDK, CMake, Android Gradle Plugin, or an external SDK, checking the changed dependency first is efficient.
• After deleting or excluding a native library, always test the affected functionality on a physical device or emulator.

Summary

“A failure occurred while executing MergeNativeLibsTask$MergeNativeLibsTaskWorkAction” appears when the Android Gradle Plugin fails while merging .so files. First, check the detailed logs to find the real cause, then inspect the sources of duplicated .so files, jniLibs, CMake, dependency AARs, and packaging settings in order. Organizing duplicate inclusion paths should be the first priority. If necessary, use pickFirsts or excludes, then clean and rebuild the project to make troubleshooting easier.