文字列型のbuildConfigFieldを生成する方法


145

私のAndroid Studioプロジェクトではbuild configuration、いくつかの2つがありますbuildConfigField

    buildTypes {
    def SERVER_URL = "SERVER_URL"
    def APP_VERSION = "APP_VERSION"

    debug {
        buildConfigField "String", SERVER_URL, "http://dev.myserver.com"
        buildConfigField "String", APP_VERSION, "0.0.1"
    }

    release {
        buildConfigField "String", SERVER_URL, "https://myserver.com"
        buildConfigField "String", APP_VERSION, "0.0.1"

        minifyEnabled false
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
    }
}

私は次のようにエラーを取得しています:

/path/to/generated/BuildConfig.java
    Error:(14, 47) error: ';' expected
    Error:(15, 47) error: ';' expected

生成されるのBuildConfig.javaは次のとおりです。

public final class BuildConfig {
    public static final boolean DEBUG = Boolean.parseBoolean("true");
    public static final String APPLICATION_ID = "com.mycuteoffice.mcoapp";
    public static final String BUILD_TYPE = "debug";
    public static final String FLAVOR = "";
    public static final int VERSION_CODE = 1;
    public static final String VERSION_NAME = "1.0";
    // Fields from build type: debug
    public static final String APP_VERSION = 0.0.1;
    public static final String SERVER_URL = http://dev.mycuteoffice.com;
}

私が考えるAPP_VERSIONSERVER_URL、彼らは引用符を持っていない文字列型として正しく生成取得されていません。

なぜこのようにして生成されているのかはわかりません。この問題の解決方法を教えてください。


値の前後に一重引用符を二重引用符で追加するだけですbuildConfigField "String", APP_VERSION, ' "0.0.1" '(もちろんスペースは不要です)
Pierre

回答:


254

文字列型のビルド構成フィールドは、次のように宣言する必要があります。

buildConfigField "String", "SERVER_URL", "\"http://dev.myserver.com\""

引用符で囲まれたフィールド名、エスケープされた引用符で囲まれたフィールド値。


1
「SERVER_URL」を変数として使用することを目的とした質問。「SERVER_URL」を引用符で囲むと、値は文字列リテラルになります。したがって、@ madheadの答えはより正確です(そしてよりきれいです)。
ヴァンダーホーフ氏、

1
@WillVanderhoef、あなたは完全に間違っています。SERVER_URL引用符で囲まないと、機能しません。コメントする前に自分で試してみればわかるでしょう。エラーメッセージはError:(32, 0) Could not find property 'SERVER_URL' on BuildType_...
Vladyslav Matviienko 2016

私の悪い。私はSimasの回答をベースとして使用し、それをコピーしました。私の要点は3番目のフィールド(変数名)ではなく、変数値のエスケープに二重引用符を使用することでした。変数自体に二重引用符がない場合は、外側の単一引用符を使用してバックスラッシュを取り除くことができます。両方の回答を編集しました。
マッドヘッド

@VladMatvienkoは間違いなく機能します。私は実際に私が説明する方法でそれを使用しています。 def FIELD_NAME = "SERVER_URL"そして、buildConfigField "boolean", FIELD_NAME, "false"一緒にうまく動作します。SERVER_URLの定義がない場合、クラッシュしますが、それはおそらくあなたが間違っていることです。
Vanderhoefが

2
@WillVanderhoef、ええ、それはあなたが言及するのを忘れていたものです-あなたは定義の間に引用符を使います。だからあなたの解決策は1つの余分な行を持ち、引用符も使用しています、そしてそれがそれが私のほど良くない理由です。
Vladyslav Matviienko 16

96

なぜ誰もが二重引用符をエスケープすることについてそれほど怒っているのですか?醜く見えます!これはGroovyです。一重引用符と二重引用符を混在させることができます。

buildConfigField "String", 'SERVER_URL', '"http://dev.myserver.com"'
buildConfigField "String", 'APP_VERSION', '"0.0.1"'

5
それはまだ道のりではありません。文字列なので、エスケープしたり、ネストされた引用符を使用したりする必要はありません
Fabio

4
@Fabioネストされた引用符を使用すると、評価可能な式を使用できます。この回答を参照してください。
アルバートヴィラカルボ2017

