Android Gradle プラグイン 4.0.0（2020 年 4 月）

このバージョンの Android プラグインには、次のものが必要です。

• Gradle 6.1.1。詳細については、Gradle のアップデートに関するセクションをご覧ください。

• SDK Build Tools 29.0.2 以降。

新機能

このバージョンの Android Gradle プラグインには、次の新機能が含まれています。

Android Studio Build Analyzer のサポート

Build Analyzer ウィンドウは、最適化の無効化やタスクの不適切な構成など、ビルドプロセスの問題を理解して診断するうえで有益です。この機能は、Android Studio 4.0 以降と Android Gradle プラグイン 4.0.0 以降を併用している場合に利用できます。Android Studio では、次の手順で [Build Analyzer] ウィンドウを開くことができます。

1. まだアプリのビルドを行っていない場合は、メニューバーから [Build] > [Make Project] を選択してアプリをビルドします。
2. メニューバーから [View] > [Tool Windows] > [Build] を選択します。
3. [Build] ウィンドウで、次のいずれかの方法で [Build Analyzer] ウィンドウを開きます。
   • Android Studio でプロジェクトのビルドが完了したら、[Build Analyzer] タブをクリックします。
   • Android Studio でプロジェクトのビルドが完了したら、[Build Output] ウィンドウの右側のリンクをクリックします。

[Build Analyzer] ウィンドウの左側のツリーには、起こり得るビルドの問題がまとめられます。各問題をクリックすると、右側のペインで詳細を調べることができます。Android Studio を使ってビルドを分析すると、ビルド時間を決定付けたタスクセットを求め、各タスクの影響を可視化して把握しやすいようにできます。[Warnings] ノードを展開して、警告の詳細を確認することもできます。

詳細については、ビルド速度の低下を特定するをご覧ください。

Java 8 ライブラリの脱糖が含まれる D8 と R8

Android Gradle プラグインでは、アプリの最小 API レベルを必要とせずに、多数の Java 8 言語 API の使用がサポートされています。

「脱糖」と呼ばれるプロセスにより、Android Studio 3.0 以降の DEX コンパイラ D8 はすでに、Java 8 言語機能（ラムダ式、デフォルトのインターフェース メソッド、リソースの試用など）の実質的なサポートを提供しています。Android Studio 4.0 では脱糖エンジンが拡張され、Java 言語 API を脱糖できるようになりました。つまり、最近の Android でしか使用できなかった標準的な言語 API（java.util.streams など）を古いバージョンの Android アプリでも使用できるようになりました。

このリリースでは次の API がサポートされています。

• 連続ストリーム（java.util.stream）
• java.time のサブセット
• java.util.function
• java.util.{Map,Collection,Comparator} の最新の追加 API
• オプション（java.util.Optional、java.util.OptionalInt、java.util.OptionalDouble）および上記の API で役立つその他の新しいクラス
• java.util.concurrent.atomic の追加 API（AtomicInteger、AtomicLong、AtomicReference の新しいメソッド）
• ConcurrentHashMap（Android 5.0 のバグを修正）

上記言語 API のサポートのため、D8 は不足している API の実装を含む単独のライブラリ DEX ファイルをコンパイルし、この実装をアプリに追加します。脱糖プロセスはアプリのコードを書き換えて、ランタイム時に代わりにこのライブラリを使用するようにします。

このような言語 API のサポートを有効にするには、アプリ モジュールの build.gradle ファイルに以下を記述します。

android {
  defaultConfig {
    // Required when setting minSdkVersion to 20 or lower
    multiDexEnabled true
  }


compileOptions {
    // Flag to enable support for the new language APIs
    coreLibraryDesugaringEnabled true
    // Sets Java compatibility to Java 8
    sourceCompatibility JavaVersion.VERSION_1_8
    targetCompatibility JavaVersion.VERSION_1_8
  }
}

dependencies {
  coreLibraryDesugaring 'com.android.tools:desugar_jdk_libs:1.0.4'
}

