Android | 质量平台帮助文档

# - Unity mono 下出现卡死情况

当前Crasheye NDK(V2.1.5 版本)暂时无法兼容Unity mono, 开发环境调试用mono时建议暂时屏蔽crasheye的C++捕捉

@override
public void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    if (!BuildConfig.DEBUG) {
      Crasheye.initWithNativeHandle(this, "Your_AppKey");
    }
}

# - 符号文件什么时候生成？

每编译一次就会生成全新的符号文件，Android平台中，目标文件对应的是SO文件。每次构建或者发布APP版本的时候，一定要做好 备份好符号文件，或做符号文件自动上传。自动上传方法可查看Q3

# - 符号文件路径位置？

通常游戏项目，需要上传项目编译的so （如果有c++代码，也需要上传c++ 编译的so），以及libunity.so 工程中，有xx.sym.so 或 xxx.dbg.so 或 xxx.so 这几种符号文件 uuid是相同的通常推荐上传xxx.dbg.so。
符号文件的位置通常在:

# il2cpp

libunity.so (如果没有重新编译引擎，默认在编辑器的如下目录）
libil2cpp.so (打包后在项目自己的构建临时目录下）

# il2cpp Release(armeabi-v7a)版本

\Unity\Editor\Data\PlaybackEngines\AndroidPlayer\Variations\il2cpp\Release\Symbols\armeabi-v7a\libunity.sym.so

# il2cpp Development(armeabi-v7a)版本

\Unity\Editor\Data\PlaybackEngines\AndroidPlayer\Variations\il2cpp\Development\Symbols\x86\libunity.sym.so

# il2cpp Release(x86)版本

\Unity\Editor\Data\PlaybackEngines\AndroidPlayer\Variations\il2cpp\Release\Symbols\x86\libunity.sym.so

# il2cpp Development(x86)版本

\Unity\Editor\Data\PlaybackEngines\AndroidPlayer\Variations\il2cpp\Development\Symbols\x86\libunity.sym.so

# MONO

# mono需要上传的符号文件

libunity.so (如果没有重新编译引擎，默认在编辑器的如下目录）
libmono.so (如果没有重现编辑mono，默认在编辑器的如下目录）

# Release(armeabi-v7a)版本

\Unity\Editor\Data\PlaybackEngines\AndroidPlayer\Variations\mono\Release\Symbols\armeabi-v7a\libunity.sym.so

\Unity\Editor\Data\PlaybackEngines\AndroidPlayer\Variations\mono\Release\MonoLibs\armeabi-v7a\libmono.so

# Release(x86)版本

\Unity\Editor\Data\PlaybackEngines\AndroidPlayer\Variations\mono\Release\Symbols\x86\libunity.sym.so

\Unity\Editor\Data\PlaybackEngines\AndroidPlayer\Variations\mono\Release\MonoLibs\x86\libmono.so

# Development(armeabi-v7a)版本

\Unity\Editor\Data\PlaybackEngines\AndroidPlayer\Variations\mono\Development\Symbols\armeabi-v7a\libunity.sym.so

\Unity\Editor\Data\PlaybackEngines\AndroidPlayer\Variations\mono\Development\MonoLibs\armeabi-v7a\libmono.so

# Development(x86)版本

\Unity\Editor\Data\PlaybackEngines\AndroidPlayer\Variations\mono\Development\Symbols\x86\libunity.sym.so

\Unity\Editor\Data\PlaybackEngines\AndroidPlayer\Variations\mono\Development\MonoLibs\x86\libmono.so

# 注意！！！

如果勾选了 strip engine code，必须要勾选Creat Symbol.zip , 项目打包出来以后会生成符号zip和libunity.so，否则将没有符号文件生成！！！

# - 符号文件每次都要上传吗？怎么做自动上传

为了方便找回Crash对应的Debug SO文件和还原堆栈，每次构建或者发布APP版本的时候，一定要做好备份好符号文件，或做符号文件自动上传。一旦符号文件无法找回，堆栈将无法还原！！！

符号文件自动上传方法：

构建脚本使用符号文件工具进行上传
使用符号文件工具，在构建脚本中进行上传

注意！！！

上传xx.sym.so 或 xxx.dbg.so 的时候！！！必须！！！重命名，重命名规则：xxx.sym.so->xxx.so, xxx.dbg.so->xxx.so 然后再上传。（不重命名再跑命令行，分析后台会无法匹配到符号）
如果勾选了 strip engine code，必须要勾选Creat Symbol.zip , 项目打包出来以后会生成符号zip和libunity.so，否则将没有符号文件生成！！！

# - 平台显示符号文件uuid比本地符号文件uuid多了一个0，是为什么？

Crasheye 里面uuid计算方式和buildid是有些区别的，最后一位都会加一个0，不影响符号文件匹配

# - 符号文件的uuid 是什么？

elf文件的build id，每次编译生成唯一ID

# - 调用了log接口，但是没有收集上log

manifest中是否有 READ_LOGS 权限

# - Android 触发dump 后，为什么收不到崩溃？

按照下述步骤进行排查

查看日志，确认Crasheye init 成功
触发崩溃后，是否重启游戏，dump 将在重新启动游戏后上报，通常10min内就会上报
确认android 初始化是否在java 层，打java包的方法，详见Android初始化

# - 后台只看到Java相关的错误堆栈信息，没发现有NDK相关的堆栈异常？

问题排除方法：

这种情况应该是初始化错误，Crasheye NDK相关的初始化应该是调用：详情参考Android NDK接入指南 Crasheye.initWithNativeHandle(this, "Your_Appkey");
不同的项目引擎排除方法也不一样，Logcat中有相应的日志输出，例如：引擎使用Cocos2d，查看logcat初始化日志：查看是否有下图的NDK初始化信息，如果没有，代表NDK没有初始化成功，请参照第一步重新初始化；

请不要将Crasheye加入代码混淆；
如果是项目的so也加入了混淆，则Crasheye无法捕获NDK的宕机；

# - 部分机型在Android5.0 之后的版本捕获不到NDK异常？

libCrasheyeNDK.so 版本过旧，更新官网最新版本的so就可以成功捕获: NDK下载

# - 接入Unity SDK后，初始化提示 mono signal chain fail 是啥原因？

该Error并不影响Crasheye 的接入，忽略即可

# - 页面堆栈未解析，是什么原因？

请根据下述方法进行排查

# 符号文件没有上传

页面提示 module “符号文件名” uuid “符号文件uuid” is miss

点击重新分析，如果页面仍然进行 miss提示，进行步骤2排查
在设置 - 符号文件页面，根据uuid，搜索符号文件是否存在，符号文件名是否完全匹配

如果符号文件不存在，请在构建机上查找符号文件并重新上传

# 堆栈损坏

页面提示 module “符号文件名” uuid “符号文件uuid” is corrupt，底层breakpad 无法解析，此种崩溃无论是Crasheye 还是用户都无法进行任何处理，通常这种崩溃仍然可以解析出部分堆栈，用户可以根据有限的堆栈，进行崩溃分析。

更多的解释可见：

Heap corruption occurs when dynamic allocation of memory is not handled properly. Typical heap corruption problems are reading, or writing outside of the bounds of allocated memory, or double-freeing memory. Since the result (e.g. a hard crash) can happen later, when the program tries to manipulate the incorrectly allocated piece of memory, the root cause of the issue can remain hidden from your eyes.

# 先触发崩溃，再上传崩溃，点击重新分析即可

服务不会实施监控符号文件上传，因此先触发崩溃，再上传崩溃，页面堆栈也会未解析，此时需要点击重新分析，堆栈将会重新解析

# - 如何获取lua 的脚本异常？

在初始化后调用API，捕获到脚本异常（例如空指针等），Android、iOS、Unity 插件均支持捕获脚本异常，具体接入见常用API

为了减少重复上报，相同的异常信息在 10 分钟内只能上报一次

# - 堆栈解析可以定位到行号吗？

有些可以定位到行号，有些不行。
不是所有的堆栈都可以解析出行号的，需要具体问题具体分析。
如果已经上传符号文件，并且已经点击重新分析，可以查看解析后的堆栈

← 崩溃上报检查 IOS →