Skip to content

Most visited

Recently visited

navigation

Gradle용 Android 플러그인 3.0.0으로 마이그레이션

알려진 문제: 기존의 Android Studio 프로젝트가 알파 버전의 Android 플러그인 3.0.0을 사용 중인 경우(예: 3.0.0-alpha9), Android 플러그인 3.0.0-beta4으로 마이그레이션하여 프로젝트를 동기화할 때 다음과 같은 오류가 발생할 수도 있습니다. Gradle project refresh failed.

이 문제를 해결하려면 메뉴 모음에서 Build > Clean Project를 선택합니다. 이 동작은 각 프로젝트에 대해 한 번만 수행해야 합니다. 그런 다음, 프로젝트 파일을 Gradle과 동기화합니다(메뉴 모음에서 Sync Project 클릭).

프로젝트를 Android 플러그인 3.0.0-beta4 이상으로 마이그레이션하려면, 이 페이지를 참조하여 Gradle 플러그인과 특정 버전을 적용하는 방법과 몇 가지 커다란 변화에 맞게 프로젝트를 적용하는 방법에 대해 알아보세요.

Gradle 버전 업데이트

새로운 Android 플러그인에는 Gradle 버전 4.1-rc-1 이상이 필요합니다. Android Studio 3.0 베타 1 이상을 사용하여 기존 프로젝트를 여는 경우, 화면 안내에 따라 기존 프로젝트를 호환 버전의 Gradle로 자동 업데이트하세요.

Gradle을 수동으로 업데이트하려면 다음과 같이 gradle-wrapper.properties에서 URL을 업데이트하세요.

distributionUrl=\
  https\://services.gradle.org/distributions/gradle-4.1-rc-1-all.zip

플러그인 적용

Android Studio 3.0 베타 1 이상을 사용하여 기존 프로젝트를 여는 경우, 화면 안내에 따라 프로젝트를 최신 버전의 Android 플러그인으로 자동 업데이트하세요. 프로젝트를 수동으로 업데이트하려면, 다음과 같이 프로젝트 수준 build.gradle 파일에 Maven 리포지토리를 포함시키고 플러그인 버전을 변경하세요.

buildscript {
    repositories {
        ...
        // You need to add the following repository to download the
        // new plugin.
        google()
    }

    dependencies {
        classpath 'com.android.tools.build:gradle:3.0.0-beta4'
    }
}

변형 인식 종속성 관리를 위해 버전 차원(flavor dimension) 사용

플러그인 3.0.0에는 라이브러리를 사용할 때 자동으로 변형을 매칭시키는 새로운 종속성 메커니즘이 포함됩니다. 즉, 앱의 debug 변형은 라이브러리의 debug 변형을 자동으로 사용하는 방식입니다. 이 기능은 버전(flavor)을 사용할 때도 마찬가지로 작동하며, 앱의 redDebug 변형은 라이브러리의 redDebug 변형을 사용합니다. 이 기능이 올바로 작동하려면 이제 플러그인에서 모든 버전은 명명된 버전 차원에 속해야 하며, 단일 차원만을 사용할 경우라도 그래야 합니다. 그렇지 않으면 다음과 같은 빌드 오류가 발생합니다.

Error:All flavors must now belong to a named flavor dimension.
The flavor 'flavor_name' is not assigned to a flavor dimension.

이 오류를 해결하려면 각 버전을 명명된 차원에 할당합니다(아래 샘플 참조). 이제 종속성 매칭은 플러그인에 의해 처리되므로, 개발자는 버전 차원을 신중하게 명명해야 합니다. 예를 들어, 모든 앱과 라이브러리 모듈이 foo 차원을 사용하는 경우, 개발자는 어떤 버전이 플러그인에 의해 매칭되는지를 제어하기가 쉽지 않습니다.

// Specifies a flavor dimension.
flavorDimensions "color"

productFlavors {
     red {
      // Assigns this product flavor to the 'color' flavor dimension.
      // This step is optional if you are using only one dimension.
      dimension "color"
      ...
    }

    blue {
      dimension "color"
      ...
    }
}

종속성 매칭과 관련된 빌드 오류 해결

