Bugly支持自动集成和手动集成两种方式,如果您使用Gradle编译Apk,强烈推荐您使用自动接入方式配置库文件。
Bugly支持JCenter仓库和Maven Central仓库。为了实现更加灵活的配置,Bugly SDK(2.1.5及以上版本)和NDK(SO库)目前已经分开成两个独立的仓库:
其中,集成Bugly NDK时,需要同时集成Bugly SDK。
在Module的build.gradle文件中添加依赖和属性配置:
dependencies {
compile 'com.tencent.bugly:crashreport:latest.release' //其中latest.release指代最新Bugly SDK版本号,也可以指定明确的版本号,例如2.2.0
}
在Module的build.gradle文件中添加依赖和属性配置:
android {
defaultConfig {
ndk {
// 设置支持的SO库架构
abiFilters 'armeabi' //, 'x86', 'armeabi-v7a', 'x86_64', 'arm64-v8a'
}
}
}
dependencies {
compile 'com.tencent.bugly:crashreport:latest.release' //其中latest.release指代最新Bugly SDK版本号,也可以指定明确的版本号,例如2.1.9
compile 'com.tencent.bugly:nativecrashreport:latest.release' //其中latest.release指代最新Bugly NDK版本号,也可以指定明确的版本号,例如3.0
}
同时集成Bugly SDK和NDK的配置如下图所示,后续更新Bugly SDK和NDK时,只需变更配置脚本中的版本号即可。
注意:自动集成时会自动包含Bugly SO库,建议在Module的build.gradle文件中使用NDK的“abiFilter”配置,设置支持的SO库架构。
如果在添加“abiFilter”之后Android Studio出现以下提示:
NDK integration is deprecated in the current plugin. Consider trying the new experimental plugin.
则在项目根目录的gradle.properties文件中添加:
android.useDeprecatedNdk=true
如果您不采用上述自动导入方式,也可以手动集成Bugly SDK。
下载Bugly库文件
Bugly NDK包含多个架构的SO库:
- armeabi
- armeabi-v7a
- arm64-v8a
- x86
- x86_64
在集成Bugly SO库时,请注意只保留支持的架构SO库。
Eclipse工程
Android Studio工程
android {
sourceSets {
main.jniLibs.srcDirs = ['libs']
}
}
为了使APP Crash堆栈的可读性更高,建议您配置符号表文件,更准确地定位问题:
Bugly支持手动和自动配置两种方式,具体的配置方法请参考:《Bugly Android符号表配置》
<uses-permission android:name="android.permission.READ_PHONE_STATE" />
<uses-permission android:name="android.permission.INTERNET" />
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
<uses-permission android:name="android.permission.ACCESS_WIFI_STATE" />
<uses-permission android:name="android.permission.READ_LOGS" />
-dontwarn com.tencent.bugly.**
-keep public class com.tencent.bugly.**{*;}
获取APP ID并将以下代码复制到项目Application类onCreate()中,Bugly会为自动检测环境并完成配置:
CrashReport.initCrashReport(getApplicationContext(), "注册时申请的APPID", false);
为了保证运营数据的准确性,建议不要在异步线程初始化Bugly。
第三个参数为SDK调试模式开关,调试模式的行为特性如下:
- 输出详细的Bugly SDK的Log;
- 每一条Crash都会被立即上报;
- 自定义日志将会在Logcat中输出。
建议在测试阶段建议设置成true,发布时设置为false。
此外,Bugly2.0及以上版本还支持通过“AndroidManifest.xml”来配置APP信息。如果同时又通过代码中配置了APP信息,则最终以代码配置的信息为准。
在“AndroidManifest.xml”的“Application”中增加“meta-data”配置项:
<application
-- 配置APP ID -->
<meta-data
android:name="BUGLY_APPID"
android:value="" />
<meta-data
android:name="BUGLY_APP_VERSION"
android:value="" />
<meta-data
android:name="BUGLY_APP_CHANNEL"
android:value="" />
<meta-data
android:name="BUGLY_ENABLE_DEBUG"
android:value="" />
application>
不同于“android:versionName”,“BUGLY_APP_VERSION”配置的是Bugly平台的APP版本号。
通过“AndroidManifest.xml”配置后的初始化方法如下:
CrashReport.initCrashReport(getApplicationContext());
Bugly默认从“AndroidManifest.xml”文件中读取“VersionName”作为版本号,自定义设置请使用参考“高级设置”。
如果App使用了多进程且各个进程都会初始化Bugly(例如在Application类onCreate()中初始化Bugly),那么每个进程下的Bugly都会进行数据上报,造成不必要的资源浪费。
因此,为了节省流量、内存等资源,建议初始化的时候对上报进程进行控制,只在主进程下上报数据:判断是否是主进程(通过进程名是否为包名来判断),并在初始化Bugly时增加一个上报进程的策略配置。
Context context = getApplicationContext();
// 获取当前包名
String packageName = context.getPackageName();
// 获取当前进程名
String processName = getProcessName(android.os.Process.myPid());
// 设置是否为上报进程
UserStrategy strategy = new UserStrategy(context);
strategy.setUploadProcess(processName == null || processName.equals(packageName));
// 初始化Bugly
CrashReport.initCrashReport(context, "注册时申请的APPID", isDebug, strategy);
// 如果通过“AndroidManifest.xml”来配置APP信息,初始化方法如下
// CrashReport.initCrashReport(context, strategy);
其中获取进程名的方法“getProcessName”有多种实现方法,推荐方法如下:
/**
* 获取进程号对应的进程名
*
* @param pid 进程号
* @return 进程名
*/
private static String getProcessName(int pid) {
BufferedReader reader = null;
try {
reader = new BufferedReader(new FileReader("/proc/" + pid + "/cmdline"));
String processName = reader.readLine();
if (!TextUtils.isEmpty(processName)) {
processName = processName.trim();
}
return processName;
} catch (Throwable throwable) {
throwable.printStackTrace();
} finally {
try {
if (reader != null) {
reader.close();
}
} catch (IOException exception) {
exception.printStackTrace();
}
}
return null;
}
现在您可以制造一个Crash(建议通过“按键”来触发),来体验Bugly的能力了。在初始化Bugly的之后,调用Bugly测Java Crash接口。
CrashReport.testJavaCrash();
执行到这段代码时会发生一个Crash,Logcat的TAG=CrashReportInfo中输出为:
现在您已经可以在“崩溃”页面看到刚才触发的Crash issue了(延迟一般在10s以内)。
如果项目包含了Native工程或者使用了代码混淆,建议配置符号表文件。
我们提供了UserStrategy类作为Bugly的初始化扩展,在这里您可以修改本次初始化Bugly数据的版本、渠道及部分初始化行为。通过以下方式传入:
UserStrategy strategy = new UserStrategy(appContext);
//...在这里设置strategy的属性,在bugly初始化时传入
//...
CrashReport.initCrashReport(appContext, APPID, true, strategy);
如果通过UserStrategy设置了版本号和渠道号,则会覆盖“AndroidManifest.xml”里面配置的版本号和渠道。
Bugly默认读取AndroidManifest.xml文件中VersionName、Package信息。若您有自己的版本或渠道设定需求,可通过该接口修改。
strategy.setAppChannel("myChannel"); //设置渠道
strategy.setAppVersion("1.0.1"); //App的版本
strategy.setAppPackageName("com.tencent.xx"); //App的包名
Bugly会在启动10s后联网同步数据。若您有特别需求,可以修改这个时间。
strategy.setAppReportDelay(20000); //改为20s
自定义标签,用于标明App的某个“场景”。在发生Crash时会显示该Crash所在的“场景”,以最后设置的标签为准,标签id需大于0。例:当用户进入界面A时,打上9527的标签:
CrashReport.setUserSceneTag(context, 9527); // 上报后的Crash会显示该标签
打标签之前,需要在Bugly产品页配置中添加标签,取得标签ID后在代码中上报。
自定义Map参数可以保存发生Crash时的一些自定义的环境信息。在发生Crash时会随着异常信息一起上报并在页面展示。
CrashReport.putUserData(context, "userkey", "uservalue");
最多可以有9对自定义的key-value(超过则添加失败),key限长50字节、value限长200字节,过长截断。
在开发测试阶段,可以在初始化Bugly之前通过以下接口把调试设备设置成“开发设备”。
CrashReport.setIsDevelopmentDevice(context, true);
ADT 17增加了BuildConfig特性,可以通过获取BuildConfig类的DEBUG变量来设置:
CrashReport.setIsDevelopmentDevice(context, BuildConfig.DEBUG);
Bugly Android SDK 1.2.8及以上版本提供了Javascript的异常捕获和上报能力,以便开发者可以感知到 WebView中发生的Javascript异常。
/**
* 设置Javascript的异常监控
*
* @param webView 指定被监控的webView
* @param autoInject 是否自动注入Bugly.js文件
* @return true 设置成功;false 设置失败
*/
CrashReport.setJavascriptMonitor(WebView webView, boolean autoInject)
建议在WebChromeClient的onProgressChanged函数中调用接口:
CrashReport.setJavascriptMonitor(webView, true);
例子如下:
WebView webView = new WebView(this);
// 设置WebChromeClient
webView.setWebChromeClient(new WebChromeClient() {
@Override
public void onProgressChanged(WebView webView, int progress) {
// 增加Javascript异常监控
CrashReport.setJavascriptMonitor(webView, true);
super.onProgressChanged(webView, progress);
}
});
// 加载HTML
webView.loadUrl(url);
<html>
<script src="bugly.js" >script>
<body>
...
body>
html>
WebView webView = new WebView(this);
// 加载HTML
webView.loadUrl(url);
// 增加Javascript异常监控
CrashReport.setJavascriptMonitor(webView, false);
在Bugly Android SDK捕获到Javascript异常后,默认会上报以下信息:
- Android设备的相关信息;
- Javascript异常堆栈和其他信息;
- Java堆栈;
- WebView的信息,目前只包括ContentDescription。
我们提供了一些信息记录API供您补充额外的内容。这些信息会随着异常一起上报。例如App环境、用户属性等等。主要包含以下接口:
1、设置用户ID 您可能会希望能精确定位到某个用户的异常,我们提供了用户ID记录接口。 例:网游用户登录后,通过该接口记录用户ID,在页面上可以精确定位到每个用户发生Crash的情况。
CrashReport.setUserId("9527"); //该用户本次启动后的异常日志用户ID都将是9527
2、主动上报开发者Catch的异常 您可能会关注某些重要异常的Catch情况。我们提供了上报这类异常的接口。 例:统计某个重要的数据库读写问题比例。
try {
//...
} catch (Throwable thr) {
CrashReport.postCatchedException(thr); // bugly会将这个throwable上报
}
3、自定义日志功能 我们提供了自定义Log的接口,用于记录一些开发者关心的调试日志,可以更全面地反应App异常时的前后文环境。使用方式与android.util.Log一致。用户传入TAG和日志内容。该日志将在Logcat输出,并在发生异常时上报。有如下
BuglyLog.v(tag, log)
BuglyLog.d(tag, log)
BuglyLog.i(tag, log)
BuglyLog.w(tag, log)
BuglyLog.e(tag, log)
注意:
为了更好得区分不同构建或者版本的SO文件以方便地管理Native代码,建议给SO文件加上独立的版本号或者UUID。
在任意一个源码文件(建议是专门控制版本相关信息的源码文件)中加入一行:
extern "C" const char SO_FILE_VERSION[] __attribute__ ((section (".bugly_version"))) = "
此后,NDK编译的SO文件将带有一个具有版本信息的段(.bugly_version)。之所以把段名 定义为“.bugly_version”,是为了Bugly的NDK解析的统一性。查看SO文件的版本号的一个方法如下(需要readelf或类似工具):
readelf -p .bugly_version libxxx.so
在“/build/core/import-locals.mk”文件的最后加上一行:
LOCAL_LDFLAGS += -Xlinker --build-id
此后,NDK构建的SO文件将带有一个段(.note.gnu.buildid)专门存放构建的UUID。查看SO文件的UUID的一个方法如下(需要readelf或类似工具):
readelf -x .note.gnu.build-id libxxx.so
其中“readelf”是GNU Binary Utilities一个工具,用于解析ELF格式文件(SO文件属于ELF格式文件)。Linux下默认安装了;Windows下可使用NDK提供的readelf(\toolchains\xxx\prebuit\windowsxxx\bin\xxxreadelf.exe)或者安装MinGW或者Cygwin;Mac下如果没有该工具,可从GNU Binary Utilities官网下载安装或者使用NDK提供的readelf。
Native堆栈例子如下图(UUID不在堆栈中显示):