Fabric如何区别debug和release版本

一. 方案一 利用Organization分别统计release和debug版信息

1. 创建两个Organization
2. 每个Organization都会生成一个apikey, 这样就可以根据buildTypes设置apiKey了
3. 在AndroidManifest.xml中使用placeHolder语法配置apiKey, 如下:

4. 然后在module下的build.gradle中根据buildTypes分别传递apiKey的值, /build.gradle 中的配置如下(其他配置略去):

android {
      buildTypes {
        debug {
            manifestPlaceholders = [fabric_apikey: "kdjflajfldjflkjaldfjedf3219ddkljdlfjaljfl"]
        }
        release {
            manifestPlaceholders = [fabric_apikey: "ldjflajflakddda35b6cljlkjldjfdjlkjadkfjdl"]
        }
      }
}

4. 重新构建你的App, 然后运行App, 这样你就可以在在Fabric的DashBoard中看到两个一样的应用, 但是它们属于不同的Organization

二. 方案二 利用不同的包名(即不同app)分别统计release和debug版信息

安卓中不同的报名表示不同的app, 因此这里可以利用这一特性来实现debug和release版的crash信息, 即debug版和release版分别有不同的包名.

1. 更改debug版的包名 (注意,更改后某些功能会用不了, 如微信分享. 因此这并非好的解决方案, 没有第一种解决方案好), 其他配置不变. 在/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'
        }
    }
}

2. 重新构建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) 在/build.gradle中配置ApiKey和Build Secret, build.gradle中的其他配置不变. AndroidManifest.xml中的apikey配置要删除掉, 自定义的Application中Fabric初始化的代码不变. 下面是在/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做的事情是, 跟新根目录下的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

五. 总结

1. 方案一和方案二都比较简单也容易理解, 确定是, 对apiSecret并未做相应处理.
2. 可以看到, 方案一和方案二中并未提到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