android {
  defaultConfig {
    // Required when setting minSdkVersion to 20 or lower
    multiDexEnabled = true
  }


compileOptions {
    // Flag to enable support for the new language APIs
    isCoreLibraryDesugaringEnabled = true
    // Sets Java compatibility to Java 8
    sourceCompatibility = JavaVersion.VERSION_1_8
    targetCompatibility = JavaVersion.VERSION_1_8
  }
}

dependencies {
  coreLibraryDesugaring("com.android.tools:desugar_jdk_libs:1.0.4")
}

また、次の場合は、ライブラリ モジュールの build.gradle ファイルにも上記のコード スニペットを含める必要があります。

• ライブラリ モジュールのインストルメンテーション テストで、このような言語 API を直接使用するか、ライブラリ モジュールまたはその依存関係を通じて使用する場合。これは、インストルメンテーション テスト APK を実行するために不足している API を提供する場合に行います。

• ライブラリ モジュールの lint を単独で実行する場合。これは、lint が言語 API が有効に使用されていることを認識し、誤った警告を報告しないようにするために行います。

ビルド機能を有効または無効にする新しいオプション

Android Gradle プラグイン 4.0.0 では、ビュー バインディングやデータ バインディングなど、有効または無効にするビルド機能を新しい方法で制御できます。新しい機能が追加されると、デフォルトで無効になります。その場合は、buildFeatures ブロックを使用して、必要な機能のみを有効にできます。これにより、プロジェクトのビルド パフォーマンスを最適化できます。各モジュールのオプションは、モジュール レベルの build.gradle ファイルで次のように設定できます。

android {
  // The default value for each feature is shown below. You can change the value to
  // override the default behavior.
  buildFeatures {
    // Determines whether to generate a BuildConfig class.
    buildConfig = true
    // Determines whether to support View Binding.
    // Note that the viewBinding.enabled property is now deprecated.
    viewBinding = false
    // Determines whether to support Data Binding.
    // Note that the dataBinding.enabled property is now deprecated.
    dataBinding = false
    // Determines whether to generate binder classes for your AIDL files.
    aidl = true
    // Determines whether to support RenderScript.
    renderScript = true
    // Determines whether to support injecting custom variables into the module’s R class.
    resValues = true
    // Determines whether to support shader AOT compilation.
    shaders = true
  }
}

android {
  // The default value for each feature is shown below. You can change the value to
  // override the default behavior.
  buildFeatures {
    // Determines whether to generate a BuildConfig class.
    buildConfig = true
    // Determines whether to support View Binding.
    // Note that the viewBinding.enabled property is now deprecated.
    viewBinding = false
    // Determines whether to support Data Binding.
    // Note that the dataBinding.enabled property is now deprecated.
    dataBinding = false
    // Determines whether to generate binder classes for your AIDL files.
    aidl = true
    // Determines whether to support RenderScript.
    renderScript = true
    // Determines whether to support injecting custom variables into the module’s R class.
    resValues = true
    // Determines whether to support shader AOT compilation.
    shaders = true
  }
}

以下に示すように、プロジェクトのすべてのモジュールでこのような機能のデフォルト設定を指定することもできます。これには、プロジェクトの gradle.properties ファイルに次のうち 1 つ以上を指定します。ただし、モジュール レベルの build.gradle ファイルで buildFeatures ブロックを使用すると、これらのプロジェクト全体のデフォルト設定をオーバーライドできます。

android.defaults.buildfeatures.buildconfig=true
android.defaults.buildfeatures.aidl=true
android.defaults.buildfeatures.renderscript=true
android.defaults.buildfeatures.resvalues=true
android.defaults.buildfeatures.shaders=true

Feature-on-Feature 依存関係

以前のバージョンの Android Gradle プラグインでは、すべての機能モジュールがアプリのベース モジュールのみに依存していました。Android Gradle プラグイン 4.0.0 を使用する場合、別の機能モジュールに依存する機能モジュールを含めることができるようになりました。つまり、以下の図に示すとおり、:video 機能は、ベース モジュールに依存する :camera 機能に依存することが可能です。