Android 플러그인은 앱의 각 변형을 라이브러리의 동일한 변형과 매칭시키려고 시도합니다. 따라서 'freeDebug' 버전의 앱을 빌드하는 경우, 플러그인은 이 버전을 로컬 라이브러리 종속성의 'freeDebug' 버전과 매칭시키려고 시도합니다.

그러나 앱이 'staging'이라는 빌드 유형을 구성하려고 하는데 그 라이브러리 종속성 중 하나가 없는 경우를 가정해 보겠습니다. 플러그인이 'staging' 버전의 앱을 빌드하려고 시도할 때 플러그인은 어떤 버전의 라이브러리를 사용할지 알지 못하며, 다음과 같은 유사한 오류 메시지가 나타납니다.

Error:Failed to resolve: Could not resolve project :mylibrary.
Required by:
    project :app

Android 플러그인 3.0.0-beta4 이상에는 앱과 종속성 사이의 직접적인 변형 매칭이 불가능한 상황을 플러그인이 어떻게 해결할지 그 방법을 제어하는 DSL 요소들이 포함됩니다. 아래 표는 변형 인식 종속성 매칭과 관련된 빌드 오류를 해결하기 위해 어떤 DSL 속성을 사용해야 할지 결정하도록 도와줍니다.

빌드 오류의 원인해결책

라이브러리 종속성이 없는 빌드 유형이 앱에 포함됩니다.

예를 들어, 앱에는 'staging' 빌드 유형이 포함되지만 종속성에는 'debug' 및 'release' 빌드 유형만 포함됩니다.

참고로, 앱에 없는 빌드 유형이 라이브러리 종속성에 포함된 경우는 문제가 되지 않습니다. 그 이유는 플러그인이 해당 빌드 유형을 종속성으로부터 절대 요청하지 않기 때문입니다.

matchingFallbacks를 사용하여 주어진 빌드 유형에 대한 대체 매칭을 지정합니다(아래 참조).
// In the app's build.gradle file.
android {
    buildTypes {
        debug {}
        release {}
        staging {
            // Specifies a sorted list of fallback build types that the
            // plugin should try to use when a dependency does not include a
            // "staging" build type. You may specify as many fallbacks as you
            // like, and the plugin selects the first build type that's
            // available in the dependency.
            matchingFallbacks = ['debug', 'qa', 'release']
        }
    }
}

주어진 버전 차원이 앱과 그 라이브러리 종속성에 모두 존재하는 경우, 라이브러리에 없는 버전이 앱에 포함됩니다.

예를 들어, 'tier' 버전 차원은 앱과 그 라이브러리 종속성에 모두 포함됩니다. 그러나 앱의 'tier' 차원에는 'free' 및 'paid' 버전이 포함되지만, 종속성에는 동일 차원에 대해 'demo' 및 'paid' 버전만 포함됩니다.

참고로, 주어진 버전 차원이 앱과 그 라이브러리 종속성에 모두 존재하는 경우, 앱에 없는 제품 버전이 라이브러리에 포함된 경우는 문제가 되지 않습니다. 그 이유는 플러그인이 해당 버전을 종속성으로부터 요청하지 않기 때문입니다.

matchingFallbacks를 사용하여 앱의 'free' 제품 버전에 대한 대체 매칭을 지정합니다(아래 참조).
// In the app's build.gradle file.
android {
    defaultConfig{
    // Do not configure matchingFallbacks in the defaultConfig block.
    // Instead, you must specify fallbacks for a given product flavor in the
    // productFlavors block, as shown below.
  }
    flavorDimensions 'tier'
    productFlavors {
        paid {
            dimension 'tier'
            // Because the dependency already includes a "paid" flavor in its
            // "tier" dimension, you don't need to provide a list of fallbacks
            // for the "paid" flavor.
        }
        free {
            dimension 'tier'
            // Specifies a sorted list of fallback flavors that the plugin
            // should try to use when a dependency's matching dimension does
            // not include a "free" flavor. You may specify as many
            // fallbacks as you like, and the plugin selects the first flavor
            // that's available in the dependency's "tier" dimension.
            matchingFallbacks = ['demo', 'trial']
        }
    }
}

