2014-11-29 5 views
5

Ho alcune versioni della mia app: versione comune, ad esempio mainapp e alcune build specifiche per cliente, ad esempio custom1, custom2, custom3. E voglio avere il sapore di base per tutti i gusti customX.Aroma di base Android senza duplice errore di classe

stavo cercando di fare in questo modo:

Creare struttura del progetto:

app\src\main 
app\src\mainapp 
app\src\commonflavor 
app\src\custom3 

E config:

productFlavors { 
    mainapp { 
    } 
    custom1 { 
    } 
    custom2 { 
    } 
    custom3 { 
    } 
} 

sourceSets { 
    custom1 { 
     java.srcDirs = ['src/commonflavor/java'] 
    } 
    custom2 { 
     java.srcDirs = ['src/commonflavor/java'] 
    } 
    custom3 { 
     java.srcDirs = ['src/commonflavor/java', 'src/custom3/java'] 
    } 
} 

In commonflavor ho messo classi Java comuni per tutti i sapori customX, dicono MainActivity.java e SecondActivity.java. Ma in custom3 ho bisogno di separare SecondActivity.java.

In questo caso, ho un errore error: duplicate class: SecondActivity da src/commonflavor/java e src/custom3/java.

Per ora ho risolto questo con classe dupllication:

sourceSets { 
    custom1 { 
     java.srcDirs = ['src/commonflavor/java'] 
    } 
    custom2 { 
     java.srcDirs = ['src/commonflavor/java'] 
    } 
    custom3 { 
     java.srcDirs = ['src/custom3/java'] 
    } 
} 

ho copiato da src/commonflavor/java srcDirs e copiare MainActivity.java a custom3. Il problema è che ho 2 clone di file MainActivity.java in src/commonflavor/java e src/custom3/java

Come risolvere questa situazione senza duplicazione del codice?

+0

ho il sospetto che non c'è bisogno per il set di 'commonflavor' fonte. Questi file potrebbero benissimo rimanere in 'src/main' ed essere ereditati di default da tutti gli aromi. –

risposta

2

La soluzione migliore quello che ho fondato è scrivere tutte le classi in app \ src \ principale e aggiungere se necessario:

if(BuildConfig.FLAVOR.equals("mainapp")) { 
    // mainapp code 
} else { 
    // coomon flavor code 
} 
+4

Sono un po 'preoccupato per questo approccio perché l'apk potrebbe essere decompilato e il 'FLAVOR' cambiato in' pro' facilmente. –

+4

Ma questo non aumenta la dimensione dell'apk poiché contiene tutti i file, ma quando si usa build tipo flavor, l'aroma indesiderato archiviato non verrà compilato e la dimensione dell'apk verrà ridotta. –

Problemi correlati