Pourquoi ne Gradle construire mon module en mode Release, lorsque l'application est en cours de Débogage

Je suis en train de faire un nouveau projet Android, avec la norme 'app' module, ainsi qu'un projet de bibliothèque (appelons 'custom_lib'). Dans le app's build.gradle fichier, je l'ai relier le module en tant que tel : 

dependencies {
    compile project(':custom_lib')
}

Quand j'déclencher le processus de construction (Menu Build > Make Project), j'obtiens le résultat suivant dans le Gradle console

Executing tasks: [clean, :app:compileDebugSources, :custom_lib:compileDebugSources]
Configuration on demand is an incubating feature.
:app:clean
:custom_lib:clean
:app:preBuild
:app:preDebugBuild
:app:checkDebugManifest
:app:preReleaseBuild
:custom_lib:compileLint
:custom_lib:copyReleaseLint UP-TO-DATE
:custom_lib:mergeReleaseProguardFiles UP-TO-DATE
:custom_lib:preBuild
:custom_lib:preReleaseBuild
:custom_lib:checkReleaseManifest
:custom_lib:prepareReleaseDependencies
:custom_lib:compileReleaseAidl
:custom_lib:compileReleaseRenderscript
:custom_lib:generateReleaseBuildConfig
:custom_lib:generateReleaseAssets UP-TO-DATE
:custom_lib:mergeReleaseAssets
:custom_lib:generateReleaseResValues UP-TO-DATE
:custom_lib:generateReleaseResources
:custom_lib:packageReleaseResources
:custom_lib:processReleaseManifest
:custom_lib:processReleaseResources
:custom_lib:generateReleaseSources
:custom_lib:compileReleaseJava
:custom_lib:processReleaseJavaRes UP-TO-DATE
:custom_lib:packageReleaseJar
:custom_lib:compileReleaseNdk
:custom_lib:packageReleaseJniLibs UP-TO-DATE
:custom_lib:packageReleaseLocalJar UP-TO-DATE
:custom_lib:packageReleaseRenderscript UP-TO-DATE
:custom_lib:bundleRelease
:app:prepareComAndroidSupportAppcompatV72102Library
:app:prepareComAndroidSupportSupportV42102Library
:app:prepareTestDoubleBuildCustom_libUnspecifiedLibrary
:app:prepareDebugDependencies
:app:compileDebugAidl
:app:compileDebugRenderscript
:app:generateDebugBuildConfig
:app:generateDebugAssets UP-TO-DATE
:app:mergeDebugAssets
:app:generateDebugResValues UP-TO-DATE
:app:generateDebugResources
:app:mergeDebugResources
:app:processDebugManifest
:app:processDebugResources
:app:generateDebugSources
:app:compileDebugJava
:app:compileDebugNdk
:app:compileDebugSources
:custom_lib:preDebugBuild
:custom_lib:checkDebugManifest
:custom_lib:prepareDebugDependencies
:custom_lib:compileDebugAidl
:custom_lib:compileDebugRenderscript
:custom_lib:generateDebugBuildConfig
:custom_lib:generateDebugAssets UP-TO-DATE
:custom_lib:mergeDebugAssets
:custom_lib:generateDebugResValues UP-TO-DATE
:custom_lib:generateDebugResources
:custom_lib:packageDebugResources
:custom_lib:processDebugManifest
:custom_lib:processDebugResources
:custom_lib:generateDebugSources
:custom_lib:compileDebugJava
:custom_lib:compileDebugNdk
:custom_lib:compileDebugSources
BUILD SUCCESSFUL
Total time: 2.184 secs

Ce qui m'intrigue, c'est que la construction du mécanisme déclenche une version de Débogage (comme la première ligne dit), mais presque immédiatement, Gradle utilise la tâche :app:preReleaseBuild qui font mon custom_lib module à être construit avec la configuration de Version.

Et puis, après l'application est entièrement construit, Gradle compile mon module avec la configuration de Débogage.

Donc mes questions sont :

  • Pourquoi est-il en train de faire cette double construire ce qui semble incohérent ?
  • Comment puis-je m'assurer que la bibliothèque est construite avec la configuration de débogage lorsque je lance une version de Débogage du processus ?

EDIT :

app/build.gradle : 

apply plugin: 'com.android.application'
android {
compileSdkVersion 21
buildToolsVersion "21.1.1"
defaultConfig {
applicationId "com.deezer.testdoublebuild"
minSdkVersion 8
targetSdkVersion 21
versionCode 1
versionName "1.0"
}
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_7
targetCompatibility JavaVersion.VERSION_1_7
}
buildTypes {
debug{
debuggable true
}
release {
debuggable false
minifyEnabled false
}
}
}
dependencies {
compile project(':custom_lib')
}

custom_lib/build.gradle : 

