Gradle scambia risorse jniLibs basate sul sapore di compilazione

Sto provando a scambiare alcune risorse nella cartella res/raw e nella cartella jniLibs/armeabi base a se è un release buildType o un debug buildType . Attualmente ho due sapori di prodotto.

Il file build.gradle:

  • libgdx android fallito al lancio
  • Imansible analizzare l'errore "Class" di model each volta che cerco di aprire una nuova class java
  • Android Studio non installa l'ultima applicazione sul dispositivo
  • API V2 di Google Maps 'Imansible caricare la mappa. Imansible contattare il server di Google
  • Memorizzazione con OkHttp (senza retrofit)
  • Permesso di scrivere su SD card android
  •  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') } 

    Utilizza sourceSet il modo giusto per farlo? In caso affermativo, quale cartella deve essere creata in modo da scambiare le risorse appropriate in base al tipo buildType e indipendentemente dai prodottiFlavors?

    EDIT: È anche ansible scambiare jniLibs e risorse di cartelle raw ?

    Struttura della cartella:

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

    La struttura della cartella è corretta.?

    EDIT 2: Sulla base della risposta di Xavier dovrebbe essere la gradella:

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

    Continuo a leggere tante risposte in conflitto, alcune di esse menzionano che hai bisogno solo di cartelle separate basate sulla variante di costruzione e qualche menzione di wherer utilizzare sourceSet ? Grazie!

  • Cluster di Android e clic del marcatore
  • Come posso impostare il colore della stella della barra di valutazione?
  • Invia messaggio da indossabile al telefono e poi immediatamente rispondere
  • Mostra tastiera soft anche se è collegata una tastiera hardware
  • Modificare il pacchetto predefinito da com.example per i progetti Android Eclipse
  • Android Beam - trasferimento di payload da entrambi i dispositivi solo quando si tocca il bundle?
  • 3 Solutions collect form web for “Gradle scambia risorse jniLibs basate sul sapore di compilazione”

    alcuni di loro menzionano che hai bisogno solo di cartelle separate basate sulla variante di costruzione e qualche menzione di wherer utilizzare sourceSet?

    Gradle / Gradle per Android ha una struttura prevista per un sourceet:

    • Risorse Android in res/
    • Albero di origine Java in java/
    • Librerie JNI pre-compilate in jniLibs/
    • Attività in assets/
    • Eccetera.

    Dove si sourceSets chiusura di sourceSets è se, per una determinata sorgente, si desidera una struttura diversa :

    • Risorse Android in foo/
    • Albero di origine Java in bar/
    • Librerie pre-compilate JNI in ickyNativeStuff/
    • Attività in assetsBecauseThatSeemsLikeADecentName/
    • Eccetera.

    Ogni tipo di build, il sapore del prodotto e la variante di creazione possono avere una sorgente separata (come può essere androidTest per test di strumentazione), per andare avanti con la main . Sono denominati lo stesso tipo di build type / product flavor / build. Questi saranno nella struttura di riserva, a less che non si utilizzino i sourceSets per cambiare le cose.

    Quindi, scorrere fino a:

    Sto provando a scambiare alcune risorse nella cartella res / raw e la cartella jniLibs / armeabi in base a se è un buildType di rilascio o un buildType di debug

    Nel caso delle risorse, altre sorgenti sovrappongono la main . Quindi, se hai src/main/res/... e src/main/debug/... e src/main/release/... , e stai facendo una creazione di debug , qualunque sia in src/main/release/... viene ignorato (poichè non facciamo il release ) e tutto ciò che è in src/main/res/... e sarà utilizzato src/main/debug/... Se esiste la stessa risorsa in entrambi ( src/main/res/raw/boom.ogg e src/debug/res/raw/boom.ogg ), il debug src/debug/res/raw/boom.ogg quello main .

    Non ho sperimentato vari jniLibs/ da variante di costruzione. La mia ipotesi è che si comporterà più come il codice Java, in cui non si può avere conflitti tra quello che è in una sorgente di una variante di costruzione e ciò che è nella main , ma è solo un'idea. Quindi, puoi avere la versione di debug del codice JNI compilato in src/debug/jniLibs/ e la versione di rilascio del codice JNI compilato in src/release/jniLibs/ . Solo nelle src/main/jniLibs/ tutte le librerie che non variano. Detto questo, come ho detto, non ho provato questo, e quindi ci possono essere singhiozze qui.

    Quindi, mi aspetto che non hai una chiusura delle sourcesets in build.gradle e utilizzi semplicemente la struttura delle sorgenti di riserva per i tuoi diversi bit:

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

    Tutto ciò che è normalmente sotto src/main/ può essere inserito in una cartella diversa:

     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 

    Dove element è il nome di un build type o di un product flavor . Se la tua variante include un elemento (tipo di build o flavor), allora viene utilizzata anche quella sorgente in aggiunta a src/main

    Tieni presente che la posizione è veramente non rilevante se l'hai configurato. Ciò che conta è che esiste un elemento android.sourcesets.main che contiene le fonti comuni a tutte le varianti e each variante ha un insieme di sorgenti.

    Ad esempio se hai un sapore phoneRelease utilizza veramente le seguenti sorgenti:

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

    Se hai un'altra variante tabletRelease , utilizzerai quanto segue:

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

    Quindi le sorgenti di phone / tablet sono diverse e è where si potrebbe mettere la variante fonti specifiche, a less che non si desideri essere ancora più specifiche e utilizzare le phoneRelease / tabletRelease (anche se quelle sono less utilizzate in genere.) Per impostazione predefinita tali sarebbero src/phone/... e src/tablet/... (o src/phoneRelease/... ) ma puoi cambiare ciò che vuoi e finché è connesso agli oggetti android.sourcesets.* bene.

    ad esempio, facendo:

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

    è ok. Ma fai attenzione a cambiare la cartella jniLibs e non gli altri elementi di origine (java, res, ecc …)

    Se hai mantenuto la posizione predefinita per le sorgenti main , vorrei solo tenere tutto sotto src/

    Puoi vedere ulteriori informazioni sulle origini e su come combinare più sorgenti di origine: http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Sources-and-Dependencies

    Per utilizzare i sapori per variare i sorgenti di origine,

     productFlavors{ phone{ } tablet{ } } 

    Ora strutturi il tuo codice come,

     src main phone tablet 

    Il codice main è comune tra entrambi i sapori, ma il codice del phone o della tablet è incluso solo quando viene creato il sapore corrispondente. È così, non c'è bisogno di fare altro.

    La struttura sotto phone e tablet è la stessa di quella main ( res , java , ecc.). Puoi anche avere un personalizzato AndroidManifest.xml sotto la directory del sapore. Gradle tenta di fondere l' AndroidManifest.xml del sapore con quello principale. In alcuni casi è necessario fornire regole per la fusione.

    L'Android è un fan Android di Google, tutto su telefoni Android, Android Wear, Android Dev e applicazioni Android Games e così via.