앱에 없는 버전 차원이 라이브러리 종속성에 포함됩니다.

예를 들어, 라이브러리 종속성에는 'minApi' 차원에 대한 버전이 포함되지만, 앱에는 'tier' 차원에 대한 버전만 포함됩니다. 따라서 'freeDebug' 버전의 앱을 빌드하려는 경우, 플러그인은 'minApi23Debug' 또는 'minApi18Debug' 버전의 종속성 사용 여부를 알지 못합니다.

참고로, 라이브러리 종속성에 없는 버전 차원이 앱에 포함된 경우는 문제가 되지 않습니다. 그 이유는 종속성에 있는 차원만의 버전을 플러그인이 매칭시키기 때문입니다. 예를 들어, ABI에 대한 차원이 종속성에 포함되지 않은 경우, 'freeX86Debug' 버전의 앱은 그냥 'freeDebug' 버전의 종속성을 사용합니다.

defaultConfig 블록의 missingDimensionStrategy를 사용하여, 누락된 각 차원으로부터 플러그인이 선택해야 하는 기본 버전을 지정합니다(아래 샘플 참조). 또한 productFlavors 블록에서 선택한 내용을 재정의할 수 있으며, 이 경우 각 버전은 누락된 차원에 대해 각기 다른 매칭 전략을 지정할 수 있습니다.
// In the app's build.gradle file.
android {
    defaultConfig{
    // Specifies a sorted list of flavors that the plugin should try to use from
    // a given dimension. The following tells the plugin that, when encountering
    // a dependency that includes a "minApi" dimension, it should select the
    // "minApi18" flavor. You can include additional flavor names to provide a
    // sorted list of fallbacks for the dimension.
    missingDimensionStrategy 'minApi', 'minApi18', 'minApi23'
    // You should specify a missingDimensionStrategy property for each
    // dimension that exists in a local dependency but not in your app.
    missingDimensionStrategy 'abi', 'x86', 'arm64'
    }
    flavorDimensions 'tier'
    productFlavors {
        free {
            dimension 'tier'
            // You can override the default selection at the product flavor
            // level by configuring another missingDimensionStrategy property
            // for the "minApi" dimension.
            missingDimensionStrategy 'minApi', 'minApi23', 'minApi18'
        }
        paid {}
    }
}

로컬 모듈의 종속성 구성을 마이그레이션

변형 인식 종속성 해결을 사용하기 위해 버전 차원을 적절히 구성했다면, 로컬 모듈 종속성에 대해 변형별 구성(예: redDebugImplementation)을 사용할 필요가 없으며 플러그인이 알아서 처리해 줍니다. 변형별 구성을 사용하는 것은 선택 사항이며 빌드를 손상시키지 않습니다.

그러나 특정 변형의 로컬 모듈 종속성을 대상으로 하는 경우에는(예: configuration: 'debug' 사용) 다음과 같은 빌드 오류가 발생할 수 있습니다.

Error:Could not resolve all dependencies for configuration
  ':app:prodDebugCompileClasspath'.
Project :app declares a dependency from configuration 'compile'
  to configuration 'debug' which is not declared in the descriptor
  for project :foo.

그 대신 다음과 같이 종속성을 구성해야 합니다.

dependencies {
    // This is the old method and no longer works for local
    // library modules:
    // debugCompile project(path: ':foo', configuration: 'debug')
    // releaseCompile project(path: ':foo', configuration: 'release')

    // Instead, simply use the following to take advantage of
    // variant-aware dependency resolution. You can learn more about
    // the 'implementation' configuration in the section about
    // new dependency configurations.
    implementation project(':foo')

    // You can, however, keep using variant-specific configurations when
    // targeting external dependencies. The following line adds 'app-magic'
    // as a dependency to only the 'debug' version of your module.

    debugImplementation 'com.example.android:app-magic:12.3'
}

