lightbulb_outline Please take our October 2018 developer survey. Start survey

Android Plugin for Gradle 3.0.0 への移行

既知の問題点: Android プラグイン 3.0.0 のアルファ版(3.0.0-alpha9 など)を使用している既存の Android Studio プロジェクトがある場合は、Android プラグイン 3.0.0-beta4 に移行して プロジェクトを同期する際に、次のエラーが発生する可能性があります。 Gradle project refresh failed.

この問題を修正するには、メニューバーで [Build] > [Clean Project] を選択します。この操作はプロジェクトごとに 1 回だけ必要です。 その後は、メニューバーから [Sync Project] をクリックすると、Gradle でプロジェクト ファイルを同期できます。

既存のプロジェクトを Android プラグイン 3.0.0-beta4 以上に移行する場合は、このページでプラグインの適用方法や具体的な Gradle バージョンを確認して、大きな変更に適応できるようにしてください。

Gradle バージョンのアップデート

新しい Android プラグインにはバージョン 4.1-rc-1 以上の Gradle が必要です。 Android Studio 3.0 Beta 1 以降で既存プロジェクトを開いている場合は、画面の指示に従って操作すると、互換性のあるバージョンの Gradle が使われるよう既存プロジェクトが自動でアップデートされます。

手動で Gradle をアップデートするには、次のように gradle-wrapper.properties の URL を変更します。

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

プラグインの適用

Android Studio 3.0 Beta 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'
    }
}

フレーバー ディメンションによるバリアントを識別した依存関係の管理

プラグイン 3.0.0 に含まれる新しい依存関係メカニズムでは、ライブラリの使用時に自動でバリアントのマッチングを行います。 よって、アプリの debug バリアントによって自動的にライブラリの debug バリアントが使われます。 これはフレーバーの使用時にも当てはまるため、アプリの 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" というビルドタイプを設定しているにもかかわらず、その依存ライブラリの 1 つに "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" バリアントを使うようなことはできません。生成側と使用側が一致しないためです。 (この場合、上述の Publishing Dependencies のセクションで説明したように、"debug" という名称は公開済みのコンフィグレーション オブジェクトを意味します。) 現在はコンパイル用とランタイム用の 2 つのコンフィグレーションが公開されているため、以前のように 1 つのコンフィグレーションを選択する方法は機能しません。

Wear アプリの依存関係の設定

バリアント判別による依存関係の解決法を埋め込みの Wear アプリ向けにサポートするため、プラグイン 3.0.0 では解決前にすべてのグラフを統合します。これは他の依存関係の処理方法と同様です。 旧バージョンのプラグインでは、<component>WearApp の依存関係グラフは個別に解決されていました。 たとえば次のように、blue バリアントでは :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 バリアントでのみ利用可能にすることも可能です。

注: compileprovidedapk は 現在も利用可能です。 ただし、これらは Android プラグインの次期メジャー リリースでは削除されます。

依存ファイルの公開

次のコンフィグレーションには、使用側における推移的なライブラリ依存関係が含まれます。

  • <variant>ApiElements
  • <variant>RuntimeElements

以前は、バリアントに対して <variant> という単一のコンフィグレーションしかありませんでした。 現在は上記のセクションの説明にあるように、ライブラリで implementationapi を使うとコンパイル時に使用側で見えるものを制御できるため、使用側のコンパイル用とランタイム用に 2 つのコンフィグレーションがあります。

異なるコンフィグレーションの関係についてはJava ライブラリ プラグイン コンフィグレーションのページで詳細をご確認ください。

カスタム依存関係の解決方針の移行

プラグインでは次のコンフィグレーションを使用して、バリアントのすべての依存関係を解決しています。

  • <variant>CompileClasspath (_<variant>Compile 既に廃止)
  • <variant>RuntimeClasspath (_<variant>Apk 既に廃止)

まだ以前のコンフィグレーションを使用している場合は、次のようなビルドエラーが発生します。

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

プラグインやビルドファイルで、古いコンフィグレーションに対して解決方針を指定している場合は、新しい名前に変更する必要があります。 現在は依存関係の遅延解決が可能なので、次の例に示すようにバリアント API を使用して解決方針を設定することができます。 (現在 Android プラグインには、バリアントのコンフィグレーション オブジェクトにアクセスするためのゲッターが含まれています。)

// 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 {
            ...
        }
    }
}

注: 現在、新しいプラグインでは古い名前を使用したコンフィグレーションを検索し、検出した場合はエラーを発生させます。 または特に反応はせず、そのカスタム解決方針を無視します。 この動作はフィードバックに応じて変更する可能性がありますが、簡単に移行できる方法を採用したいと考えています。

アノテーション プロセッサの依存関係コンフィグレーションの使用

