一. 方案一 利用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) , 我繪制了一張各種概念的結構關系圖, 如下:
五. 總結
- 方案一和方案二都比較簡單也容易理解, 確定是, 對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