참고: 수동 변형 종속성을 위한 오래된 메커니즘은 더 이상 쉽게 사용할 수 없으며 아직 Gradle API가 있더라도 마찬가지입니다. 이제 project() DSL에 제공된 구성에서는 빌드 유형과 버전(및 기타 속성)에서 소비자를 매칭시켜야 합니다. 예를 들어, 생산자와 소비자가 매칭되지 않기 때문에 이 메커니즘을 통해서는 'debug' 변형이 'release' 변형을 사용하도록 만드는 것이 불가능합니다. (이 경우, 'debug'라는 이름은 종속성 게시 섹션에 언급된 게시된 구성 객체를 나타냅니다.) 이제는 컴파일용 구성과 런타임용 구성의 두 가지 구성이 게시되므로, 하나의 구성을 선택하는 이전 방법은 더 이상 작동하지 않습니다.

Wear 앱 종속성 구성

삽입된 Wear 앱에 대해서 변형 인식 종속성 해결을 지원하기 위해 이제 플러그인 3.0.0에서는 해결 전에 모든 그래프를 서로 조합하며, 이것은 다른 종속성들이 처리되는 방식과 유사합니다. 이전 버전의 플러그인에서는 <component>WearApp 종속성 그래프가 개별적으로 해결되었습니다. 예를 들어, 다음과 같은 동작을 수행할 수 있으며, 이 때 파란색 변형은 :wear2를 사용하고 기타 모든 변형은 :wear1을 사용할 것입니다.

dependencies {
    // This is the old way of configuring Wear App dependencies.
    wearApp project(':wear1')
    blueWearApp project(':wear2')
}

위의 구성은 새 플러그인에서 더 이상 작동하지 않습니다. 그러나 웨어러블 모듈이 기본 앱과 동일한 버전을 구성하는 경우에는, <flavor>WearApp 구성을 사용할 필요가 없습니다. wearApp 구성을 지정하기만 하면 기본 앱의 각 변형에서는 매칭되는 변형을 wearable로부터 사용할 것입니다.

dependencies {
    // If the main app and wearable modules have the same flavors,
    // the following configuration uses automatic dependency matching.
    wearApp  project(':wearable')
}

앱 버전에 따라 각기 다른 Wear 앱 모듈을 지정하려는 경우에도 여전히 다음과 같이 <flavor>WearApp 구성을 사용할 수 있지만, wearApp 구성과 조합될 수는 없습니다.

dependencies {
    redWearApp project(':wear1')
    greenWearApp project(':wear1')
    blueWearApp project(':wear2')
}

새로운 종속성 구성 사용

Gradle 3.4에서는 새로운 Java 라이브러리 플러그인 구성을 도입했습니다. 이 구성에서는 (모듈 간 종속성을 위해) 컴파일 및 런타임 클래스 경로에 대한 게시를 제어할 수 있습니다. Android 플러그인 3.0.0은 이와 같은 새로운 종속성 구성으로 이전하고 있습니다. 프로젝트를 마이그레이션하려면, 지원 중단된 구성 대신 새로운 구성을 사용하도록 종속성을 업데이트하기만 하면 됩니다(아래 표에 요약).

새 구성 지원 중단된 구성 동작
implementation compile 컴파일 타임에는 모듈에 종속성을 사용할 수 있으며, 런타임에만 모듈 소비자에게 종속성을 사용할 수 있습니다. 대규모의 다중 프로젝트 빌드에서 api/compile 대신 implementation을 사용하면 빌드 시스템이 재컴파일해야 하는 프로젝트의 크기가 줄어들기 때문에 빌드 시간이 상당히 개선될 수 있습니다. 대부분의 앱과 테스트 모듈은 이 구성을 사용해야 합니다.
api compile 컴파일 타임에는 모듈에 종속성을 사용할 수 있으며, 컴파일 타임과 런타임에는 모듈 소비자에게도 종속성을 사용할 수 있습니다. 이 구성은 compile(지금은 지원 중단됨)과 마찬가지로 동작하며 일반적으로 이 구성은 라이브러리 모듈에서만 사용해야 합니다. API를 별도 테스트 모듈에 노출시키지 않으려면, 앱 모듈이 implementation을 사용해야 합니다.
compileOnly provided 컴파일 타임에만 모듈에 종속성을 사용할 수 있으며, 컴파일 타임이나 런타임에는 소비자에게 종속성을 사용할 수 없습니다. 이 구성은 provided와 마찬가지로 동작합니다(지금은 지원 중단됨).
runtimeOnly apk 런타임에만 모듈과 모듈 소비자에게 종속성을 사용할 수 있습니다. 이 구성은 apk와 마찬가지로 동작합니다(지금은 지원 중단됨).

