Crashlytics (tessuto) organizzazioni separate per le varianti applicative (costruzione tipi, sapori di prodotti)

Question

Questo è questione di auto-risposta condividere la mia conoscenza.

Ho un progetto con più gusti di prodotto e desidero integrare Fabric utilizzando organizzazioni separate per ciascun gusto del prodotto.

Ho provato a integrare Fabric utilizzando Android Studio Fabric Plugin. Si aggiunge

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

ingresso AndroidManifest.xml di main Imposta origine.

ho deciso di riscrivere questa voce in set fonte specifica variante di applicazione:

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

Poi ho scoperto che in tessuto Gradle plug genera crashlytics.properties file con segreto tessuto api (AKA costruire segreta) durante la costruzione e dovrebbe includere questo file al controllo del codice sorgente. Ma questo file viene sovrascritto ogni volta che costruisco una variante specifica dell'applicazione perché l'API segreto è univoco per ogni applicazione.

Come posso integrare Fabric utilizzando organizzazioni separate per ogni variante di applicazione?

Answer 1

Durante l'operazione di compilazione fabricGenerateResources si chiama e cerca un file chiamato fabric.properties con seguente contenuto:

apiSecret=YOUR_BUILD_SECRET 
apiKey=YOUR_API_KEY 

Quindi tutti abbiamo bisogno è di generare fabric.properties file prima di questo.

ho trovato this solution e leggermente modificato per supportare pienamente applicazione varianti non solo costruire tipi.

aggiungere questo codice android sezione del 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() 
     } 
    } 
} 

Si itera su varianti di applicazione e per ogni variante applicazione crea compito che genera fabric.properties file e il compito che elimina questo file dopo Tessuto Gradle plug genera risorse dell'applicazione.

Tutto ciò che serve ora è quello di definire il sapore del prodotto o tipo specifico fabricApiKey e fabricApiSecret costruire:

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

ext è un oggetto ExtraPropertiesExtention fornito da ogni oggetto ExtensionAware. Permette di aggiungere nuove proprietà all'oggetto esistente. Nel mio caso è flavor1ExtensionAware oggetto e può essere esteso con nuove proprietà utilizzando ext.someProperty = "value" sintassi e poi queste proprietà possono essere utilizzati come flavor.someProperty, flavor.fabricApiKey.

Inoltre è meglio includere fabric.properties-.gitignore.

E non dimenticare di rimuovere ext.enableCrashlytics = false dal tipo di build di debug se lo hai usato per disabilitare Crashlytics durante il debug.Invece di questo si può disattivare in Application.onCreate:

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

Answer 2

Se non sei invece di utilizzare un suffisso applicazione id, non occorre organizzazioni separate. Gli arresti anomali e le risposte saranno trattati come app separate.

Per esempio, diciamo che la mia domanda id è io.example

Nel vostro build.gradle:

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

Dopo aver distribuito la versione di debug a un dispositivo o un emulatore, sul sito di tessuto si vedrà due applicazioni:

• io.example
• io.example.debug

Una cosa che è bella di questo approccio è che si può anche tenere traccia di altri sapori costruire seprately: io.exmaple.free, io.exmaple.paid, io.example.exterprise, e così via.