我之前碰到过好几个类似的案例，核心问题出在64位设备会优先加载对应架构的SO文件，但你的AAR要么不小心生成了不匹配的架构目录，要么配置没把ABI范围锁死，导致32位SO被错误放到了64位目录里。下面是几个你大概率遗漏的配置点：

1. 未在Library模块严格限制ABI生成范围 #

你设置了ANDROID-ARCH为armeabi-v7a，但如果没在gradle配置里明确指定abiFilters，Android Gradle插件会默认生成所有支持的ABI架构目录（包括arm64-v8a）。这时候插件可能会把32位的SO文件复制到arm64-v8a目录下，导致64位设备加载时检测到SO位数不匹配。

解决方法：在你的AAR Library模块的build.gradle中添加ABI过滤配置：

android {
    defaultConfig {
        ndk {
            // 只生成armeabi-v7a架构的产物
            abiFilters "armeabi-v7a"
        }
    }

    // 若构建类型有单独配置，也要同步设置
    buildTypes {
        release {
            ndk {
                abiFilters "armeabi-v7a"
            }
        }
        debug {
            ndk {
                abiFilters "armeabi-v7a"
            }
        }
    }
}

2. 预构建静态库的存放路径或架构不匹配 #

检查你的预构建静态库是否只放在了src/main/jniLibs/armeabi-v7a目录下。如果误放到了其他架构目录（比如arm64-v8a），或者gradle自动复制了32位库到64位目录，都会导致这个问题。

你可以手动解压生成的AAR文件，查看内部的jniLibs目录：

• 如果存在arm64-v8a目录，里面的SO文件肯定是32位的（可以用file libxxx.so命令验证，输出会显示32-bit），这时候需要删除多余的架构目录，或者调整配置避免自动生成。

3. 主项目未同步限制ABI范围 #

即使你的AAR只包含armeabi-v7a的SO，若主项目没有设置ABI过滤，Gradle会默认生成包含所有架构的APK。64位设备会优先加载arm64-v8a目录下的SO，但如果你的AAR没有提供对应架构的SO，插件可能会把32位SO复制进去凑数，进而触发报错。

解决方法：在主项目的build.gradle中添加相同的ABI过滤配置，确保APK只包含armeabi-v7a架构的SO：

android {
    defaultConfig {
        ndk {
            abiFilters "armeabi-v7a"
        }
    }
}

4. 忽略了Gradle缓存的旧产物 #

有时候旧的架构产物会残存在Gradle缓存中，即使你修改了配置，重新构建时还是会打包进去。这时候需要执行清理命令后再重新构建：

./gradlew clean
./gradlew assembleRelease

额外验证步骤 #

• 解压最终生成的APK，查看lib目录下是否只有armeabi-v7a文件夹，没有arm64-v8a。
• 用file命令检查APK中SO文件的位数，确认都是32位ARM架构。

内容的提问来源于stack exchange，提问作者funny_geek