안정된 최신 버전의 Android 플러그인과 마찬가지로 위의 구성은 버전별 또는 빌드 유형별 종속성에 사용될 수 있습니다. 예를 들어, api를 사용하여 모든 변형에 종속성을 사용하도록 만들거나,redApi를 사용하여 모듈의 red 변형에만 종속성을 사용하도록 만들 수 있습니다.

참고: compile, providedapk은 현재도 여전히 사용할 수 있습니다. 그러나 Android 플러그인의 향후 주요 릴리스에서는 사라질 것입니다.

종속성 게시

다음 구성에서는 소비자의 소비를 위해 라이브러리의 이행성 종속성을 유지합니다.

이전에는 다음과 같은 변형별 단일 구성이 있었습니다: <variant>. 이제 라이브러리는 컴파일 시 소비자에게 무엇이 보이는지 제어하기 위해 이전 섹션에 설명된 implementationapi 구성을 사용할 수 있기 때문에, 이제는 소비자의 컴파일용 구성과 런타임용 구성의 두 가지 구성이 있습니다.

다양한 구성들의 관계에 대해 자세히 알아보려면 Java 라이브러리 플러그인 구성으로 이동하세요.

사용자설정 종속성 해결 전략을 마이그레이션

플러그인에서는 다음과 같은 구성을 사용하여 특정 변형의 모든 종속성을 해결합니다.

오래된 구성을 여전히 사용하는 경우 다음과 유사한 빌드 오류가 발생합니다.

Error:Configuration with old name _debugCompile found.
Use new name debugCompileClasspath instead.

해결된 구성상에서 해결 전략을 수립하는 플러그인이나 빌드 파일은 새로운 이름에 맞게 변경되어야 합니다. 지연된 종속성 해결 덕분에 이제는 변형 API를 사용하는 중에 해결 전략을 수립할 수 있습니다(아래 예시 참조). (이제 Android 플러그인에는 특정 변형의 구성 객체에 액세스하는 getter가 포함됩니다.)

// Previously, you had to apply a custom resolution strategy during the
// configuration phase, rather than in the execution phase. That's
// because, by the time the variant was created and the Variant API was
// called, the dependencies were already resolved. This no longer works, and
// you should use this method only while using an older version of the plugin.
// configurations {
//     _debugCompile
//     _debugApk
// }
// ...
//
// configurations._debugCompile.resolutionStrategy {
//     ...
// }
//
// configurations.all {
//     resolutionStrategy {
//     ...
//     }
// }

// Because the new build model delays dependency resolution, you should
// query and modify the resolution strategy using the Variant API.
android {
    applicationVariants.all { variant ->
        variant.getCompileConfiguration().resolutionStrategy {
            ...
        }
        variant.runtimeConfiguration.resolutionStrategy {
            ...
        }
        variant.getAnnotationProcessorConfiguration().resolutionStrategy {
            ...
        }
    }
}

참고: 현재는 새 플러그인이 오래된 이름을 사용하여 구성을 찾고 있으며, 구성을 찾는다면 플러그인이 실패할 것입니다. 아니면 플러그인이 사용자설정 해결 전략을 자동으로 무시할 것입니다. 우리가 피드백에 따라 이것을 변경할 수도 있지만 그보다는 원활한 마이그레이션을 위한 방법을 찾아내고 싶습니다.

주석 프로세서 종속성 구성 사용

이전 버전의 Gradle용 Android 플러그인에서는 컴파일 클래스 경로상의 종속성이 프로세서 클래스 경로에 자동으로 추가되었습니다. 즉, 주석 프로세서를 컴파일 클래스 경로에 추가할 수 있으며 예상대로 작동할 것입니다. 그러나 이 경우 대량의 불필요한 종속성이 프로세서에 추가되어 성능에 상당한 영향을 미칩니다.

