一. 方案一 利用Organization分别统计release和debug版信息
- 创建两个
Organization - 每个
Organization都会生成一个apikey, 这样就可以根据buildTypes设置apiKey了 - 在AndroidManifest.xml中使用placeHolder语法配置apiKey, 如下:
<meta-data
android:name="io.fabric.ApiKey"
android:value="${fabric_apikey}" />
- 然后在module下的build.gradle中根据buildTypes分别传递apiKey的值,
<module>/build.gradle中的配置如下(其他配置略去):
android {
buildTypes {
debug {
manifestPlaceholders = [fabric_apikey: "kdjflajfldjflkjaldfjedf3219ddkljdlfjaljfl"]
}
release {
manifestPlaceholders = [fabric_apikey: "ldjflajflakddda35b6cljlkjldjfdjlkjadkfjdl"]
}
}
}
- 重新构建你的App, 然后运行App, 这样你就可以在在Fabric的DashBoard中看到两个一样的应用, 但是它们属于不同的
Organization
二. 方案二 利用不同的包名(即不同app)分别统计release和debug版信息
安卓中不同的报名表示不同的app, 因此这里可以利用这一特性来实现debug和release版的crash信息, 即debug版和release版分别有不同的包名.
- 更改debug版的包名 (注意,更改后某些功能会用不了, 如微信分享. 因此这并非好的解决方案, 没有第一种解决方案好), 其他配置不变. 在
<module>/build.gradle中更改buildTypes, 只要在debug块中添加applicationIdSuffix ".debug"即可, 如下(不相干的配置已经略去):
android {
buildTypes {
debug {
applicationIdSuffix ".debug"
versionNameSuffix "_debug"
debuggable true
jniDebuggable true
}
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
- 重新构建app, 运行app, 这时在Fabric的DashBoard中就可以看到两个app啦, 这两个app属于同一个
Organization
三. 方案三 (方案一的变种), 原理跟方案一相同:
给不同的buildTypes分别设置
ApiKey和Build Secret------ 由于每个Organization只有一个ApiKey和Build Secret, 因此必须创建两个Organization, 一个用于debug版本另一个用于release版本. debug和release版本的app分别属于两个不同的Organization中.
- (1) 创建两个
Organization, 生成两对ApiKey和Build Secret. - (2) 在
<module>/build.gradle中配置ApiKey和Build Secret, build.gradle中的其他配置不变.AndroidManifest.xml中的apikey配置要删除掉, 自定义的Application中Fabric初始化的代码不变. 下面是在<module>/build.gradle中配置ApiKey和Build Secret的代码(不相干的代码已经略去):
import com.crashlytics.tools.utils.PropertiesUtils
android {
buildTypes {
debug {
debuggable true
jniDebuggable true
ext.crashlyticsApiSecret = "2ec50395441105dc70b09ca22f10a5b497bb34c029f129d926ead14a064ddc52"
ext.crashlyticsApiKey = "7c0d68ae3486cf62f5388fe48217db4462cd147b"
}
release {
minifyEnabled false
signingConfig signingConfigs.release
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
ext.crashlyticsApiSecret = "a3f046bf5190a68e229986799d6835076faf772f5aca94acdc3eac08ff10062b"
ext.crashlyticsApiKey = "146c08aee1c528209a558a071477608bed71daa1"
}
}
//这段代码必须在android块的最末端
File crashlyticsProperties = new File("${project.projectDir.absolutePath}/fabric.properties")
android.applicationVariants.all { variant ->
def variantSuffix = variant.name.capitalize()
def generateResourcesTask = project.tasks.getByName("fabricGenerateResources${variantSuffix}")
def generatePropertiesTask = task("fabricGenerateProperties${variantSuffix}") << {
Properties properties = new Properties()
println "...copying apiSecret for ${variant.name}"
properties.put("apiSecret", variant.buildType.ext.crashlyticsApiSecret)
println "...copying apiKey for ${variant.name}"
properties.put("apiKey", variant.buildType.ext.crashlyticsApiKey)
PropertiesUtils.injectPropertyInFile(crashlyticsProperties, properties, "")
}
generateResourcesTask.dependsOn generatePropertiesTask
}
}
这段代码的大概意思: 给fabricGenerateResources${variant.name}添加类一个依赖的task. 这个依赖的task做的事情是, 跟新<module>根目录下的fabric.properties文件中的内容, 即重新写入如下内容:
#
#Mon Sep 05 19:45:00 CST 2016
apiSecret=329046bf5190a68e22lsiz6799d6835076faf772f5aca94acdc3eaajldf10062
apiKey=0219a8awkzc528209a55akz71477608bed71d01zkd
其中apiSecret(即Build Secret)和apiKey的值, 是从buildTypes中获取的. fabricGenerateResources${variant.name}这个task应该是fabric插件定义的, 这个task执行的时候会从fabric.properties文件中获取apiKey和apiSecret的值, 因此要在fabricGenerateResources${variant.name}这个task之前更新apikey和apiSecret的值, 即fabricGenerateResources${variant.name}依赖与一个更新fabric.properties中的值的task.
- (3) 分别构建debug和relase版的app, 启动app, 这时候你就可以在Fabric的DashBoard中看到两个app, 分别是debug版和release版.
四. 为了更好的理解Fabric中的各种概念 (Account/Organizations/Members/Apps/ApiKey/Build Secret) , 我绘制了一张各种概念的结构关系图, 如下:
Fabric中各种概念的关系图.png
五. 总结
- 方案一和方案二都比较简单也容易理解, 确定是, 对apiSecret并未做相应处理.
- 可以看到, 方案一和方案二中并未提到apiSecret, 其实fabric.properties文件中的apiSecret无论填的是debug的还是release的, 都不影响crash信息的收集 (测试可行 !), 因此并未对apiSecret做相应的处理.
第三种方案对apiSecret做了相应的处理, 这样就不怕因为apiSecret未做相应处理而导致各种问题, 因此这是最好的解决方案. 但是此方案比较复杂且有一定的理解难度. 我们必须对fabric插件有一定的了解. fabric的插件并没有源代码, 因此要搞懂fabric内部运行原理就非常困难 (可以用JD-GUI反编译jar包插件源码, 但是源码读起来非常吃力), 而且如果fabric插件的实现方式发生变化, 就有可能导致这种方案无法正常工作. 这些都是这种方案的不足之处.
如果不太清楚Fabric的用法, 请参考我前一篇《Fabric用法》
或 官网相关文档 https://docs.fabric.io/android/fabric/overview.html
References：
https://www.fabric.io
https://gist.github.com/alexsinger/2b5b1b7ae2d2fca1ffdb
网友评论