È possibile dichiarare una variabile in Gradle utilizzabile in Java?


417

È possibile dichiarare una variabile in Gradle utilizzabile in Java? Fondamentalmente vorrei dichiarare alcuni errori in build.gradle e poi ottenerlo (ovviamente) al momento della compilazione. Proprio come le macro di un pre-processore in C / C ++ ...

Un esempio di dichiarazione sarebbe qualcosa del genere ...:

android {
    debug {
        A_VAR_RETRIEVABLE_IN_JAVA = 42
    }
    release {
        A_VAR_RETRIEVABLE_IN_JAVA = 42+52
    }
}

C'è un modo per fare qualcosa del genere?

Risposte:


796

Genera costanti Java

android {
    buildTypes {
        debug {
            buildConfigField "int", "FOO", "42"
            buildConfigField "String", "FOO_STRING", "\"foo\""
            buildConfigField "boolean", "LOG", "true"
        }

        release {
            buildConfigField "int", "FOO", "52"
            buildConfigField "String", "FOO_STRING", "\"bar\""
            buildConfigField "boolean", "LOG", "false"
        }
    }
}

Puoi accedervi con BuildConfig.FOO

Genera risorse Android

android {
    buildTypes {
        debug{
            resValue "string", "app_name", "My App Name Debug"
        }
        release {
            resValue "string", "app_name", "My App Name"
        }
    }
}

Puoi accedervi come di consueto con @string/app_nameoR.string.app_name


4
No, ma puoi anche generare risorse. Ho aggiornato la mia risposta incluso quello.
Rciovati,

2
Fantastico, grazie. Qualcosa che ho scoperto è che potresti specificare directory alternative per il debug e le build di rilascio. In <project>/src/, se si crea il file debug/res/values/strings.xmle un altro file release/res/values/strings.xml, è possibile impostare le risorse per il debug e le versioni di rilascio in modo leggermente più pulito.
elimirks

6
@rciovati è possibile ottenere lo stesso risultato senza il androidplugin? cioè solo usando apply plugin java? Grazie!
Zennichimaro,

2
Come posso creare costanti per diversi tipi di build e tipi di build?
Jakob Eriksson,

3
È possibile impostare uno dei campi, come l'anno in corso, e raggiungerlo anche indipendentemente dal tipo di build scelto (release, debug, ...)?
sviluppatore Android

102

Un esempio di utilizzo di una chiave app Api in un'applicazione Android (Java e XML)

gradle.properties

AppKey="XXXX-XXXX"

build.gradle

buildTypes {
//...
    buildTypes.each {
        it.buildConfigField 'String', 'APP_KEY_1', AppKey
        it.resValue 'string', 'APP_KEY_2', AppKey
    }
}

Utilizzo nel codice Java

Log.d("UserActivity", "onCreate, APP_KEY: " + getString(R.string.APP_KEY_2));

BuildConfig.APP_KEY_1

Utilizzo in codice xml

<data android:scheme="@string/APP_KEY_2" />

1
Se posso aggiungere, questa variabile può essere passata anche in fase di esecuzione. Utile soprattutto quando si eseguono test con configurazioni diverse. Usa./gradlew -PAppKey="1234" testdebug
Jaswanth Manigundan

1
Per dichiarare la stessa proprietà per ogni tipo di costruzione è possibile utilizzare il defaultConfigblocco così: stackoverflow.com/a/51521146/321354
rciovati

Hai un esempio funzionante della parte XML? in un repository Github o Gist. Non funziona per me, non posso fare riferimento@string/APP_KEY_2
voghDev

32

Esempio di utilizzo delle proprietà di sistema, impostato in build.gradle, letto dall'applicazione Java (seguito dalla domanda nei commenti):

Fondamentalmente, utilizzando l' testattività in build.gradle, con il metodo dell'attività di test che systemPropertyimposta una proprietà di sistema che viene passata in fase di esecuzione:

apply plugin: 'java'
group = 'example'
version = '0.0.1-SNAPSHOT'

repositories {
    mavenCentral()
    // mavenLocal()
    // maven { url 'http://localhost/nexus/content/groups/public'; }
}

dependencies {
    testCompile 'junit:junit:4.8.2'
    compile 'ch.qos.logback:logback-classic:1.1.2'
}

test {
  logger.info '==test=='
  systemProperty 'MY-VAR1', 'VALUE-TEST'
}

Ed ecco il resto del codice di esempio (che probabilmente si potrebbe dedurre, ma è comunque incluso qui): ottiene una proprietà di sistema MY-VAR1, che dovrebbe essere impostata in fase di esecuzione su VALUE-TEST:

