Gradle Swap jniLibs Ressourcen basierend auf Build-Geschmack

Question

Ich versuche, einige Ressourcen in der res/raw Ordner und die jniLibs/armeabi Ordner basierend darauf, ob es eine release buildType oder eine debug buildType Ordner zu tauschen. Ich habe derzeit auch zwei Produktaromen.

Die build.gradle Datei:

apply plugin: 'com.android.application' 

android { 
    dexOptions { 
     preDexLibraries = false 
    } 

    compileSdkVersion 21 
    buildToolsVersion "22.0.1" 

    defaultConfig { 
     applicationId "com.example.test" 
     minSdkVersion 17 
     targetSdkVersion 22 
     compileOptions { 
      sourceCompatibility JavaVersion.VERSION_1_7 
      targetCompatibility JavaVersion.VERSION_1_7 
     } 
    } 

    productFlavors{ 
     phone{ 
      applicationId "com.example.testPhone" 
     } 
     tablet{ 
      applicationId "com.example.testTablet" 
     } 
    } 

    buildTypes { 
     release { 
      minifyEnabled false 
      proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.txt' 
     } 
    } 

    sourceSets{ 
     release{ 
      res.srcDirs = ['androidRelease/res/raw'] 
     } 
    } 
} 

dependencies { 
    compile project(':facebook') 

} 

sourceSet der richtige Weg, dies zu tun verwendet? Wenn ja, welcher Ordner sollte erstellt werden, so dass er die entsprechenden Ressourcen nur basierend auf der buildType und unabhängig von der productFlavors vertauscht?

EDIT: Ist es sogar möglich, jniLibs und raw Ordner Ressourcen auszutauschen?

Ordnerstruktur:

src/main/jniLibs/armeabi 
phoneRelease/jniLibs/armeabi 
tabletRelease/jniLibs/armeabi 

die Ordnerstruktur korrekt.?

EDIT 2: Basierend auf Xaviers Antwort sollte die gradle wie folgt aussehen:

android { 

     sourcesets { 
     phone { 
      jniLibs.srcDirs = ['phoneRelease/jniLibs/'] 
      res.srcDirs = ['androidRelease/res/raw'] 
     } 
     tablet { 
      jniLibs.srcDirs = ['tabletRelease/jniLibs/'] 
      res.srcDirs = ['androidRelease/res/raw'] 
     } 
     } 
    } 

ich viele widersprüchliche Antworten lesen Sie erwähnen einige von ihnen, dass Sie separate Ordner müssen nur anhand von Build-Variante und einige Erwähnen Sie, dass Sie sourceSet verwenden müssen? Danke!

Answer 1

einige von ihnen erwähnen, dass Sie separate Ordner müssen nur auf Basis von Build-Variante und einige Erwähnung über sourceSet verwenden?

Gradle/Gradle für Android hat eine erwartete Struktur für eine sourceSet:

• Android Ressourcen in res/
• Java-Source-Tree in java/
• vorkompilierte JNI Bibliotheken in jniLibs/
• Assets in assets/
• Etc.

Wo die sourceSets Schließung ins Spiel kommt, wenn für eine bestimmte sourceSet, mögen Sie eine andere Struktur:

• Android Ressourcen in foo/
• Java-Source-Tree in bar/
• Pre -kompilierte JNI-Bibliotheken in ickyNativeStuff/
• Assets in assetsBecauseThatSeemsLikeADecentName/
• usw.

Jeder Buildtyp, Produktgeschmack, und bauen Variante kann eine separate sourceSet haben (wie kann androidTest für die Instrumentierung Prüfung), mit main zu gehen. Sie haben den gleichen Namen wie die Build-Typ/Produkt-Flavor/Build-Variante. Diese werden in der Bestandsstruktur sein, es sei denn, Sie verwenden sourceSets, um Dinge zu ändern.

So, den ganzen Weg zu rollen zurück zu:

Ich versuche, einige Ressourcen in der res/raw-Ordner und der jniLibs/armeabi Ordner basierend darauf, ob seine eine Freigabe buildType oder einem Debug-buildType zu tauschen

Bei Ressourcen überschreiben andere Quellgruppen main. Also, wenn Sie haben src/main/res/... und src/main/debug/... und src/main/release/..., und Sie machen einen debug zu bauen, was auch immer in src/main/release/... ist wird ignoriert (da wir nicht release tun) und was auch immer in src/main/res/... und src/main/debug/... verwendet. Wenn es in beiden die gleiche Ressource gibt (src/main/res/raw/boom.ogg und src/debug/res/raw/boom.ogg), übertrumpft die debug die main.

