外部子项目依赖下Crashlytics NDK配置异常排查求助

我之前踩过类似的外部JNI子项目集成Crashlytics的坑，咱们一步步拆解问题、修正配置，让NDK崩溃能正常上报并反混淆：

1. 修正Crashlytics NDK路径配置（避免硬编码坑） #

你之前用的硬编码相对路径../../core/...很容易因为项目结构变化或者gradle执行路径问题出错，换成gradle的项目对象动态获取路径更可靠，同时要区分debug/release变体的符号目录：

在app模块的build.gradle中，替换成如下配置：

crashlytics {
    enableNdk true
    // 动态获取core子项目的符号目录，避免硬编码
    androidNdkOut project(':core').file('build/intermediates/cmake/debug/obj').absolutePath
    androidNdkLibsOut project(':core').file('build/intermediates/cmake/release/obj').absolutePath
}

如果你的项目有flavor或多buildType，更建议在android.buildTypes下分变体配置，确保每个变体对应正确的符号路径：

android {
    buildTypes {
        debug {
            crashlytics {
                enableNdk true
                androidNdkOut project(':core').file('build/intermediates/cmake/debug/obj').absolutePath
                androidNdkLibsOut project(':core').file('build/intermediates/cmake/debug/obj').absolutePath
            }
        }
        release {
            crashlytics {
                enableNdk true
                androidNdkOut project(':core').file('build/intermediates/cmake/release/obj').absolutePath
                androidNdkLibsOut project(':core').file('build/intermediates/cmake/release/obj').absolutePath
            }
        }
    }
}

2. 确保JNI子项目生成正确的调试符号 #

Crashlytics依赖.so文件的调试符号来反混淆崩溃日志，所以要在core子项目的CMakeLists.txt中配置生成带调试信息的符号：

• 对于debug模式，保留完整调试信息：

set(CMAKE_C_FLAGS_DEBUG "${CMAKE_C_FLAGS_DEBUG} -g")
set(CMAKE_CXX_FLAGS_DEBUG "${CMAKE_CXX_FLAGS_DEBUG} -g")

• 对于release模式，既保留符号又控制体积，可以用行号仅保留模式：

set(CMAKE_C_FLAGS_RELEASE "${CMAKE_C_FLAGS_RELEASE} -gline-tables-only")
set(CMAKE_CXX_FLAGS_RELEASE "${CMAKE_CXX_FLAGS_RELEASE} -gline-tables-only")

同时要确保core子项目的build.gradle中正确配置了cmake路径，让gradle能正确生成符号到指定目录：

android {
    externalNativeBuild {
        cmake {
            path "CMakeLists.txt"
        }
    }
}

3. 正确执行符号上传命令 #

执行上传命令前，一定要先构建对应变体的JNI库，否则符号文件还没生成会导致上传无效：

# 先构建core子项目的对应变体，比如FreeDebug
./gradlew :core:assembleFreeDebug
# 再执行符号上传
./gradlew crashlyticsUploadSymbolsFreeDebug

注意替换命令中的Free为你实际的flavor名称，确保变体完全匹配。

4. 排查minidump缺失与崩溃上报异常 #

Logcat中的No minidump data found警告通常和初始化或崩溃场景有关：

• 确保Crashlytics NDK初始化时机正确：在Application的onCreate()中优先初始化Crashlytics，保证在所有JNI代码执行前完成初始化：

// 若使用旧版Fabric
Fabric.with(this, new Crashlytics(), new CrashlyticsNdk());
// 若使用Firebase Crashlytics（推荐）
FirebaseApp.initializeApp(this);
Crashlytics.getInstance().setCrashlyticsCollectionEnabled(true);
CrashlyticsNdk.getInstance().setCrashlyticsCollectionEnabled(true);

• 检查SDK版本：升级到最新的Crashlytics NDK SDK，旧版本可能存在外部子项目的兼容问题：

implementation 'com.google.firebase:firebase-crashlytics-ndk:18.4.0' // 替换为最新版本

• 排查崩溃场景：如果崩溃发生在Application初始化前、JNI线程未被Crashlytics捕获的场景，可能无法生成minidump。可以手动触发一个JNI崩溃测试，比如在按钮点击事件中调用一个会崩溃的JNI方法，验证是否能生成minidump并上报。

5. 验证反混淆有效性 #

如果崩溃日志无法反混淆，大概率是符号文件与崩溃时的.so文件不匹配：

• 每次发布新版本的JNI库时，都要重新执行符号上传命令，确保Crashlytics控制台的符号文件是最新的；
• 检查release模式下是否有额外的strip操作，如果gradle或脚本自动strip了.so的符号，会导致Crashlytics无法反混淆，需要确保上传符号后再执行strip。

内容的提问来源于stack exchange，提问作者Michał Klimczak