Comment définir et utiliser une constante dans le script de build Gradle (Android)?

Je suis en train de travailler sur une application Android avec Gradle que son système de construction.

Mon objectif est d'utiliser une valeur (un nom de paquet) comme un applicationId:

productFlavors {
   orange {
      applicationId "com.fruits.android.orange"
      //...

Mais aussi de les exposer via BuildConfig de sorte que le code Java a accès.

Cet accès doit être à partir de l'extérieur de la saveur (à savoir, la version gratuite de l'application a besoin de connaître le nom du package de la version payante de sorte qu'il peut demander à l'utilisateur pour une mise à niveau dans le Play store).

Donc j'aimerais faire quelque chose comme ça:

productFlavors {
   orange {
      applicationId orangeProPackage
      //...


buildConfigField 'String', 'ORANGE_PRO_PACKAGE', "$orangeProPackage" //?

Seulement je ne suis pas sûr de la façon de définir orangeProPackage de sorte qu'il est visible dans l'ensemble de la construction.gradle et ne se cassent pas le script.

Puisqu'il y a un peu de saveurs différentes, il serait mieux si j'arrivais à les regrouper toutes ces constantes comme ça (je suppose?):

def proPackages = [
        orange: "..."
        apple: "..."
        banana: "..."
]

puis référez-vous à un endroit propre et de manière descriptive, comme proPackages.orange etc.

La question est, comment le réaliser?

Ce n'est pas un doublon de Est-il possible de déclarer une variable dans Gradle utilisable en Java?

J'ai vu que la question (et quelques autres). Je sais comment déclarer buildConfigFields, j'en ai déjà beaucoup. Ma question est sur le réutilisation la même valeur qu'une buildConfigField et applicationId.

Double Possible de Est-il possible de déclarer une variable dans Gradle utilisable en Java?
ce n'est pas un doublon. J'ai vu que la question (et quelques autres). Je sais comment déclarer buildConfigFields, j'en ai déjà beaucoup. Ma question est à propos de la réutilisation, la même valeur qu'une buildConfigField et applicationId.

OriginalL'auteur Konrad Morawski | 2015-10-26

  1. 19

    Seulement je ne suis pas sûr de la façon de définir orangeProPackage de sorte qu'il est visible dans l'ensemble de la construction.gradle et ne se cassent pas le script.

    Vous pourriez le mettre dans gradle.properties dans votre racine du projet. Comme d'autres .properties fichiers, c'est juste une clé-valeur en magasin:

    ORANGE_PRO_PACKAGE=com.morawski.awesomeapp

    Vous alors se référer à elle comme une simple variable globale de type chaîne (ORANGE_PRO_PACKAGE) dans votre build.gradle:

    buildConfigField 'String', 'ORANGE_PRO_PACKAGE', ORANGE_PRO_PACKAGE

    il serait mieux si j'arrivais à les regrouper toutes ces constantes

    En ce qui concerne la .properties fichiers ne sont pas gérer cela. Là, vous cherchez peut-être à définir des variables globales dans le haut-niveau build.gradle fichier juste en plaine Groovy code ou quelque chose.

    En fait, il devrait être buildConfigField 'String', 'ORANGE_PRO_PACKAGE', '"' + ORANGE_PRO_PACKAGE + '"' sinon la valeur n'est pas générée comme une chaîne littérale dans BuildConfig et de la construire des pauses. Mais d'autres que cela fonctionne, merci pour l'astuce.
    Est-il possible d'utiliser un autre .properties fichier pour chaque saveur? L'avantage sera que de cette façon on peut conserver la même clé (dans gradle.les propriétés) à travers les saveurs. Basé sur la saveur depuis le fichier de changement, les valeurs de ces clés seraient différentes. Si vous utilisez le même gradle.properties fichier pour une chaîne de caractères dont la valeur change de goût, nous aurions besoin d'avoir différentes touches en même .properties de fichier, qui sont plus difficiles à maintenir dans le temps.
    il est possible d'utiliser un autre .fichier de propriétés pour chaque saveur?" - il n'y a rien d'automatique pour autant que je sache. Mais Gradle est Groovy, de sorte que vous pouvez lire tous les fichiers à partir de votre ordinateur de développement que vous souhaitez dans vos scripts.

    OriginalL'auteur CommonsWare