새로운 플러그인을 사용할 경우, annotationProcessor 종속성 구성을 사용하여 주석 프로세서를 프로세서 클래스 경로에 추가해야 합니다(아래 참조).

dependencies {
    ...
    annotationProcessor 'com.google.dagger:dagger-compiler:<version-number>'
}

JAR 파일에 META- INF/services/javax.annotation.processing.Processor 파일이 포함된 경우 플러그인은 그 종속성이 주석 프로세서라고 가정합니다. 플러그인이 컴파일 클래스 경로에서 주석 프로세서를 감지하는 경우 빌드는 실패하며, 컴파일 클래스 경로상의 각 주석 프로세서가 나열된 오류 메시지가 발생합니다. 이 오류를 수정하려면 annotationProcessor를 사용하도록 해당 종속성의 구성을 변경하면 됩니다. 컴파일 클래스 경로상에도 있어야 하는 구성 요소가 종속성에 포함된 경우에는, 이 종속성을 두 번째 선언하고 compile 종속성 구성을 사용합니다.

android-apt 플러그인 사용자: 현재는 이 동작이 android-apt 플러그인에 영향을 미치지 않습니다. 그러나 향후 버전의 Gradle용 Android 플러그인과 플러그인이 호환되지 않을 것입니다.

오류 검사 비활성화

불필요한 주석 프로세서를 포함하는 종속성이 컴파일 클래스 경로상에 있는 경우, 다음 코드를 build.gradle 파일에 추가하여 오류 검사를 비활성화할 수 있습니다. 명심할 점은, 컴파일 클래스 경로에 추가되는 주석 프로세서는 여전히 프로세서 클래스 경로에 추가되지 않습니다.

android {
    ...
    defaultConfig {
        ...
        javaCompileOptions {
            annotationProcessorOptions {
                includeCompileClasspath false
            }
        }
    }
}

새로운 종속성 해결 전략으로 마이그레이션하는 중에 문제가 발생하면 , includeCompileClasspath true를 설정하여 Android 플러그인 2.3으로 동작을 복원할 수 있습니다. 그러나 동작을 버전 2.3으로 복원하는 것은 권장하지 않으며, 이를 위한 옵션은 향후 업데이트에서 제거될 것입니다. 여러분이 사용 중인 종속성과의 호환성을 우리가 개선할 수 있도록 버그를 제출해 주세요.

별도 테스트 모듈 사용

플러그인 3.0.0을 사용할 경우 이제 별도 테스트 모듈이 변형을 인식합니다(위의 섹션 참조). 즉, 더 이상 targetVariant를 지정할 필요가 없습니다.

테스트 모듈의 각 변형은 대상 프로젝트에서 매칭되는 변형을 테스트하려고 시도합니다. 기본적으로 테스트 모듈에는 debug 변형만 포함되지만, 테스트되는 앱 프로젝트와 매칭되는 새 변형을 만들기 위해 새 빌드 유형과 새 버전을 만들 수 있습니다. 각 변형에 대해 하나의 connectedCheck 작업이 생성됩니다.

다른 빌드 유형만을 Test 프로젝트가 테스트하도록 만들려면, VariantFilter를 사용하여 debug 변형을 테스트 프로젝트에서 비활성화합니다(아래 참조).

