【问题标题】:How can I generate a cSYM from release build output that contains correct symbols?如何从包含正确符号的发布构建输出生成 cSYM?
【发布时间】:2020-06-10 02:47:17
【问题描述】:

对于 Android,我有一个将 firebaseCrashlytics 与之集成的原生项目。

当我强制崩溃时,它会出现在控制台中。但是,我无法让符号化发生。我的构建过程的输出在build/intermediates/cmake/release/obj 中,这些似乎被正确地用于生成符号以使用 gradle 任务成功上传到 firebase。

app:uploadCrashlyticsSymbolFileRelease

22:08:02.617 [DEBUG] [com.google.firebase.crashlytics] Generating native symbol files for libs in: android/project/crash_reporting/build/intermediates/cmake/release/obj; writing output symbols to: android/project/crash_reporting/build/crashlytics/Release/nativeSymbols
22:08:02.617 [DEBUG] [com.google.firebase.crashlytics] Crashlytics generating cSYM files from object files in android/project/crash_reporting/build/intermediates/cmake/release/obj:
22:08:02.937 [DEBUG] [com.google.firebase.crashlytics] Generating symbols for android/project/crash_reporting/build/intermediates/cmake/release/obj/armeabi-v7a/libcrash_reporting.so
22:08:02.938 [DEBUG] [com.google.firebase.crashlytics] Using DWARF data for cSYM generation.
22:08:03.711 [DEBUG] [com.google.firebase.crashlytics] Generating symbols for android/project/crash_reporting/build/intermediates/cmake/release/obj/x86/libcrash_reporting.so
22:08:03.712 [DEBUG] [com.google.firebase.crashlytics] Using DWARF data for cSYM generation.
22:08:04.525 [DEBUG] [com.google.firebase.crashlytics] Generating symbols for android/project/crash_reporting/build/intermediates/cmake/release/obj/arm64-v8a/libcrash_reporting.so
22:08:04.525 [DEBUG] [com.google.firebase.crashlytics] Using DWARF data for cSYM generation.

查看*.so 文件,我可以看到引发异常的方法的符号。我还可以在控制台中看到它尝试进行符号化,但出错了。

当我手动生成 .cSYM 文件并在 android studio 中查看它时,我没有看到我期望的方法名称。

如果我生成带有调试*.so 输出的cSYM,我确实会看到预期的方法名称。

如果我启用 crashlytics 进行调试,并上传这些符号,我就可以符号化我的调试版本。我不能对发布版本做同样的事情。有什么需要做的吗

(1) 生成 cSYM 以释放足够的信息?一些 DWARF 标志? (2) 使用从调试输出生成的 cSYM 以供发布版本使用。

编辑: 或者......我是否只需要在 debuggable 设置为 true 的情况下构建发布版本,生成并上传符号,然后对构建不执行任何操作。它只是用于符号生成。这是这里的典型方法吗?

【问题讨论】:

    标签: android firebase crashlytics


    【解决方案1】:

    Firebaser 在这里 -

    如果您发现崩溃在调试时得到了正确的符号化而不是发布,这可能与您启用的特定构建设置有关。在为发布应用程序构建时,您构建本机库的方式是否有所不同?当您为发布应用构建时,您的 Gradle 构建有什么不同吗?

    调用app:uploadCrashlyticsSymbolFileRelease 后,进入调试模式并观察logcat 会很有用。如果您同时执行debugrelease,我建议您使用--debug 调用这两个任务并保存输出的日志。可能有很多不相关的输出,因此您可能需要在调用中附加一个过滤器:

    ./gradlew ... | grep "[com.google.firebase.crashlytics]"

    然后观察您是否注意到这些日志之间的任何差异。您可能还需要确保在此处清理上传和不同构建类型之间的构建。日志中需要注意的事项: -DWARF 在这两种情况下仍被用于生成 cSYM - 剥离和未剥离符号的路径在调试和发布之间保持不变

    否则,这似乎是您遇到的一个奇怪问题,您可能需要支持来深入了解您的设置,而不是我们在公共论坛上可以做的。如果是这样,您可能需要联系 Firebase support 并提供您收集的详细信息,他们应该会针对您的设置提供一些故障排除建议。

    【讨论】:

    • 感谢您回复我。对于调试版本,我设置了debuggable=true,这显然会生成更大的输出 *.so 以从中生成符号。对于发布,未设置此项。共享对象要小得多,但如果我检查它,我仍然可以看到人类可读的方法名称。当我从此文件生成 cSYM 时,它不存在。日志表明这里正在使用 DWARF 数据。在构建发布版本以运行任务以生成和上传符号时,是否需要以特定方式构建它们?在早期的 NDK 构建配置中,我们使用 NDK_DEBUG。
    • 我想更具体地说,我如何确保我的发布版本*.so ndk 项目使用 DWARF 数据构建,以便可以用来生成正确的 cSYM。
    • 我认为这里有一些过度使用的术语。当您说“调试”时,您是在谈论 Gradle 文件中的 buildTypes,还是指的是二进制文件的“未剥离”版本?从 OP 看来,当您根据 .so 文件的“调试”(我假设“未剥离”)版本生成符号时,您会得到很好的符号化 - 这是可以预期的,因为它具有我们需要的正确信息生成有用的符号映射。
    • 我想说,要回答这些问题,我们需要更多关于如何设置构建的深入信息 - ndkbuild、cmake 等 - 以及如何构建库(与Android 应用程序,或者作为它的一部分?)您可能想通过它联系 Firebase 支持 - 我可能会看到这种情况 :)
    • 感谢 Kevin,我已经提交了包含更多信息的支持票。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2020-10-16
    • 1970-01-01
    • 1970-01-01
    • 2021-10-24
    • 1970-01-01
    • 1970-01-01
    • 2012-02-05
    相关资源
    最近更新 更多