機能モジュール :video は、ベース :app モジュールに依存する機能 :camera に依存します。

つまり、アプリによって機能モジュールのダウンロードがリクエストされると、その機能モジュールが依存する他の機能モジュールもダウンロードされます。アプリの機能モジュールを作成した後、モジュールの build.gradle ファイルで Feature-on-Feature 依存関係を宣言できます。たとえば、:video モジュールで :camera に対する依存関係を宣言する場合、次のようになります。

// In the build.gradle file of the ':video' module.
dependencies {
  // All feature modules must declare a dependency
  // on the base module.
  implementation project(':app')
  // Declares that this module also depends on the 'camera'
  // feature module.
  implementation project(':camera')
  ...
}

// In the build.gradle file of the ':video' module.
dependencies {
    // All feature modules must declare a dependency
    // on the base module.
    implementation(project(":app"))
    // Declares that this module also depends on the 'camera'
    // feature module.
    implementation(project(":camera"))
    ...
}

また、メニューバーから [Help] > [Edit Custom VM Options] をクリックして以下の行を含め、Android Studio の Feature-on-Feature 依存関係機能を有効にする必要があります（たとえば、実行構成の編集時にこの機能をサポートするため）。

-Drundebug.feature.on.feature=true

依存関係のメタデータ

Android Gradle プラグイン 4.0.0 以降を使用してアプリをビルドする場合、アプリにコンパイルされる依存関係を記述するメタデータがプラグインに含まれます。アプリをアップロードすると、Play Console でこのメタデータが検査され、次のようなメリットがあります。

• アプリで使用する SDK と依存関係に関する既知の問題のアラートを取得する
• これらの問題を解決するための実用的なフィードバックを受け取る

データは圧縮され、Google Play の署名鍵で暗号化され、リリースアプリの署名ブロックに保存されます。ただし、ディレクトリ <project>/<module>/build/outputs/sdk-dependencies/release/sdkDependency.txt のローカル中間ビルドファイルでは自分でメタデータを検査できます。

この情報を共有したくない場合は、モジュールの build.gradle ファイルに次の情報を含めることでオプトアウトできます。

android {
  dependenciesInfo {
      // Disables dependency metadata when building APKs.
      includeInApk = false
      // Disables dependency metadata when building Android App Bundles.
      includeInBundle = false
  }
}

android {
  dependenciesInfo {
      // Disables dependency metadata when building APKs.
      includeInApk = false
      // Disables dependency metadata when building Android App Bundles.
      includeInBundle = false
  }
}

AAR 依存関係からネイティブ ライブラリをインポートする

アプリの AAR 依存関係から C / C++ ライブラリをインポートできるようになりました。以下で説明する構成手順に従うと、Gradle により自動的にこれらのネイティブ ライブラリが CMake などの外部ネイティブ ビルドシステムで使用できるようになります。Gradle はこれらのライブラリをビルドで使用できるようにするだけなので、これらを使用するには、ビルド スクリプトを構成する必要があります。

ライブラリは、Prefab パッケージ形式を使用してエクスポートされます。

Prefab パッケージは 1 つ以上のモジュールで構成され、各依存関係は最大 1 つのパッケージを公開できます。Prefab モジュールは単一のライブラリで、共有ライブラリ、静的ライブラリ、ヘッダーのみのライブラリのいずれかになります。

通常、パッケージ名は Maven アーティファクト名と一致し、モジュール名はライブラリ名と一致しますが、常に一致するとは限りません。ライブラリのパッケージとモジュール名を知る必要があるため、依存関係のドキュメントを参照して名前を確認する必要があります。

外部ネイティブ ビルドシステムを構成する

必要な手順を確認するには、使用する予定の外部ネイティブ ビルドシステムの次の手順を行います。

