web-dev-qa-db-fra.com

Utilisation des versions de compilation - Structuration correcte des dossiers source et de build.gradle

Remarque: Réponse modifiée après la réponse de Xavier

J'essaie d'utiliser différents Build Flavors pour un même projet d'application dans Android Studio. Cependant, je semble avoir du mal à le configurer pour qu'il fonctionne correctement.

Étapes:

  1. Créez un nouveau Android Studio Project, nommé 'Test'.

  2. Ouvrez build.gradle * et ajoutez les lignes suivantes:

    productFlavors {
flavor1 {
    packageName 'com.Android.studio.test.flavor1'
    }
flavor2 {
    packageName 'com.Android.studio.test.flavor2'
    }
}
  3. Après avoir redémarré Android Studio, je vois maintenant 4 variantes de construction dans la section Variantes de construction. Cela signifie que nous avons réussi jusqu'à présent à définir les arômes du produit. **

  4. Création d'un nouveau dossier source pour saveur1 ; Cependant, je ne suis pas sûr de le faire correctement. Voici comment je l'ai fait:

    • N'oubliez pas que le nom de mon package pour ce projet est: com.foo.test
    • Faites un clic droit sur le dossier src, pour saveur1, j'ai en fait créé les dossiers individuels dans l'explorateur, de manière à ce que la structure soit src/flavor1/Java/com/foo/test/MainActivity.Java.
    • Ce qui précède a bien fonctionné, car le dossier 'Java' est en bleu , ce qui signifie que IDE connaît son répertoire source actif. En outre, le package a été créé automatiquement. Malgré cela, je reçois un avertissement pour la classe en double trouvée. Voir la capture d'écran ici.
    • Pour la saveur 2, j'ai essayé de créer le paquet manuellement, mais le dossier 'src' pour la saveur 2 ne semble pas être en bleu. Par conséquent, les options sont différentes lorsque vous cliquez avec le bouton droit de la souris et le 'Nouveau paquet' n'est pas disponible pour moi. Voir image ici.
    • Notez que pour la saveur1, j'ai également créé un répertoire 'res', qui devient bleu, mais malgré cela, ne permet pas de créer un fichier de ressources Android, ou un répertoire de ressources Andorid, dans Dans ce cas, je voulais utiliser différentes ressources pour différentes saveurs.

Est-ce que je fais quelque chose de mal? Ou est-ce que je manque quelque chose? Tenez-moi au courant si vous avez besoin de plus d'informations.

* Mon projet semble avoir deux fichiers build.gradle. Celui situé à la racine du dossier du projet (\ GradleTest), celui-ci est vide. Le second situé à la racine d’un sous-dossier de\GradleTest, également appelé 'GradleTest' (GradleTest-GradleTest), c’est celui qui avait déjà du code lorsqu’il était ouvert; c'est donc celui que j'ai édité.

** J'ai vérifié les paramètres de gradation et apparemment Utiliser l'importation automatique was déjà activé. Malgré cela, apporter des modifications à la construction Fichier .gradle ne met pas à jour automatiquement les variantes de construction. Remarque: J'ai également essayé d'utiliser Build - Rebuild Project et/ou Build - Make Project, no-go. Je dois encore fermer le projet et rouvrir pour que les modifications prennent effet.

androidintellij-ideagradleandroid-studio
162
daniel_c05

Si vous êtes dans les préférences de Studio, dans la section Gradule, vous pouvez activer l'importation automatique pour votre projet (nous l'activerons par défaut ultérieurement). Cela permettra à Studio de réimporter votre build.gradle chaque fois que vous le modifierez.

La création de variantes ne signifie pas que vous allez utiliser du code personnalisé pour elles, nous ne créons donc pas de dossiers. Vous devez les créer vous-même.

Si vous regardez mon IO talk vous verrez comment nous mélangeons les valeurs du saveurs et type de construction pour créer la variante.

Pour la source Java:

src/main/Java
src/flavor1/Java
src/debug/Java

sont tous les 3 utilisés pour créer une seule sortie. Cela signifie qu'ils ne peuvent pas définir la même classe.

Si vous voulez avoir une version différente de la même classe dans les deux versions, vous devez la créer dans les deux versions.

src/flavor1/Java/com/foo/A.Java
src/flavor2/Java/com/foo/A.Java

Et puis votre code dans src/main/Java peut faire

import com.foo.A

selon la version choisie, la bonne version de com.foo.A est utilisée.

