Чи можна оголосити змінну в Gradle придатною для використання на Java?

Чи можна оголосити змінну в Gradle придатною для використання на Java? В основному, я хотів би оголосити деякі зміни в build.gradle, а потім отримати його (очевидно) під час збирання. Так само, як макроси перед процесором у C / C ++ ...

Прикладом декларації може бути щось подібне ...:

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

Чи є спосіб зробити щось подібне?

Створення констант 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"
        }
    }
}

Ви можете отримати доступ до них за допомогою BuildConfig.FOO

Генеруйте ресурси Android

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

Ви можете отримати доступ до них звичайним способом за допомогою @string/app_nameабоR.string.app_name

Приклад використання ключа Api App у додатку для Android (Java та 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
    }
}

Використання в коді Java

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

BuildConfig.APP_KEY_1

Використання в xml-коді

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

• Посилання на приклад використання Api App Key в додатку Android
• Використання струнних констант, згенерованих конфігураціями збірки Gradle

Приклад із використанням системних властивостей, встановлених у build.gradle, зчитується з програми Java (слідкуйте за запитанням у коментарях):

В основному, використовуючи testзавдання в build.gradleметоді тестового завдання, systemPropertyвстановлюючи властивість системи, що передається під час виконання:

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'
}

І ось решта зразкового коду (який ви, мабуть, могли б зробити, але тут все одно включений): він отримує системне властивість MY-VAR1, очікується, що під час виконання буде встановлено таке 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);
  }
}

Тестовий зразок: якщо його MY-VARне встановлено, тест повинен бути невдалим:

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);
    }
}

Виконати (примітка: тест проходить):

$ 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

Я виявив, що хитра частина насправді отримує вихід з gradle ... Отже, журнал тут налаштований (slf4j + logback), і файл журналу показує результати (як альтернатива, запустити gradle --info cleanTest test; також є властивості, які отримують stdout до консоль, але, знаєте, чому):

$ 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

Якщо ви коментуєте " systemProperty..." (який, btw, працює лише у testзавданні), то:

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

Для повноти ось конфігурація зворотного зв'язку ( 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> 

Файли:

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

Ви можете створити поле конфігурації збірки, яке можна замінити за допомогою змінних системного середовища під час збирання:

Fallback використовується під час розробки, але ви можете змінити змінну під час запуску збірки на Jenkins або іншому інструменті.

У вашому додатку 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
        }
    } 

Змінна буде доступна як BuildConfig.SERVER_URL.

Відповідь rciovati цілком правильна. Я просто хотів додати ще один прикмету, який ви також можете створювати змінні для кожного типу збірки в межах конфігурації за замовчуванням для свого build.gradle. Це виглядатиме так:

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

Це дозволить вам отримати доступ до "через"

BuildConfig.App_NAME

Просто хотілося також зауважити цей сценарій, якщо ви хочете загальну конфігурацію.

Я використовую цей код і дуже добре працюю.

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
    }
 }
}

}

Як ви можете вставити String результат функції в buildConfigField

Ось приклад дати складання у наборі для читання формату:

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

def buildDate = getDate()

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

Я використовую

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

Він ґрунтується на відповіді Денніса, але схоплює його із змінної середовища.

Жоден із вищезазначених відповідей не давав мені ніяких вказівок, тому мені довелося провести дві години, вивчаючи методи Groovy.

Я хотів, щоб я міг протидіяти виробництву, пісочниці та місцевому середовищу. Оскільки я лінивий, я хотів лише змінити URL-адресу в одному місці. Ось що я придумав:

 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"
        }
    }

Альтернативний синтаксис, оскільки ${variable}у методах 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"
    }

Мені було важко зрозуміти, що рядки потрібно оголошувати як рядки, оточені лапками. Через це обмеження я не міг API_HOSTбезпосередньо використовувати посилання , що саме я хотів зробити в першу чергу.