ネイティブ コードを含む、アプリのそれぞれの AAR 依存関係により、Android.mk ファイルが公開されます。このファイルは ndk-build プロジェクトにインポートする必要があります。このファイルをインポートするには、import&endash;module コマンドを使用します。このコマンドは、ndk-build プロジェクトの import&endash;add&endash;path プロパティを使用して指定したパスを検索します。たとえば、アプリで libapp.so を定義し、curl を使用する場合は、Android.mk ファイルに次のコードを含める必要があります。

1. CMake の場合:

   add_library(app SHARED app.cpp)
   
   
   # Add these two lines.
   find_package(curl REQUIRED CONFIG)
   target_link_libraries(app curl::curl)

2. ndk-build の場合:

   include $(CLEAR_VARS)
   LOCAL_MODULE := libapp
   LOCAL_SRC_FILES := app.cpp
   # Link libcurl from the curl AAR.
   LOCAL_SHARED_LIBRARIES := curl
   include $(BUILD_SHARED_LIBRARY)
   
   
   # If you don't expect that your project will be built using versions of the NDK
   # older than r21, you can omit this block.
   ifneq ($(call ndk-major-at-least,21),true)
       $(call import-add-path,$(NDK_GRADLE_INJECTED_IMPORT_PATH))
   endif
   
   # Import all modules that are included in the curl AAR.
   $(call import-module,prefab/curl)

AAR に含まれているネイティブ依存関係は、CMAKE_FIND_ROOT_PATH{: .external} 変数を介して CMake プロジェクトに公開されます。この値は、CMake が呼び出されたときに Gradle によって自動的に設定されるため、ビルドシステムでこの変数を変更する場合は、割り当てるのではなく追加する必要があります。

各依存関係は、CMake ビルドに config-file パッケージ{: .external}を公開します。これは find_package{: .external} コマンドでインポートします。このコマンドで、指定されたパッケージ名とバージョンに一致する config-file パッケージを検索し、ビルドで使用するために定義したターゲットを公開します。たとえば、アプリで libapp.so を定義し curl を使用する場合は、CMakeLists.txt ファイルに次のように記述します。

add_library(app SHARED app.cpp)


# Add these two lines.
find_package(curl REQUIRED CONFIG)
target_link_libraries(app curl::curl)

app.cpp で #include "curl/curl.h" を指定できるようになりました。プロジェクトをビルドすると、外部ネイティブ ビルドシステムによって自動的に、APK または App Bundle の libcurl.so とパッケージ libcurl.so に libapp.so がリンクされます。詳細については、curl prefab のサンプル{:.external}をご覧ください。

動作の変更

このバージョンのプラグインを使用する場合、以下のように動作が変更されます。

v1 / v2 署名設定の更新

signingConfig ブロックのアプリ署名設定の動作が次のように変更されました。

v1 署名

• v1SigningEnabled が明示的に有効にされている場合、AGP は v1 アプリ署名を行います。
• v1SigningEnabled がユーザーによって明示的に無効にされている場合、v1 アプリ署名は行われません。
• ユーザーが v1 署名を明示的に有効にしていない場合、minSdk と targetSdk に基づいて自動的に無効にできます。

v2 署名

• v2SigningEnabled が明示的に有効にされている場合、AGP は v2 アプリ署名を行います。
• v2SigningEnabled がユーザーによって明示的に無効にされている場合、v2 アプリ署名は行われません。
• ユーザーが v2 署名を明示的に有効にしていない場合、targetSdk に基づいて自動的に無効にできます。

この変更により、AGP は、ユーザーが上記のフラグを明示的に有効にしたかどうかに基づいて署名メカニズムを無効にすることにより、ビルドを最適化できます。これより前のリリースでは、v1Signing が明示的に有効にされていても無効になる可能性があり、混乱を招くことがありました。

feature および instantapp Android Gradle プラグインを削除