旧バージョンの Android plugin for Gradle では、コンパイル クラスパスの依存関係は自動でプロセッサ クラスパスに追加されていました。 つまり、アノテーション プロセッサをコンパイル クラスパスに追加して、期待どおりに動作させることが可能でした。 ただし、この場合は膨大な量の不要な依存関係をプロセッサに追加するため、パフォーマンスに大きな影響が生じます。

新しいプラグインを使用する場合は、次のように annotationProcessor 依存関係コンフィグレーションを使用して、アノテーション プロセッサをプロセッサ クラスパスに追加する必要があります。

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

JAR ファイルに META- INF/services/javax.annotation.processing.Processor. というファイルが含まれる場合、プラグインではアノテーション プロセッサに依存していると見なします。プラグインがコンパイル クラスパスでアノテーション プロセッサを検出するとビルドが失敗して、エラー メッセージにコンパイル クラスパスにある各アノテーション プロセッサの一覧が表示されます。 このエラーを修正するには、単純にそれらの依存関係のコンフィグレーションを変更して annotationProcessor を使うようにします。 依存関係に、コンパイル クラスパスに必要なコンポーネントも含まれている場合は、その依存関係を 2 回宣言して compile 依存関係コンフィグレーションを使用します。

android-apt プラグインユーザー向け: 現在、この動作変更による android-apt プラグインへの影響はありません。 ただし、以降の Android Plugin for Gradle バージョンでは、このプラグインとの互換性がなくなります。

エラーチェックの無効化

コンパイル クラスパスの依存関係に不要なアノテーション プロセッサが含まれている場合は、build.gradle ファイルに次の内容を追加するとエラーチェックを無効にできます。 コンパイル クラスパスに追加するアノテーション プロセッサは、まだプロセッサクラスパスに追加されていない点に注意してください。

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

新しい依存関係の解決方針に移行するにあたって不具合が生じている場合は、includeCompileClasspath true を設定すると Android プラグイン 2.3 の動作に戻すことができます。 ただし、バージョン 2.3 への復元はお勧めしません。また、この復元オプションは以降のアップデートで削除します。 使用中の依存ファイルとの互換性向上のために、バグの登録をお願いいたします。

分離されたテスト モジュールの使用

プラグイン 3.0.0 を使用している場合、現在は分離されたテスト モジュールでバリアントを判別します。つまり targetVariant を指定する必要はありません。

テスト モジュールに含まれる各バリアントは、ターゲット プロジェクトに存在する対応するバリアントのテストを試みます。 デフォルトではテスト モジュールには debug バリアントしか含まれていませんが、新しいビルドタイプとフレーバーを作成し、テスト対象のアプリ プロジェクトに対応するよう新たにバリアントを作成することができます。 connectedCheck タスクはバリアントごとに作成されます。

Test プロジェクト テストを debug ではなく、別のビルドタイプに限定したい場合は、次のように 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 ファイルの処理方法が以下のように変更されました。

プロジェクト間の公開

  • ライブラリ モジュールではローカル JAR の処理を行わなくなりました。 これにより、ライブラリ モジュールのコード変更によって生じる増分ビルドが高速化されます。

  • ライブラリ モジュールの変換は、現在 PROJECT スコープにのみ影響を及ぼします。 PROJECT_LOCAL_DEPS スコープは廃止されたため、このスコープを使って変換を施すと失敗します。

  • ローカル JAR が EXTERNAL ストリームに含まれるアプリ モジュールの場合は、PROJECT_LOCAL_DEPS および SUB_PROJECT_LOCAL_DEPS ストリームは常に空になります。

  • 現在はローカル ライブラリ モジュールに対して ProGuard を有効にしても、ライブラリのコードには効果がありません。 代わりに最終版のアプリ モジュールに ProGuard を適用してください。

  • 以前は、ライブラリ モジュールとそのローカル JAR の依存先との間の Java リソース競合は、ライブラリ モジュールで解決する必要がありました。 現在はライブラリ モジュールでローカル JAR の処理は行わないため、この競合はライブラリを使用するアプリ側で解決しなければなりません。

Maven リポジトリへの公開

  • Maven リポジトリへの公開に関しては、特に変更はありません。 ローカル JAR はバンドルされ、非クラス リソースは AAR のメイン JAR ファイルにマージされます。 モジュールで ProGuard を有効にすると、すべての JAR がメイン JAR ファイルにマージされます。

API の変更

Android プラグイン 3.0.0 で導入された API 変更には特定の機能を削除する変更が含まれているため、既存のビルドが失敗する恐れがあります。 今後のプラグイン バージョンでは、利用不可となった機能の代わりとなる新しい公開 API を導入する可能性があります。

バリアント出力

新しいプラグインでは、Variant 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)
        }
    }
}