android - apikey - Crashlytics(Fabric) separa a las organizaciones para las variantes de aplicación(tipos de compilación, versiones de producto)

io fabric apikey

Question

Esta es una pregunta auto respondida para compartir mi conocimiento.

Tengo un proyecto con varios tipos de productos y quiero integrar Fabric utilizando organizaciones separadas para cada producto.

Intenté integrar Fabric usando Android Studio Fabric Plugin. Agrega

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

entrada a AndroidManifest.xml del conjunto fuente main .

Decidí volver a escribir esta entrada en los conjuntos de fuente específicos de la variante de la aplicación:

<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>

Luego descubrí que el complemento Fabric Gradle genera el archivo crashlytics.properties con la API de la estructura (también conocido como construcción secreta) durante la compilación y debería incluir este archivo en el control de código fuente. Pero este archivo se sobrescribe cada vez que construyo una variante específica de la aplicación porque el secreto de la API es único para cada aplicación.

¿Cómo puedo integrar Fabric utilizando organizaciones separadas para cada variante de aplicación?

Answer 1

Durante la compilación, la tarea fabricGenerateResources se llama y busca un archivo llamado fabric.properties con el siguiente contenido:

apiSecret=YOUR_BUILD_SECRET
apiKey=YOUR_API_KEY

Así que todo lo que necesitamos es generar el archivo fabric.properties antes de esto.

Encontré esta solución y la modifiqué ligeramente para admitir completamente las variantes de la aplicación, no solo los tipos de compilación.

Agrega este código a la sección de android de build.gradle :

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()
}
}
}

Se itera sobre las variantes de la aplicación y para cada variante de la aplicación crea la tarea que genera el archivo fabric.properties y la tarea que elimina este archivo después de que el complemento Fabric Gradle genere los recursos de la aplicación.

Todo lo que necesita ahora es definir el sabor del producto o construir el tipo específico de fabricApiKey y fabricApiSecret :

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

ext es un objeto ExtraPropertiesExtention proporcionado por cada objeto ExtensionAware . Permite agregar nuevas propiedades al objeto existente. En mi caso, flavor1 es un objeto ExtensionAware y puede extenderse con nuevas propiedades mediante el uso de la ext.someProperty = "value" y, posteriormente, estas propiedades se pueden usar como flavor.someProperty, flavor.fabricApiKey .

También es mejor incluir fabric.properties a .gitignore .

Y no olvide eliminar ext.enableCrashlytics = false del tipo de compilación de depuración si lo usó para deshabilitar Crashlytics durante la depuración. En lugar de esto, puede deshabilitarlo en Application.onCreate :

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

Answer 2

Si no se opone a usar un sufijo de ID de aplicación, no necesita organizaciones separadas. Los fallos y las respuestas se tratarán como aplicaciones separadas.

Por ejemplo, digamos que mi ID de aplicación es io.example

En tu build.gradle:

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

Después de implementar la versión de depuración en un dispositivo o emulador, en el sitio de Fabric verá dos aplicaciones:

• io.example
• io.example.debug

Una cosa que es agradable de este enfoque es que también puede realizar un seguimiento de otros sabores de compilación por separado: io.exmaple.free , io.exmaple.paid , io.example.exterprise , y así sucesivamente.