bugly android z自动上传符号表失败,Android 符号表

Bugly Android 符号表配置

介绍

什么是符号表？

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

[]

为什么要配置符号表？

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

举一个例子：

Bugly提供了自动和手动两种方法配置Android符号表。

自动配置：使用Android Studio插件

插件的配置和使用方法参考文档：Bugly符号表插件使用指南

手动配置

手动配置的流程如下：

符号表工具JAR包(buglySymbolAndroid.jar)

Windows的脚本(buglySymbolAndroid.bat)

Shell脚本(buglySymbolAndroid.sh)

默认符号表配置文件(settings.txt)

符号表工具Android版-使用指南

根据UUID定位Debug SO文件

使用工具生成符号表文件(zip文件)

在页面上传符号表文件

其他说明

如果项目只使用了混淆代码 (Proguard)，而没有Native工程，只需要直接上传Proguard生成的Mapping文件；

Bugly Android符号表工具2.5.0及以上版本增加了上传功能，并支持Mapping文件的上传；

定位Debug SO文件的方法和工具的使用方法请参考：“符号表工具Android版-使用指南”。

符号表上传接口

Bugly提供了上传符号表的API接口(使用POST方式上传):

https://api.bugly.qq.com/openapi/file/upload/symbol

参数说明

上传接口的参数说明如下：

属性

说明

api_version

API版本，固定为1

app_id

App ID

app_key

App Key

symbolType

符号表类型，Mapping为1，Symbol为3

bundleId

包名(Package)

productVersion

版本号(Version Name)

channel

渠道(channel)

fileName

符号表文件名

file

符号表文件

其中包名、版本号、渠道和符号表文件名需要做URL Encode。

例子：使用Curl上传

使用Curl工具来上传的例子如下：

上传Mapping文件

curl -k "https://api.bugly.qq.com/openapi/file/upload/symbol?app_key=xxx&app_id=9000xxx" --form "api_version=1" --form "app_id=xxxxxx" --form "app_key=xxxxxx" --form "symbolType=1" --form "bundleId=com.demo.test" --form "productVersion=1.0" --form "channel=xxx" --form "fileName=mapping.txt" --form "file=@mapping.txt" --verbose

上传符号表文件(Symbol文件)

curl -k "https://api.bugly.qq.com/openapi/file/upload/symbol?app_key=xxx&app_id=9000xxx" --form "api_version=1" --form "app_id=xxxxxx" --form "app_key=xxxxxx" --form "symbolType=3" --form "bundleId=com.demo.test" --form "productVersion=1.0" --form "fileName=symbol.zip" --form "file=@symbol.zip" --verbose

Debug SO文件

什么是Debug SO文件？

Android平台中，目标文件对应的是SO文件。Debug SO文件是指具有调试信息的SO文件。

为了方便找回Crash对应的Debug SO文件和还原堆栈，建议每次构建或者发布APP版本的时候，备份好Debug SO文件。

如何定位Debug SO文件？

IDE: Eclipse

IDE如果使用Eclipse+NDK，默认情况下，Debug SO文件将位于：

/obj/local//

如下图所示：

IDE: Android Sutdio

IDE如果使用Android Sutdio+NDK，默认情况下，Debug编译的Debug SO文件将位于：

//build/intermediates/ndk/debug/obj/local/

而Release编译的Debug SO文件将位于：

//build/intermediates/ndk/release/obj/local/

如下图所示：

如何判断是否与Crash匹配？

Bugly v2.0页面

Bugly v1.0还原Crash堆栈时，根据App包名、App版本号、SO文件名和架构来匹配符号表文件。

使用工具上传方式

检查生成符号表文件时输入的SO文件名和架构是否和Crash堆栈的SO文件匹配；

上传时指定的App包名、版本号是否和Crash对应的App包名和版本号匹配。

手动上传方式

检查生成符号表文件时输入的SO文件名和架构是否和Crash堆栈的SO文件匹配；

在版本管理页面下，检查符号表文件是否是在Crash对应App版本(包名和版本)下上传的。

Bugly v2.0页面

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

查看Crash对应的APP的UUID：

崩溃分析 ---> Crash issue ---> 符号表 ---> UUID

如何查看Debug SO文件的UUID？

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

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

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

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

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

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

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

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