31

「問題を解決する」ことによってリテラルを二重引用符で囲む必要がないことを意味する場合、設計どおりに機能しているように見えるので、私は何も見つけていません。

回避策として、リテラルを「gradle.properties」に移動して、潜在的に複数の醜い行を1つの醜い行に変換する実験を行っています。

そのようです:

buildTypes {
def SERVER_URL = "SERVER_URL"
def APP_VERSION = "APP_VERSION"

def CONFIG = { k -> "\"${project.properties.get(k)}\"" }

debug {
    buildConfigField "String", SERVER_URL, CONFIG("debug.server.url")
    buildConfigField "String", APP_VERSION, CONFIG("version")
}

release {
    buildConfigField "String", SERVER_URL, CONFIG("release.server.url")
    buildConfigField "String", APP_VERSION, CONFIG("version")

    minifyEnabled false
    proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
}
}

gradle.properties

version=0.1.1
...
debug.server.url=http://dev.myserver.com
...
release.server.url=http://myserver.com
...

さらなる考え:


def CONFIG = { b,k -> "\"${project.properties.get(b+'.'+k)}\"" }
def CONFIG_DEBUG = { k -> CONFIG('debug',k) }
def CONFIG_RELEASE = { k -> CONFIG('release',k) }

def CONFIG = { b,k -> "\"${project.properties.get(b+'.'+k)}\"" }
def CONFIG_INT = { b,k -> "${project.properties.get(b+'.'+k)}" }
...

ビルド構成フィールドがあり、同じgradleでmyn defの変数にアクセスしたいのですが、gradle plz helppは初めてです!!
Adeel Turk 2018

CONFIGスクリプトをありがとう!チームでは、varが存在しない場合に例外をスローするように少し改善しました CONFIG = { k -> if (project.properties.containsKey(k)) "\"${project.properties.get(k)}\"" else throw new RuntimeException("No such variable: " + k) }
。– demaksee

9

私も混乱しました。しかし意味があります。「文字列」はフィールドのタイプを定義しますが、ここで式を使用できるようにするためにフィールド値は自動的に引用されません。

buildConfigField "String", "TEST", "new Integer(10).toString()"

そうでなければ、それは不可能です。


たとえば、次のように文字列補間を使用することが可能です。
Szörényiアダム

9

文字列の引用符をエスケープします。

buildConfigField "String", 'SERVER_URL', "\"http://dev.myserver.com\""
buildConfigField "String", 'APP_VERSION', "\"0.0.1\""


2

アプリのbuild.gradle

def buildTimeAndVersion = releaseTime() + "-" + getSvnVersion()    
buildTypes {
debug {
    signingConfig signingConfigs.config
    buildConfigField "String", 'BIULD_TIME', "\"${buildTimeAndVersion}\""
    proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
    }
}
...
}

static def releaseTime() {
return new Date().format("yyyyMMdd", TimeZone.getDefault())
}

def getSvnVersion() {
def pro = ("svnversion -c " + getBuildDir().parent).execute()
pro.waitFor()
def version = pro.in.text
Pattern p = Pattern.compile("(\\d+\\:)?(\\d+)\\D?")
Matcher m = p.matcher(version)
if (m.find()) {
version = m.group(m.groupCount())
}
try {
return version
} catch (e) {
println e.getMessage()
}
return 0
}

その後、BuildConfig

public final class BuildConfig {  
public static final boolean DEBUG = Boolean.parseBoolean("true");   
public static final String APPLICATION_ID = "xxx.xxxxxxxx.xxx";   
public static final String BUILD_TYPE = "debug";  
public static final String FLAVOR = "";  
public static final int VERSION_CODE = 53;  
public static final String VERSION_NAME = "5.4.4";  
// Fields from build type: debug  
public static final String BIULD_TIME = "20181030-2595";  
}

1
コードのみの答えは本当にお勧めできません。将来の読者を助けるために、あなたも何をしているのか説明してください!
itsmysterybox 2018年

次回は、単に貼り付けをコピーするのではなく、以前の回答stackoverflow.com/a/53056170/1084764を参照してください
Raykud

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.