Cela signifie également que les deux versions de A doivent avoir la même API (du moins lorsqu'il s'agit de l'API utilisée par les classes de src/main/Java/...

Modifier pour correspondre à la question révisée

De plus, il est important de placer la même classe A uniquement dans les dossiers source qui s'excluent mutuellement. Dans ce cas, src/saveur1/Java et src/saveur2/Java ne sont jamais sélectionnés ensemble, mais main et saveur1.

Si vous souhaitez fournir une version différente d'une activité dans une version différente, ne la mettez pas dans src/main/Java.

Notez que si vous aviez 3 versions et que vous vouliez une version personnalisée pour la version 1, alors que la version 2 et la version 3 partageaient la même activité, vous pouvez créer un dossier source commun pour ces deux autres activités. Vous disposez d'une flexibilité totale pour créer de nouveaux dossiers source et configurer le jeu de sources pour l'utiliser.

Sur vos autres points:

Il est normal que le deuxième dossier source de saveur ne soit pas bleu. Vous devez passer à la deuxième variante pour l'activer, puis vous pourrez créer des packages et des classes à l'intérieur. Jusque-là, Studio ne considère pas qu'il s'agisse d'un dossier source. Espérons que nous améliorerons cela à l'avenir afin de rendre le IDE conscient de ces dossiers sources inactifs .

Je pense qu'il est également normal que vous ne puissiez pas créer de fichiers de ressources dans le dossier res. Le système de menus n'a pas été mis à jour pour gérer tous ces dossiers de ressources supplémentaires. Cela viendra plus tard.

216
Xavier Ducrohet

"Product Flavors" sur Android

On m'a parfois demandé comment travailler avec différents hôtes, icônes ou même noms de paquets, en fonction de différentes versions de la même application.

Il existe de nombreuses raisons de le faire et un moyen facile d’y aller: les saveurs de produits.

Vous pouvez définir sur votre script build.gradle ce genre de choses que j'ai déjà décrites.

Saveurs de produits Une partie de cet article consiste en une réflexion écrite sur les saveurs de produits, alors de quoi s'agit-il? En ce qui concerne Android documentation:

Une version de produit définit une version personnalisée de l'application générée par le projet. Un même projet peut avoir différentes variantes qui modifient l'application générée.

Comment pouvez-vous les définir? Vous devez écrire sur votre build.gradle les saveurs que vous voulez définir:

productFlavors {  
        ...
        devel {
            ...
        }

        prod {
            ...
        }
    }

Maintenant, nous aurons deux saveurs différentes de notre application. Vous pouvez le vérifier sur Android Studio également dans l'onglet Variantes de construction.

Construire des variantes

Nom de plusieurs packages

Que faire si vous voulez avoir installé sur votre téléphone une application avec l’état de développement et une autre pour l’état de production. Comme vous le savez peut-être, vous ne pouvez installer qu'une seule application avec le même nom de package (si vous essayez d'installer un nouvel APK avec le même nom que celui installé sur votre téléphone, il tentera de le mettre à jour).

La seule chose à faire est de le définir sur chacune des saveurs de votre produit:

Android {  
    productFlavors {
        devel {
            applicationId "zuul.com.Android.devel"
        }
        prod {
            applicationId "zuul.com.Android"
        }
    }
}

Envoi de demandes à plusieurs hôtes en fonction de la saveur Comme précédemment, vous devez inclure certains paramètres dans le champ de configuration de la saveur de votre produit.

Android {  
    productFlavors {
        devel {
            applicationId "zuul.com.Android.devel"
            buildConfigField 'String', 'Host', '"http://192.168.1.34:3000"'

        }

        prod {
            applicationId "zuul.com.Android"
               buildConfigField 'String', 'Host', '"http://api.zuul.com"'

        }
    }
}

Par exemple, nous allons essayer de vous montrer comment vous pouvez intégrer cela à Retrofit pour envoyer une requête au serveur approprié sans gérer le serveur sur lequel vous pointez et en fonction de la version. Dans ce cas, il s'agit d'un extrait de l'application Zuul Android:

public class RetrofitModule {

    public ZuulService getRestAdapter() {
        RestAdapter restAdapter = new RestAdapter.Builder()
                .setEndpoint(BuildConfig.Host)
                .setLogLevel(RestAdapter.LogLevel.FULL)
                .build();
        return restAdapter.create(ZuulService.class);
    }

}

Comme vous pouvez le constater, vous devez simplement utiliser BuildConfigclass pour accéder à la variable que vous venez de définir.

Toute variable disponible dans votre code La variable Host n'est pas la seule que vous puissiez exposer dans votre code. Vous pouvez le faire avec tout ce que vous voulez:

prod {  
    applicationId "zuul.com.Android"
    buildConfigField 'String', 'Host', '"http://api.zuul.com"'
    buildConfigField 'String', 'FLAVOR', '"prod"'
    buildConfigField "boolean", "REPORT_CRASHES", "true"
}