package example;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class HelloWorld {
  static final Logger log=LoggerFactory.getLogger(HelloWorld.class);
  public static void main(String args[]) {
    log.info("entering main...");
    final String val = System.getProperty("MY-VAR1", "UNSET (MAIN)");
    System.out.println("(main.out) hello, world: " + val);
    log.info("main.log) MY-VAR1=" + val);
  }
}

Testcase: se MY-VARnon impostato, il test dovrebbe fallire:

package example;
...
public class HelloWorldTest {
    static final Logger log=LoggerFactory.getLogger(HelloWorldTest.class);
    @Test public void testEnv() {
        HelloWorld.main(new String[]{});
        final String val = System.getProperty("MY-VAR1", "UNSET (TEST)");
        System.out.println("(test.out) var1=" + val);
        log.info("(test.log) MY-VAR1=" + val);
        assertEquals("env MY-VAR1 set.", "VALUE-TEST", val);
    }
}

Esegui (nota: il test sta superando):

$ gradle cleanTest test
:cleanTest
:compileJava UP-TO-DATE
:processResources UP-TO-DATE
:classes UP-TO-DATE
:compileTestJava UP-TO-DATE
:processTestResources UP-TO-DATE
:testClasses UP-TO-DATE
:test

BUILD SUCCESSFUL

Ho scoperto che la parte difficile sta effettivamente ottenendo l'output dal gradle ... Quindi, la registrazione è configurata qui (slf4j + logback) e il file di registro mostra i risultati (in alternativa, esegui gradle --info cleanTest test; ci sono anche proprietà che ottengono stdout su la console, ma, sai, perché):

$ cat app.log
INFO Test worker example.HelloWorld - entering main...
INFO Test worker example.HelloWorld - main.log) MY-VAR1=VALUE-TEST
INFO Test worker example.HelloWorldTest - (test.log) MY-VAR1=VALUE-TEST

Se commenti " systemProperty..." (che, tra l'altro, funziona solo in testun'attività), allora:

example.HelloWorldTest > testEnv FAILED
    org.junit.ComparisonFailure at HelloWorldTest.java:14

Per completezza, ecco il logback config ( src/test/resources/logback-test.xml):

<configuration>
    <appender name="FILE" class="ch.qos.logback.core.FileAppender">
        <file>app.log</file>
        <layout class="ch.qos.logback.classic.PatternLayout">
            <pattern>%d %p %t %c - %m%n</pattern>
        </layout>
 </appender>
 <root level="info">
     <appender-ref ref="FILE"/>
</root>
</configuration> 

File:

  • build.gradle
  • src/main/java/example/HelloWorld.java
  • src/test/java/example/HelloWorldTest.java
  • src/test/resources/logback-test.xml

Si noti che questa è una risposta diretta a un commento nella risposta accettata, quindi si discosta leggermente dalla domanda originale.
michael,

2
Posso in qualche modo ottenere version = '0.0.1-SNAPSHOT'tramite il codice Java?
Nom1fan,

SystemProperty è disponibile solo nell'attività di test gradle :(. Qualcuno sa in altro modo di avere un valore variabile gradle nel codice java della libreria?
Stoycho Andreev

systemPropertyha davvero senso solo per i test, quindi vedo perché lo hanno fatto in questo modo (non è una svista), ma allo stesso tempo, ho anche provato a usare il gradle per cose a cui non era destinato (come un'applicazione DSL ) così posso identificarmi. In alternativa, consiglierei di caricare le proprietà da un file di proprietà (o servizio di configurazione, ecc.), Perché se non è in modalità "test", è la modalità "produzione" e richiede la logica dell'applicazione. (Questa è la teoria, comunque.)
michael

14

È possibile creare un campo di configurazione build sostituibile tramite le variabili di ambiente di sistema durante la compilazione:

Il fallback viene utilizzato durante lo sviluppo, ma è possibile ignorare la variabile quando si esegue la build su Jenkins o un altro strumento.

Nella tua app build.gradle :

buildTypes {
        def serverUrl =  '\"' + (System.getenv("SERVER_URL")?: "http://default.fallback.url.com")+'\"'
        debug{
            buildConfigField "String", "SERVER_URL", serverUrl
        }
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            buildConfigField "String", "SERVER_URL", serverUrl
        }
    } 

La variabile sarà disponibile come BuildConfig.SERVER_URL.


1
Grazie per questa risposta! Ho cercato di capire come rendere visibile una variabile d'ambiente all'interno di un file .java per Android, e questo ha funzionato alla grande!
Wayne Piekarski,