Android Gradle プラグイン 3.6.0 では、Feature プラグイン（com.android.feature）と Instant App プラグイン（com.android.instantapp）が非推奨になり、Android App Bundle を使用して Instant App のビルドとパッケージ化を行う Dynamic Feature プラグイン（com.android.dynamic-feature）が代わりに使用されるようになりました。

Android Gradle プラグイン 4.0.0 以降では、非推奨になった上記プラグインは完全に削除されています。このため、最新の Android Gradle プラグインを使用するには、Android App Bundle に対応できるように Instant App を移行する必要があります。Instant App を移行すると、App Bundle のメリットを生かして、アプリのモジュール設計を簡素化できます。

注: Android Studio 4.0 以降で削除されたプラグインを使用するプロジェクトを開くには、Android Gradle プラグイン 3.6.0 以前を使用する必要があります。

個別アノテーション処理機能を削除

個別アノテーション処理を専用のタスクに分割する機能は削除されました。このオプションは、Java のみのプロジェクトで非増分アノテーション プロセッサが使用されている場合において、増分 Java コンパイルの維持に使用されていました。有効化には gradle.properties ファイルで android.enableSeparateAnnotationProcessing を true に設定する必要がありましたが、この設定はすでにご利用いただけません。

ビルド パフォーマンスを向上させるには、代わりに増分アノテーション プロセッサを使用するよう移行する必要があります。

includeCompileClasspath の非推奨

Android Gradle プラグインは、コンパイル クラスパスで宣言したアノテーション プロセッサのチェックや追加を行えなくなり、annotationProcessorOptions.includeCompileClasspath DSL プロパティは無効になります。アノテーション プロセッサをコンパイル クラスパスに追加すると、次のエラーが発生することがあります。

Error: Annotation processors must be explicitly declared now.

この問題を解決するには、annotationProcessor 依存関係構成を使用して、build.gradle ファイルにアノテーション プロセッサを含める必要があります。詳細については、アノテーション プロセッサの追加をご覧ください。

CMake が使用するビルド済み依存関係の自動パッケージ化

以前のバージョンの Android Gradle プラグインでは、jniLibs を使用して、CMake 外部ネイティブ ビルドで使用するビルド済みライブラリを明示的にパッケージ化することが求められました。モジュールの src/main/jniLibs ディレクトリ、または build.gradle ファイルに構成されているその他のディレクトリにライブラリが存在する場合もあります。

sourceSets {
  main {
    // The libs directory contains prebuilt libraries that are used by the
    // app's library defined in CMakeLists.txt via an IMPORTED target.
    jniLibs.srcDirs = ['libs']
  }
}

sourceSets {
  main {
    // The libs directory contains prebuilt libraries that are used by the
    // app's library defined in CMakeLists.txt via an IMPORTED target.
    jniLibs.setSrcDirs(listOf("libs"))
  }
}

Android Gradle プラグイン 4.0 では上記の構成は不要になったため、ビルドエラーが発生することがあります。

* What went wrong:
Execution failed for task ':app:mergeDebugNativeLibs'.
  > A failure occurred while executing com.android.build.gradle.internal.tasks.Workers$ActionFacade
    > More than one file was found with OS independent path 'lib/x86/libprebuilt.so'

外部ネイティブ ビルドではそれらのライブラリが自動的にパッケージ化されるため、jniLibs を指定してライブラリを明示的にパッケージ化すると、重複が発生します。ビルドエラーを回避するには、ビルド済みライブラリを jniLibs の外部に移動するか、build.gradle ファイルから jniLibs 構成を削除します。

既知の問題

このセクションでは、Android Gradle プラグイン 4.0.0 に存在する既知の問題について説明します。

Gradle ワーカー メカニズムでの競合状態

Android Gradle プラグイン 4.0 で変更を行うと、Gradle 6.3 以下のバージョンで &endash;&endash;no&endash;daemon を使用したときに競合状態が発生し、ビルドの完了後にビルドがハングすることがあります。

この問題は Gradle 6.4 で修正される予定です。