Vous pouvez y accéder comme suit:

BuildConfig.Host  
BuildConfig.FLAVOR  
BuildConfig.REPORT_CRASHES

Différentes icônes par saveur Si vous voulez avoir différentes icônes par saveur, vous pouvez ainsi détecter visuellement celle que vous ouvrez (vous pouvez aussi le faire par son nom ... Mais cela ne pourrait pas correspondre à l'espace!), Il vous suffit de définir de nouvelles structures de répertoires pour chacun des types.

Dans l'exemple que je viens d'utiliser, il existe deux variantes: devel et prod. Ensuite, nous pourrions définir deux nouvelles structures de répertoires afin de définir les ressources souhaitées:

structure

Cela fonctionne avec d'autres types de ressources comme strings.xml, integers.xml, arrays.xml, etc.

Configurer les paramètres de signature

Pour configurer manuellement les configurations de signature pour votre type de construction de version à l'aide de configurations de construction de Gradle:

1.Créez un magasin de clés. Un magasin de clés est un fichier binaire contenant un ensemble de clés privées. Vous devez conserver votre magasin de clés dans un endroit sûr et sécurisé. 2.Créez une clé privée. Une clé privée représente l'entité à identifier avec l'application, telle qu'une personne ou une entreprise. 3.Ajoutez la configuration de signature au fichier build.gradle au niveau du module:

Android {
...
defaultConfig {...}
signingConfigs {
    release {
        storeFile file("myreleasekey.keystore")
        storePassword "password"
        keyAlias "MyReleaseKey"
        keyPassword "password"
    }
}
buildTypes {
    release {
        ...
        signingConfig signingConfigs.release
    }
}

}

Générez un fichier APK signé:

Pour générer un fichier APK signé, sélectionnez Construire> Générer un fichier APK signé dans le menu principal. Le paquet dans app/build/apk/app-release.apk est maintenant signé avec votre clé de publication.

ref: https://developer.Android.com/studio/build/variants.html#signing,http://blog.brainattica.com/how-to-work-with-flavours-on- Android /

19
A-Droid Tech

Il semble que vous ayez besoin de recharger votre projet après avoir ajouté de nouvelles saveurs dans build.gradle. Après cela, vous verrez 4 variantes de construction dans la vue Variantes de construction (vous y accédez depuis le bord gauche de la fenêtre).

En ce qui concerne les répertoires sources supplémentaires, il semble que vous deviez les créer à la main: src/flavor1/Java et src/flavor2/Java. Vous constaterez que le changement de la version dans la vue "Variantes de construction" modifiera le répertoires source actuellement actifs (le répertoire est bleu lorsqu'il s'agit d'un répertoire source actif)

Enfin, "gradle créera de nouveaux sourceSets pour vos nouvelles versions" signifie que gradle créera les objets Android.sourceSets.flavor1 et Android.sourceSets.flavor2 et vous pourrez les utiliser dans votre script build.gradle. Mais ces objets sont créés dynamiquement, c'est pourquoi vous ne les voyez pas dans le build.gradle (je vous suggère de lire ceci: http://www.gradle.org/docs/current/userguide/tutorial_using_tasks .html Surtout le 6.6: il explique la création d'une tâche dynamique. Un script gradle est un script groovy, je vous suggère donc de vous familiariser avec lui aussi.

7
ben75

J'ai eu le même problème lorsque j'ai migré mon projet vers Gradle. Le problème était que la construction n'a pas trouvé le dossier de ressources approprié. Je l'ai corrigé en ajoutant ceci sous l'élément Android dans build.gradle:

sourceSets {
        main {
            res.srcDirs = ['myProject/res']
        }
    }
2
Tomer

Ce qui est important et qui m’a bloqué pendant un bon bout de temps, c’est que le nom de la saveur qui doit correspondre au paquet par opposition au paquet défini dans la définition de la saveur dans gradle. Par exemple:

src/flavor1/Java/com/foo/A.Java

correspondra

productFlavors {
  flavor1 {
    packageName 'com.Android.studio.test.foobar'
  }
}

mais

src/foobar/Java/com/foo/A.Java ne sera pas utilisé pour la construction de saveur1.

0
bitrock

En grade:

Pour les types de construction, il vous suffit de:

buildTypes {
   release{
    //proguard, signing etc.
   }
   debug {
    //development
   }
  }
}

Et puis pour les saveurs, ajoutez ceux dont vous avez besoin

productFlavors {
    pro {
        applicationIdSuffix '.paid'
        buildConfigField 'boolean', 'PRO', 'true'
    }
    free {
        applicationIdSuffix '.free'
        buildConfigField 'boolean', 'PRO', 'false'
    }
}
0
TouchBoarder