查看是否strip
可以通过命令行来查看 so 的状态,Mac下使用 file 命令即可,在命令返回值里面可以查看到so的一些基本信息。
stripped代表是没有debug信息的so,with debug_info, not stripped代表携带debug信息的so。
file libbreakpad-core-s.so
libbreakpad-core-s.so: *******, BuildID[sha1]=54ad86d708f4dc0926ad220b098d2a9e71da235a, stripped
file libbreakpad-core.so
libbreakpad-core.so: ******, BuildID[sha1]=54ad86d708f4dc0926ad220b098d2a9e71da235a, with debug_info, not stripped
已经striped的so仍然可能看到函数名
类似mapping文件
➜ 23.1.7779620 ./ndk-stack -sym /lib/build/intermediates/cmake/debug/obj/arm64-v8a/ -dump /test11.log
NDK 符号表还原堆栈是一个用于分析 Android 应用中 Native 层崩溃问题的工具。当你的应用发生 Native 层的崩溃时,ndk-stack 工具可以帮助你将崩溃日志中的内存地址转换为可读的函数名和源代码行号,从而定位问题所在。以下是使用 ndk-stack 以及符号表还原堆栈的一般步骤:
获取崩溃日志:首先,你需要从应用中捕获崩溃日志。这通常通过 Android Studio 的 Logcat 工具或使用 adb logcat 命令来完成。
使用 ndk-stack 工具:ndk-stack 是 Android NDK 中的一个工具,它可以解析崩溃日志并尝试将内存地址映射回符号信息。使用时需要指定符号表目录和日志文件路径。基本命令格式如下:
ndk-stack -sym <符号表目录> -dump <日志文件路径>
其中 <符号表目录> 是包含符号表文件(通常是 .so 文件)的目录路径,<日志文件路径> 是包含崩溃日志的文件路径 。
符号表的准备:符号表是内存地址与函数名、文件名、行号的映射表。为了使用 ndk-stack 工具,你需要确保符号表与崩溃时加载的 .so 文件匹配。符号表通常可以在 .so 文件的 Debug 版本中找到,或者通过 Bugly 等平台上传和使用 。
解析结果:ndk-stack 会输出转换后的函数名和源代码行号信息,对应于崩溃堆栈中的地址。这可以帮助开发者确定崩溃发生的具体函数和源代码行号,以及可能的调用栈信息 。
注意事项:确保使用的 ndk-stack 工具版本与编译应用时使用的 NDK 版本一致。此外,符号表文件的 UUID 需要与崩溃时加载的 .so 文件的 UUID 匹配,以确保堆栈信息的准确还原 。
Bugly 平台的使用:如果你使用 Bugly 等崩溃监控平台,可以上传符号表文件到平台,并在发生崩溃时由平台自动进行堆栈信息的解析和还原 。
其他工具:除了 ndk-stack,还有其他工具如 addr2line 可以用来将地址转换为文件名和行号,objdump 可以用来反汇编 .so 文件,这些工具可以辅助进行更深入的分析 。
这个过程需要你有应用的源代码和编译时生成的符号表文件。如果你没有这些信息,可能无法准确地还原堆栈信息。
android app 保存符号表
build.gradle
packagingOptions {
doNotStrip "*/arm64-v8a/*.so"
}
ref
https://www.cnblogs.com/vivotech/p/14442561.html
https://bugly.tds.qq.com/docs/tutorial/symbol/android/
https://bugly.qq.com/docs/user-guide/symbol-configuration-android/
https://www.jianshu.com/p/58760868b468
https://tech.meituan.com/2022/06/02/meituans-technical-exploration-and-practice-of-android-so-volume-optimization.html