Android 符号表

什么是符号表？

第一种：SO符号表

符号表是内存地址与函数名、文件名、行号的映射表。符号表元素如下所示：

<起始地址> <结束地址> <函数> [<文件名:行号>]

对于native crash，为了能快速并准确地定位用户APP发生Crash的代码位置，Bugly使用符号表对APP发生Crash的程序堆栈进行解析和还原。 举一个例子：

第二种：mapping文件

mapping文件用于对混淆后的Java代码进行还原，详见 代码混淆 。

Android 的mapping文件通过App版本，构建号来进行关联。例如，对于指定异常上例，Bugly平台通过App版本，构建号来查找匹配的符号表文件。对于指定的App版本和构建号，Bugly符号表平台支持上传多个符号表文件，通过文件名来区分。

Bugly推荐业务，将宿主的mapping文件命名为mapping.txt，插件或者组件的符号表文件命名为xxx_mapping.txt，支持通过批量上传，或者多次上传这些符号表文件。

详细查看 <<Android应用怎样上传插件的符号表>>

怎么找到符号表？

SO符号表位置

Android平台中，Debug SO文件是指具有调试信息的SO文件，其中包含用户还原堆栈的符号信息。

Debug SO文件

为了方便找回Crash对应的Debug SO文件和还原堆栈，建议每次构建或者发布APP版本的时候，备份好Debug SO文件。或者借助Bugly的符号表上传工具，将符号表上传到Bugly平台。

CMake编译项目: 默认情况下，Debug编译的Debug SO文件将位于：

<项目文件夹>/<Module>/build/intermediates/cmake/debug/obj/local<架构>/

NDK编译项目: 默认情况下，Debug编译的Debug SO文件将位于：

<项目文件夹>/<Module>/build/intermediates/ndk/debug/obj/local<架构>/

mapping文件位置

默认情况下，mapping文件位置在：

<项目文件夹>/<Module>/build/outputs/mapping/<build-type>/

如何判断是否与Crash匹配？

Bugly还原Native Crash堆栈时，需要根据UUID来匹配符号表文件，因此只有上传的符号表文件的UUID与Native Crash堆栈的SO文件的UUID一致时(从后往前匹配)，才能准确地对堆栈进行还原。

对于Java堆栈的还原，当前Bugly使用 APP版本号 + 构建号 来识别和定位mapping文件。

• 查看符号表文件的UUID （详细见 UUID提取指引 ）

• 在问题详情/个例详情/符号表中查看当前异常堆栈中的符号表信息。

如何查看Debug SO文件的UUID？

符号表文件的UUID与Debug SO文件的UUID是一致的，因此可以通过符号表工具生成的符号表文件来查看Debug SO文件的UUID：

生成符号表文件(.zip) ---> 解压符号表文件(.symbol) ---> 使用文本编辑器打开符号表文件

其中符号表文件的“SHA-1”信息即Debug SO文件的UUID，亦是符号表文件的UUID，如果文件较大，建议使用“Sublime Text”等文本编辑器来打开符号表文件。

更多详情见 UUID提取指引 。

提醒

由于Bugly已采用新的UUID计算规则，为了能正确地匹配Crash堆栈对应的SO文件，请使用2.5.0或以上版本的符号表工具。

找不到Crash对应的Debug SO文件？

如果本地已经无法找到Crash对应的符号表文件或者Debug SO文件了，但还能找回Crash对应的APP版本的Native工程代码，建议尝试重新用NDK编译出Debug SO文件并用符号表工具生成符号表文件。

如果连Native工程代码也无法找回了，那就真的无法还原这个Crash堆栈了。

为了防止出现这种情况，建议每次构建或者发布APP版本的时候，一定要备份好Debug SO文件!

如何上传符号表到bugly平台？

方式一：网页上传

详细见 《网页上传符号表》

方式二：符号表工具上传

详细见 《符号表上传工具》