android {
    variantFilter { variant ->
        if (variant.buildType.name.equals('debug') {
            variant.setIgnore(true);
        }
    }
}

특정 버전의 앱 변형만을 대상으로 하는 테스트 모듈을 만들려면, flavorSelection 속성을 사용하여 테스트하려는 대상 버전을 지정할 수 있습니다. 이렇게 하면 테스트 모듈이 해당 버전을 직접 구성할 필요가 없습니다.

라이브러리에 있는 로컬 JAR 파일

이전에는 로컬 JAR 파일상의 종속성을 처리하기 위해 라이브러리 모듈이 비표준적인 방식을 사용했으며 종속성을 AAR 내에 패키징하고 했습니다. 심지어 다중 프로젝트 빌드에서도 AAR의 소비자는 패키지 버전을 통해 이러한 JAR 파일을 확인하곤 했습니다.

Android 플러그인 3.0.0 이상에서는 새로운 Gradle API를 사용하기 때문에 소비 프로젝트는 이러한 로컬 JAR 파일을 일반적인 이행성 종속성으로 볼 수 있으며, 이것은 Maven 좌표 종속성과 유사합니다. 새로운 Gradle API에 맞추기 위해, 플러그인은 로컬 JAR 파일의 처리 방식을 몇 가지 측면에서 변경해야 했습니다.

프로젝트 간 게시

Maven 리포지토리에 게시

API 변경 사항

Android 플러그인 3.0.0에 소개된 API 변경 사항은 특정한 기능을 제거하며 또한 기존 빌드를 손상시킬 수도 있습니다. 향후 버전의 플러그인에서는 손상된 기능을 대체하는 새로운 공개 API가 소개될 수도 있습니다.

변형 출력

변형 API를 사용하여 변형 출력을 조작하는 기능은 새로운 플러그인에서 손상됩니다. 그러나 빌드 시간 중에 APK 이름을 변경하는 등의 간단한 작업은 여전히 작동합니다.

// If you use each() to iterate through the variant objects,
// you need to start using all(). That's because each() iterates
// through only the objects that already exist during configuration time—
// but those object don't exist at configuration time with the new model.
// However, all() adapts to the new model by picking up object as they are
// added during execution.
android.applicationVariants.all { variant ->
    variant.outputs.all {
        outputFileName = "${variant.name}-${variant.versionName}.apk"
    }
}

그러나 outputFile 객체 액세스가 관련되는 보다 복잡한 작업은 작동하지 않습니다. 그 이유는 구성 단계에서 변형별 작업이 더 이상 생성되지 않기 때문입니다. 그 결과, 플러그인이 모든 출력을 미리 다 알지는 못하지만 구성 시간은 더 빨라집니다.

manifestOutputFile

processManifest.manifestOutputFile() 메서드는 더 이상 사용할 수 없으며, 호출을 시도하면 다음과 같은 오류가 발생합니다.

A problem occurred configuring project ':myapp'.
   Could not get unknown property 'manifestOutputFile' for task ':myapp:processDebugManifest'
   of type com.android.build.gradle.tasks.ProcessManifest.

각 변형의 매니페스트 파일을 가져오기 위해 manifestOutputFile()을 호출하는 대신, 생성된 모든 매니페스트가 포함된 디렉토리의 경로를 반환하기 위해 processManifest.manifestOutputDirectory()를 호출할 수 있습니다. 그런 다음, 매니페스트를 찾아 여기에 로직을 적용합니다. 아래 샘플은 매니페스트에서 버전 코드를 동적으로 변경합니다.

android.applicationVariants.all { variant ->
    variant.outputs.all { output ->
        output.processManifest.doLast {
            // Stores the path to the maifest.
            String manifestPath = "$manifestOutputDirectory/AndroidManifest.xml"
            // Stores the contents of the manifest.
            def manifestContent = file(manifestPath).getText()
            // Changes the version code in the stored text.
            manifestContent = manifestContent.replace('android:versionCode="1"',
                    String.format('android:versionCode="%s"', generatedCode))
            // Overwrites the manifest with the new text.
            file(manifestPath).write(manifestContent)
        }
    }
}
This site uses cookies to store your preferences for site-specific language and display options.

Get the latest Android developer news and tips that will help you find success on Google Play.

* Required Fields

Hooray!

WeChat에서 Google Developers 팔로우하기

Browse this site in ?

You requested a page in , but your language preference for this site is .

Would you like to change your language preference and browse this site in ? If you want to change your language preference later, use the language menu at the bottom of each page.

This class requires API level or higher

This doc is hidden because your selected API level for the documentation is . You can change the documentation API level with the selector above the left navigation.

For more information about specifying the API level your app requires, read Supporting Different Platform Versions.

Take a short survey?
Help us improve the Android developer experience. (Dec 2017 Android Platform & Tools Survey)