Ich habe nicht mit variierenden jniLibs/ von Build-Variante experimentiert. Meine Vermutung ist, dass es sich mehr wie Java-Code verhält, wo es keine Konflikte zwischen dem, was in einem Build-Variante-Quellcode und was in main ist, haben kann, aber das ist nur eine Vermutung. So können Sie die Debug-Version Ihres kompilierten JNI-Codes in src/debug/jniLibs/ und die Release-Version Ihres kompilierten JNI-Codes in src/release/jniLibs/ haben. Nur in src/main/jniLibs/ haben alle Bibliotheken, die nicht variieren. Wie gesagt, ich habe das nicht versucht, und so kann es hier zu Schluckauf kommen.

Also, ich würde erwarten, dass Sie keine sourcesets Schließung in build.gradle haben, und nur die Struktur stock sourcesets zu verwenden, für Ihre verschiedenen Bits:

src/ 
    main/ 
    ... 
    debug/ 
    jniLibs/ 
    res/ 
     raw/ 
    release 
    jniLibs/ 
    res/ 
     raw/ 

Answer 2

Aromen zu verwenden Quelle Sätze zu variieren,

productFlavors{ 
    phone{ 
    } 
    tablet{ 
    } 
} 

Jetzt Ihren Code strukturieren wie,

src 
    main 
    phone 
    tablet 

Der Code in main ist üblich, zwischen den beiden Geschmacksrichtungen, aber der Code in phone oder tablet ist nur enthalten, wenn der jeweilige Geschmack aufgebaut ist. Das ist es, du musst nichts anderes tun.

Die Struktur unter phone und tablet ist die gleiche wie unter main (res, java, etc). Sie können auch eine benutzerdefinierte AndroidManifest.xml unter dem Flavor-Verzeichnis haben. Gradle versucht, die AndroidManifest.xml des Aromas mit der in main zu verschmelzen. In einigen Fällen müssen Sie Regeln für die Zusammenführung angeben.

Answer 3

Alles, was normalerweise unter src/main/ ist in einem anderen Ordner abgelegt werden:

src/<element>/AndroidManifest.xml 
src/<element>/java 
src/<element>/res 
src/<element>/assets 
src/<element>/resources 
src/<element>/jni 
src/<element>/jniLibs 
src/<element>/aidl 
src/<element>/rs 

Wo element ist der Name eines build type oder product flavor. Wenn Sie Ihre Variante ein solches Element enthält (Build-Typ oder Aroma), dann ist das Quellsatz wird auch zusätzlich-src/main

Beachten Sie, dass die Lage ist wirklich nicht relevant verwendet, wenn Sie es konfiguriert haben. Was zählt ist, dass es ein android.sourcesets.main Element gibt, das die für alle Varianten gemeinsamen Quellen enthält, und jede Variante hat eine Reihe von Quellgruppen.wenn Sie

Zum Beispiel haben einen Geschmack phoneRelease es wirklich die folgenden sourcesets mit:

android.sourcesets.main 
android.sourcesets.phone 
android.sourcesets.release 
android.sourcesets.phoneRelease 

Wenn Sie eine andere Variante tabletRelease haben, wird es verwenden, um die folgenden:

android.sourcesets.main 
android.sourcesets.tablet 
android.sourcesets.release 
android.sourcesets.phoneRelease 

So die phone/tablet Quellsatz ist anders und ist, wo Sie die Variante spezifische Quellen setzen würden, es sei denn, Sie möchten noch spezifischer sein und verwenden Sie die phoneRelease/tabletRelease Quellsätze (obwohl diese im Allgemeinen weniger verwendet werden.) Standardmäßig wären dies src/phone/... und src/tablet/... (oder src/phoneRelease/...) aber Sie können das ändern, wie Sie wollen und solange es mit den android.sourcesets.* Objekten verbunden ist, wird es in Ordnung sein.

zum Beispiel tun:

android { 
    sourcesets { 
    phone { 
     jniLibs.srcDirs = ['phoneRelease/jniLibs/'] 
    } 
    tablet { 
     jniLibs.srcDirs = ['tabletRelease/jniLibs/'] 
    } 
    } 
} 

ist in Ordnung. Aber beachten Sie, dass Sie nur den jniLibs Ordner geändert und nicht die anderen Quellenelemente (java, res, etc ...)

Wenn Sie den Standardordner für die main sourcesets gehalten, würde ich einfach alles halten unter src/

können Sie weitere Informationen über sourcesets sehen und wie mehrere sourcesets kombiniert sind hier: http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Sourcesets-and-Dependencies