web-dev-qa-db-ja.com

Crashlytics(Fabric)は、アプリケーションバリアント(ビルドタイプ、製品フレーバー)のために組織を分けています

これは私の知識を共有するための自己回答型の質問です。

複数の製品フレーバーを持つプロジェクトがあり、製品フレーバーごとに別々の組織を使用してファブリックを統合したいと考えています。

Android Studio Fabric Pluginを使用してFabricを統合しようとしました。

<meta-data
    Android:name="io.fabric.ApiKey"
    Android:value="DEFAULT_ORGANIZATION_API_KEY" />

mainソースセットのAndroidManifest.xmlへのエントリ。

アプリケーションバリアント固有のソースセットでこのエントリを書き換えることにしました。

<manifest xmlns:Android="http://schemas.Android.com/apk/res/Android"
    xmlns:tools="http://schemas.Android.com/tools">

    <application>
        <meta-data
            Android:name="io.fabric.ApiKey"
            Android:value="SECOND_ORGANIZATION_API_KEY"
            tools:replace="Android:value" />
    </application>
</manifest>

次に、Fabric Gradleプラグインがビルド中にファブリックAPIシークレット(別名ビルドシークレット)を含むcrashlytics.propertiesファイルを生成することを発見しました。このファイルをソース管理に含める必要があります。ただし、APIシークレットはアプリケーションごとに一意であるため、特定のアプリケーションバリアントをビルドするたびにこのファイルが上書きされます。

アプリケーションバリアントごとに別々の組織を使用してファブリックを統合するにはどうすればよいですか?

32
mixel

ビルド中にfabricGenerateResourcesタスクが呼び出され、次の内容のfabric.propertiesという名前のファイルを探します。

apiSecret=YOUR_BUILD_SECRET
apiKey=YOUR_API_KEY

したがって、必要なのは、この前にfabric.propertiesファイルを生成することだけです。

私は この解決策 を見つけ、ビルドタイプだけでなくアプリケーションバリアントを完全にサポートするように少し修正しました。

このコードをbuild.gradleAndroidセクションに追加します。

File crashlyticsProperties = new File("${project.projectDir.absolutePath}/fabric.properties")
applicationVariants.all { variant ->
    variant.productFlavors.each { flavor ->
        def variantSuffix = variant.name.capitalize()
        def generatePropertiesTask = task("fabricGenerateProperties${variantSuffix}") << {
            Properties properties = new Properties()
            properties.put("apiKey", flavor.fabricApiKey)
            properties.put("apiSecret", flavor.fabricApiSecret)
            properties.store(new FileWriter(crashlyticsProperties), "")
        }

        def generateResourcesTask = project.tasks.getByName("fabricGenerateResources${variantSuffix}")
        generateResourcesTask.dependsOn generatePropertiesTask
        generateResourcesTask.doLast {
            println "Removing fabric.properties"
            crashlyticsProperties.delete()
        }
    }
}

アプリケーションバリアントを反復処理し、アプリケーションバリアントごとに、fabric.propertiesファイルを生成するタスクと、Fabric Gradleプラグインがアプリケーションリソースを生成した後にこのファイルを削除するタスクを作成します。

ここで必要なのは、製品のフレーバーまたはビルドタイプ固有のfabricApiKeyおよびfabricApiSecretを定義することだけです。

productFlavors {
    flavor1 {
        ext.fabricApiKey = "FLAVOR1_API_KEY"
        ext.fabricApiSecret = "FLAVOR1_API_SECRET"
    }
}

extExtraPropertiesExtention オブジェクトであり、すべての ExtensionAware オブジェクトによって提供されます。新しいプロパティを既存のオブジェクトに追加できます。私の場合、flavor1ExtensionAwareオブジェクトであり、ext.someProperty = "value"構文を使用して新しいプロパティで拡張でき、後でこれらのプロパティをflavor.someProperty, flavor.fabricApiKeyとして使用できます。

また、fabric.properties.gitignoreを含めることをお勧めします。

また、デバッグ中にCrashlyticsを無効にするために使用した場合は、デバッグビルドタイプからext.enableCrashlytics = falseを削除することを忘れないでください。これの代わりに、Application.onCreateで無効にすることができます。

Fabric.with(this, new Crashlytics.Builder().core(
    new CrashlyticsCore.Builder().disabled(BuildConfig.DEBUG).build()).build());
27
mixel

アプリケーションIDのサフィックスを使用することに反対がない場合は、別個の組織は必要ありません。クラッシュと回答は別のアプリとして扱われます。

たとえば、私のアプリケーションIDがio.example

あなたのbuild.gradleで:

buildTypes {
  debug {
    applicationIdSuffix ".debug"
  }
  release {
    //options
  }
}

デバッグバージョンをデバイスまたはエミュレーターにデプロイすると、Fabricサイトに2つのアプリが表示されます。

  • io.example
  • io.example.debug

このアプローチの良い点の1つは、他のビルドフレーバーを個別に追跡できることです:io.exmaple.freeio.exmaple.paidio.example.exterprise、 等々。

7
Dave Jensen

Gradle 5.x +とも互換性のあるより簡単なソリューションは、固有のファブリックAPIキーとシークレットを必要とするビルドバリアントごとに個別のfabric.propertiesファイルを作成することです。 fabric.propertiesファイルを次のように作成します。

#Contains API Secret used to validate your application. Commit to internal source control; avoid making secret public.
apiSecret=YOUR_API_SECRET
apiKey=YOUR_API_KEY

YOUR_API_SECRETをビルドバリアントのAPIシークレットで置き換え、YOUR_API_KEYをビルドバリアントのAPIキーで置き換えます。

次に、各バリアントのfabric.propertiesをプロジェクトsrc/variantフォルダの下に配置します。 app/src/debugまたはapp/src/releaseドキュメントを参照 追加の詳細については、ビルドバリアントについて。

ビルド時には、ビルドされるバリアントのfabric.propertiesが使用されます。

0
Jeff Lockhart