apply plugin: 'com.android.library'
android {
compileSdkVersion 21
buildToolsVersion "21.1.1"
defaultConfig {
applicationId "com.deezer.mylibrary"
minSdkVersion 8
targetSdkVersion 21
versionCode 1
versionName "1.0"
}
compileOptions {
sourceCompatibility JavaVersion.VERSION_1_7
targetCompatibility JavaVersion.VERSION_1_7
}
buildTypes {
release {
minifyEnabled false
proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}
}
dependencies {
}

Note : je suis à l'aide d'Android Studio 1.0 RC 1 /Gradle 2.2, et reproduit ce problème en créant un nouveau projet à partir de zéro, ajouter un vide Android module Bibliothèque, et "voila"

  • Pouvez-vous fournir l'ensemble de votre build.gradle?
  • Gradle outpus ce avec n'importe quelle build.gradle autant que je sache. Je pense que c'est juste une étape, il va à travers et en sortir immédiatement après...
  • Ce n'est pas seulement une étape qui ne fait rien comme il compile mon code de bibliothèque : je vais ajouter la pleine gradle de sortie
  • Gradle fait beaucoup de "pré/vérifier/préparer/...la Libération des" tâches " dans mes projets aussi, mais mon code final est certainement en mode de DÉBOGAGE.
  • Vous ne devriez pas avoir un type de construction pour votre android bibliothèque. En particulier, vous n'aurez pas Proguard sur votre bibliothèque avant de l'utiliser dans votre application. Android libs par défaut à la libération.
  • la bibliothèque est destiné à être publié à un certain point, et une partie de sont va être brouillée avec proguard, mais comme je l'ai développer ce que j'en ai besoin pour être en Debug localement.

InformationsquelleAutor XGouchet | 2014-12-03
  1. 21

    Dans la section "créer des Variantes de" fenêtre du panneau sur la gauche, vous devriez voir vos deux modules, et à côté de l'actuel "active" variantes. Par exemple

    app          debug
custom_lib   debug

    Lors de l'appel de Build > Make Project nous construisons tous les modules du projet dans leur variante actuelle.

    Toutefois, en raison d'un Gradle limitation (https://code.google.com/p/android/issues/detail?id=52962), la construction d' app dans debug nécessiteront la construction de la release variante de custom_lib, et donc, en fin de construction à la fois.

    Je recommande de ne pas utiliser Make Project mais au lieu d'utiliser l'option ci-dessous qui dit Make Module app. Cette option va changer à partir de app à lib basée sur la sélection en cours dans le Project panneau ou sur la base actuelle de l'éditeur, et sera toujours de faire ce qui est nécessaire pour construire le module en cours.

    (À la recherche dans ce, nous avons remarqué qu'il n'y a pas un raccourci, nous sommes donc en ajouter un).

    • Très intéressant, merci pour l'aperçu! Moi aussi, je me demandais pourquoi les bibliothèques semblait être construit à deux reprises. Serait-ce à dire que, si le problème 52962 est résolu, construit avec les dépendances des modules sera plus rapide?
    • Il ne sera pas plus vite parce que vous pourriez obtenir dans la face de la question, où vous avez la custom_lib active de la variante de la libération, ce qui ferait de Make Project encore construire tant.
    • La bonne façon de construire plus rapide est de ne construire que le module que vous souhaitez (plutôt que de l'ensemble du projet), et de le construire à ses dépendances.
    • malheureusement, à partir d'Android Studio, il n'y a aucun moyen pratique de "seulement générer un module que vous voulez", vous devez 1. sélectionnez le module; 2. naviguer ti Build -> Faire nom_du_module à chaque fois.
    InformationsquelleAutor Xavier Ducrohet
  2. 65

    Mettre cela dans votre application dépendances:

    dependencies {
debugCompile project(path: ':custom_lib', configuration: "debug")
releaseCompile project(path: ':custom_lib', configuration: "release")
}

    et dans votre bibliothèque, en construire.gradle ajouter:

    android {
defaultConfig {
defaultPublishConfig 'release'
publishNonDefault true
}
}

    La bibliothèque sera construite sur le même mode que l'application. Contrairement à de précédentes révisions de cette réponse, j'ai confirmé une saveur n'est pas nécessaire sur la bibliothèque (cela peut être dû à Gradle ou Android versions plugin - je suis l'aide de Gradle 2.14 et Android plugin 2.1.0 et n'en a pas besoin).

    Edit: Vous pouvez avoir des problèmes si vous ne nettoyez pas/reconstruction après la modification de la gradle fichiers, comme indiqué dans cette réponse ici.

    • C'est la seule solution propre à cette page.
    • L'air vraiment interessant. Exactement ce dont j'ai besoin en fait. Cependant, j'ai le message suivant à Gradle l'heure de la synchronisation: Error:Configuration with name 'libraryDebug' not found.. J'ai essayé avec juste de "debug" et "release" (qui sont les construire config noms que j'utilise dans ma lib), mais le résultat est le même. Une idée ? (Je suis en cours d'exécution Android Studio 2.0 beta 2.)
    • Je n'ai pas besoin de le faire pour un certain temps, mais si vous postez votre gradle les fichiers de l'application + bibliothèque, je peux voir si il n'y a rien d'évident de mal
    • Merci beaucoup Kane. Elle est ici: stackoverflow.com/questions/35312743/...
    • Donc, il fonctionne. J'ai juste besoin de faire un "nettoyage" comme expliqué ici: stackoverflow.com/questions/35312743/.... Et j'ai aussi vérifié, le productFlavour {} déclaration est effectivement nécessaire. Merci !
    • Heureux vous avez obtenu de travail, j'ai mis à jour la réponse à inclure vos résultats
    • Beaucoup 🙂 j'ai fait la même dans mon propre aswer. C'est vraiment cool d'avoir ce travail, ça aide beaucoup!
    • stackoverflow.com/a/29031427/4455466 fournit une autre solution sans la mystérieuse bibliothèque du produit de la saveur.
    • Qui ressemble à la même réponse sans saveur. Je n'étais pas sûr que c'était nécessaire, mais quelqu'un l'a confirmé qu'il était. Je devrais peut-être revoir ce point et mise à jour de ma réponse, si elle s'avère inutile (ce qui est à quoi il ressemble, selon la réponse que vous avez mis en lien).
    • J'ai récemment mis en œuvre ce nouveau et peut confirmer la saveur n'est plus nécessaire. J'ai le sentiment qu'une nouvelle Gradle ou Android version du plugin a assoupli cette exigence.
    • la vie de veille, merci
    • Merci @KaneO Riley
    • Grande réponse. Mérite la coche verte. Merci pour le partage
    • comment ce travail, si vous avez plusieurs produits de saveurs
    • l'ajout de publishNonDefault vrai dans gradle-4.10.2 donne l'avertissement suivant publishNonDefault est obsolète et n'a plus d'effet. Toutes les variantes sont maintenant publiés. et en regardant le code source, il semble un peu inutile, cependant, le message d'avertissement semble être erronée comme je l'ai toujours utiliser la variante de débogage peut pas public void setPublishNonDefault(boolean publishNonDefault) { logger.warn("publishNonDefault is deprecated and has no effect anymore. All variants are now published."); }

    InformationsquelleAutor Kane O'Riley
  3. 3

    Gradle prend désormais en charge plus de Saveur-buildType Compilation de la directive, de sorte KaneORiley la réponse peut maintenant être améliorée comme suit:

    de la bibliothèque de construire.gradle:

    android {
defaultPublishConfig 'release'
publishNonDefault true
productFlavors {
library {
}
}

    application de la construire.gradle:

    configurations {
devDebugCompile
devReleaseCompile
storeDebugCompile
storeReleaseCompile
}
android {
.....
}
dependencies {
(...)
devDebugCompile    project(path: ':path:to:lib', configuration: 'devDebug')
devReleaseCompile  project(path: ':path:to:lib', configuration: 'devRelease')
storeDebugCompile  project(path: ':path:to:lib', configuration: 'storeDebug')
storeReleaseCompile project(path: ':path:to:lib', configuration: 'storeRelease') 
}
    InformationsquelleAutor Phileo99
  4. 2

    Cela est étroitement liée à cette question.

    Il semble que Gradle construit référencé tous les modules d'un projet en mode release. Depuis custom_lib est seulement une bibliothèque, sa configuration est remplacé par le module de référence. Je ne serais pas trop inquiet au sujet de la bibliothèque construit à l'aide de la "libération" de l'étiquette.

    Vous remarquerez que dans votre gradle de sortie, votre projet est bien en cours d'élaboration avec la configuration de débogage.

    • J'ai fait comme vous l'avez suggéré, mais j'obtiens toujours le même résultat. D'ailleurs, si vous regardez la dernière partie de mon gradle sortie de la console, vous verriez qu'il parvient à trouver le débogage des tâches dans le custom_lib, même si le type de débogage n'est pas explicitement déclaré
    • Le debug et release les types de builds sont intégrés; vous n'avez pas à spécifier explicitement à les obtenir.
    • Bon point, Scott. Je crois que le build Gradle est toujours exécutée en tant que "libération" pour référencées bibliothèques. C'est l'application du module lui-même qui prend la configuration correspondante.
    • Oui, par défaut, il utilise la version de bibliothèques, mais je pense que vous pouvez le changer via les scripts de construction (ou peut-être vous ne pouvez mapper le goût de la saveur les relations entre les modules; j'en oublie). Il ne répond pas à la question de savoir pourquoi il s'appuie à la fois sur les types de builds, dont je ne suis pas sûr à ce sujet.
    InformationsquelleAutor Paul Lammertsma