Se si desidera definire la variabile booleana, è necessario utilizzare buildConfigField "booleano", "CI_BUILD", "$ {isCi}" o buildConfigField "booleano", "CI_BUILD", "Boolean.parseBoolean (" + '"' + isCi + ' "' + ')' se si vuole sfuggire controlli pelucchi ( stackoverflow.com/questions/29889098/... )
android_dev

5

La risposta di rciovati è del tutto corretta. Volevo solo aggiungere un altro bocconcino da poter creare anche variabili per ogni tipo di build all'interno della porzione di configurazione predefinita di build.gradle. Questo sarebbe simile a questo:

android {
    defaultConfig {
        buildConfigField "String", "APP_NAME", "\"APP_NAME\""
    }
}

Questo ti permetterà di avere accesso a

BuildConfig.App_NAME

Volevo solo prendere nota di questo scenario anche se vuoi una configurazione comune.


3

Sto usando questo codice e sto lavorando molto bene.

def baseUrl = '\"http://patelwala.com/myapi/"'
def googleServerKey = '\"87171841097-opu71rk2ps35ibv96ud57g3ktto6ioio.apps.googleusercontent.com"'
android {
  buildTypes {
  release {
        minifyEnabled true
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
        buildConfigField 'String', 'BASE_URL', baseUrl
        buildConfigField 'String', 'web_client_id', googleServerKey
    }
    releasedebug {
        initWith debug
        buildConfigField 'String', 'BASE_URL', baseUrl
        buildConfigField 'String', 'web_client_id' ,googleServerKey
    }
    debug {

        buildConfigField 'String', 'BASE_URL', baseUrl
        buildConfigField 'String', 'web_client_id', googleServerKey
    }
 }
}

}


Sarebbe bello se specifichi cosa hai modificato e quale impatto ha, risultando nella tua soluzione di lavoro.
Badgy

2

Come è possibile inserire il risultato String della funzione in buildConfigField

Ecco un esempio di data di costruzione nel set di formati leggibili dall'uomo:

def getDate() {
    return new SimpleDateFormat("dd MMMM yyyy", new Locale("ru")).format(new Date())
}

def buildDate = getDate()

defaultConfig {
    buildConfigField "String", "BUILD_DATE", "\"$buildDate\""
}

1

sto usando

buildTypes.each {
    it.buildConfigField 'String', 'GoogleMapsApiKey', "\"$System.env.GoogleMapsApiKey\""
}

Si basa sulla risposta di Dennis ma la afferra da una variabile d'ambiente.


0

Nessuna delle risposte sopra mi ha dato delle linee guida, quindi ho dovuto passare due ore a conoscere i metodi Groovy.

Volevo essere in grado di andare contro una produzione, sandbox e ambiente locale. Perché sono pigro, volevo solo cambiare l'URL in un posto. Ecco cosa mi è venuto in mente:

 flavorDimensions 'environment'
    productFlavors {
        production {
            def SERVER_HOST = "evil-company.com"
            buildConfigField 'String', 'API_HOST', "\"${SERVER_HOST}\""
            buildConfigField 'String', 'API_URL', "\"https://${SERVER_HOST}/api/v1/\""
            buildConfigField 'String', 'WEB_URL', "\"https://${SERVER_HOST}/\""
            dimension 'environment'
        }
        rickard {
            def LOCAL_HOST = "192.168.1.107"
            buildConfigField 'String', 'API_HOST', "\"${LOCAL_HOST}\""
            buildConfigField 'String', 'API_URL', "\"https://${LOCAL_HOST}/api/v1/\""
            buildConfigField 'String', 'WEB_URL', "\"https://${LOCAL_HOST}/\""
            applicationIdSuffix ".dev"
        }
    }

Sintassi alternativa, perché è possibile utilizzare solo ${variable}con virgolette doppie nei metodi Groovy.

    rickard {
        def LOCAL_HOST = "192.168.1.107"
        buildConfigField 'String', 'API_HOST', '"' + LOCAL_HOST + '"'
        buildConfigField 'String', 'API_URL', '"https://' + LOCAL_HOST + '/api/v1/"'
        buildConfigField 'String', 'WEB_URL', '"https://' + LOCAL_HOST + '"'
        applicationIdSuffix ".dev"
    }

Ciò che è stato difficile da capire per me è che le stringhe devono essere dichiarate come stringhe racchiuse tra virgolette. A causa di questa restrizione, non ho potuto usare API_HOSTdirettamente il riferimento , che era quello che volevo fare in primo luogo.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.