Gradle のヒントとテクニック

Gradle と Android Plugin for Gradle を使用すると、Android アプリやライブラリを柔軟にコンパイル、ビルド、パッケージ化できます。このページでは、各ビルドを最大限に活用するための有用な情報や設定についてご紹介します。 ビルドを高速化するための詳しい情報については、ビルド速度を最適化するをご覧ください。

Gradle を初めて利用する方は、ビルドを設定するで基本的な内容についてご確認ください。また、このページで使用しているプロパティの詳細については、Android プラグインの DSL リファレンス ドキュメントでもご覧いただけます。

プロジェクトとソースを管理する

ここでは、プロジェクトのモジュールとそのソースを管理するための設定について説明します。プロジェクトとモジュールの作成や管理の詳細については、プロジェクトの概要をご覧ください。

デフォルト ソースセットの設定を変更する

モジュール レベルの build.gradle ファイル内の sourceSets ブロックを使用すると、ソースセットの各コンポーネントのファイルを Gradle が収集する際に参照する場所を変更できます。

android {
  ...
  sourceSets {
    // Encapsulates configurations for the main source set.
    main {
      // Changes the directory for Java sources. The default directory is
      // 'src/main/java'.
      java.srcDirs = ['other/java']

      // When you list multiple directories, Gradle uses all of them to collect
      // sources. You should avoid specifying a directory which is a parent to one
      // or more other directories you specify.
      res.srcDirs = ['other/res1', 'other/res2']

      // For each source set, you can specify only one Android manifest.
      // The following points Gradle to a different manifest for this source set.
      manifest.srcFile 'other/AndroidManifest.xml'
      ...
    }

    // Create additional blocks to configure other source sets.
    androidTest {

      // If all the files for a source set are located under a single root
      // directory, you can specify that directory using the setRoot property.
      // When gathering sources for the source set, Gradle looks only in locations
      // relative to the root directory you specify. For example, after applying
      // the configuration below for the androidTest source set, Gradle looks for
      // Java sources only in the src/tests/java/ directory.
      setRoot 'src/tests'
      ...
    }
  }
}
...

プロジェクト レベルのプロパティを設定する

複数のモジュールを含むプロジェクトの場合は、プロジェクト レベルでプロパティを定義し、それをすべてのモジュールで共有すると便利です。そのためには、トップレベルの build.gradle ファイル内の ext ブロックで、追加のプロパティを定義します。

buildscript {...}
allprojects {...}

// This block encapsulates custom properties and makes them available to all
// modules in the project.
ext {
    // The following are only a few examples of the types of properties you can define.
    compileSdkVersion = 28
    // You can also use this to specify versions for dependencies. Having consistent
    // versions between modules can avoid behavior conflicts.
    supportLibVersion = "28.0.0"
    ...
}
...

同一プロジェクト内の各モジュールから上記のプロパティにアクセスするには、モジュール レベルの build.gradle ファイル内で次の構文を使用します。

android {
  // Use the following syntax to access properties you define at the project level:
  // rootProject.ext.property_name
  compileSdkVersion rootProject.ext.compileSdkVersion
  ...
}
...
dependencies {
    implementation "com.android.support:appcompat-v7:${rootProject.ext.supportLibVersion}"
    ...
}

ライブラリと依存関係を管理する

Gradle の堅牢なメカニズムにより、リモート ライブラリでもローカル ライブラリ モジュールでも、依存関係を管理できます。

依存関係コンフィグレーションを使用して特定のビルドをターゲティングする

特定のビルド バリアントのソースセットまたはテスト用のソースセットに限り依存関係が必要な場合は、依存関係コンフィグレーション名の先頭を大文字にして、その先頭に対象のビルド バリアント ソースセットまたはテスト用ソースセットの名前を付加します。

android {...}

// Creates Gradle dependency configurations to use in the dependencies block.
configurations {
  // For variants that combine a product flavor and build type, you need to
  // intitialize a placeholder for its dependency configuration.
  freeDebugRuntimeOnly{}
  ...
}

dependencies {
    // Adds an implementation dependency only to the "free" product flavor.
    freeImplementation 'com.google.firebase:firebase-ads:9.8.0'
    // Adds a runtimeOnly dependency only to the "freeDebug" build variant.
    freeDebugRuntimeOnly fileTree(dir: 'libs', include: ['*.jar'])
    // Adds a remote binary dependency only for local tests.
    testImplementation 'junit:junit:4.12'
    // Adds a remote binary dependency only for the instrumented test APK.
    androidTestImplementation 'com.android.support.test.espresso:espresso-core:3.0.2'
}

アプリの別バージョンを作成する

Gradle と Android プラグインを使用してビルド バリアントを設定すると、単一のモジュールから複数のアプリ バージョンを作成できます。

マルチ APK サポートを設定する

Android プラグインを使用して、複数の APK を作成し、それぞれ異なる ABI や画面密度をターゲティングすると、Google Play のマルチ APK サポートを利用できます。

画面密度ごとに異なる APK を設定する

画面密度ごとに異なる APK を作成するには、モジュールの build.gradle ファイルに android.splits.density ブロックを追加します。

android {
  ...
  splits {

    // Configures multiple APKs based on screen density.
    density {

      // Enables building multiple APKs.
      enable true

      // Specifies a list of screen densities Gradle should not create APKs for.
      exclude "ldpi", "mdpi"

      // Alternatively, you can use the following to clear the default list of
      // screen densities and specify only the screen densities you want to build
      // APKs for:
      // reset()
      // include "hdpi", "xhdpi", "xxhdpi", "xxxhdpi"

      // Specifies a list of compatible screen size settings. This property
      // configures the <compatible-screens> element in the manifest. You
      // typically don't need to configure this manifest property, but it's
      // important when building multiple APKs based on screen density.
      compatibleScreens 'normal', 'large', 'xlarge'
    }
  }
}

ABI ごとに異なる APK を設定する

ABI ごとに異なる APK を作成するには、モジュールの build.gradle ファイルに android.splits.abi ブロックを追加します。

android {
  ...
  splits {

    // Configures multiple APKs based on ABI.
    abi {

      // Enables building multiple APKs.
      enable true

      // By default all ABIs are included, so use reset() and include to specify that we only
      // want APKs for x86, armeabi-v7a, and mips.
      reset()

      // Specifies a list of ABIs that Gradle should create APKs for.
      include "x86", "armeabi-v7a", "mips"

      // Specify that we want to also generate a universal APK that includes all ABIs.
      universalApk true
    }
  }
}

動的なバージョン コードを設定する

Gradle を使用してプロジェクト用の APK を生成する場合、デフォルトでは、モジュール レベルの build.gradle ファイルに指定されているバージョン情報が、すべての APK に対して適用されます。Google Play ストアでは、同一アプリの複数の APK が同じバージョン情報を持つことは認められていないため、Play ストアにアップロードする前に、各 APK の versionCode が一意の値になっているか確認する必要があります。

ビルド時に APK ごとに異なるバージョン コードを割り当てるには、カスタム ビルドロジックを使用します。たとえば、次のように自動で APK のバージョニングを行うと、ABI ごとに異なる APK が生成されます。

android {
  ...
  defaultConfig {
    ...
    versionCode 4
  }
  splits {
    ...
  }
}

// Map for the version code that gives each ABI a value.
ext.abiCodes = ['armeabi-v7a':1, mips:2, x86:3]

// For per-density APKs, create a similar map like this:
// ext.densityCodes = ['hdpi': 1, 'xhdpi': 2, 'xxhdpi': 3, 'xxxhdpi': 4]

import com.android.build.OutputFile

// For each APK output variant, override versionCode with a combination of
// ext.abiCodes * 1000 + variant.versionCode. In this example, variant.versionCode
// is equal to defaultConfig.versionCode. If you configure product flavors that
// define their own versionCode, variant.versionCode uses that value instead.
android.applicationVariants.all { variant ->

  // Assigns a different version code for each output APK
  // other than the universal APK.
  variant.outputs.each { output ->

    // Stores the value of ext.abiCodes that is associated with the ABI for this variant.
    def baseAbiVersionCode =
            // Determines the ABI for this variant and returns the mapped value.
            project.ext.abiCodes.get(output.getFilter(OutputFile.ABI))

    // Because abiCodes.get() returns null for ABIs that are not mapped by ext.abiCodes,
    // the following code does not override the version code for universal APKs.
    // However, because we want universal APKs to have the lowest version code,
    // this outcome is desirable.
    if (baseAbiVersionCode != null) {

      // Assigns the new version code to versionCodeOverride, which changes the version code
      // for only the output APK, not for the variant itself. Skipping this step simply
      // causes Gradle to use the value of variant.versionCode for the APK.
      output.versionCodeOverride =
              baseAbiVersionCode * 1000 + variant.versionCode
    }
  }
}

複数のプロダクト フレーバーを組み合わせる

複数のプロダクト フレーバーの設定を組み合わせることが必要となる場合があります。そのような場合、Android Plugin for Gradle を使用すると、「フレーバー ディメンション」と呼ばれるプロダクト フレーバーのグループを作成できます。

下記のサンプルコードでは、flavorDimensions プロパティを使用して「mode」フレーバー ディメンションを作成し、「full」プロダクト フレーバーと「demo」プロダクト フレーバーをグループ化しています。さらに、「api」フレーバー ディメンションを作成し、API レベルに基づいてプロダクト フレーバー設定をグループ化しています。このように設定すると、Gradle は「mode」ディメンションのプロダクト フレーバーと「api」ディメンションのプロダクト フレーバーを組み合わせます。

android {
  ...
  buildTypes {
    debug {...}
    release {...}
  }

  // Specifies the flavor dimensions you want to use. The order in which you
  // list each dimension determines its priority, from highest to lowest,
  // when Gradle merges variant sources and configurations. You must assign
  // each product flavor you configure to one of the flavor dimensions.
  flavorDimensions "api", "mode"

  productFlavors {
    demo {
      // Assigns this product flavor to the "mode" flavor dimension.
      dimension "mode"
      ...
    }

    full {
      dimension "mode"
      ...
    }

    // Configurations in the "api" product flavors override those in "mode"
    // flavors and the defaultConfig block. Gradle determines the priority
    // between flavor dimensions based on the order in which they appear next
    // to the flavorDimensions property above--the first dimension has a higher
    // priority than the second, and so on.
    minApi24 {
      dimension "api"
      minSdkVersion '24'
      // To ensure the target device receives the version of the app with
      // the highest compatible API level, assign version codes in increasing
      // value with API level. To learn more about assigning version codes to
      // support app updates and uploading to Google Play, read Multiple APK Support
      versionCode 30000 + android.defaultConfig.versionCode
      versionNameSuffix "-minApi24"
      ...
    }

    minApi23 {
      dimension "api"
      minSdkVersion '23'
      versionCode 20000  + android.defaultConfig.versionCode
      versionNameSuffix "-minApi23"
      ...
    }

    minApi21 {
      dimension "api"
      minSdkVersion '21'
      versionCode 10000  + android.defaultConfig.versionCode
      versionNameSuffix "-minApi21"
      ...
    }
  }
}
...

バリアントのフィルタリング

使用しないビルド バリアントをフィルタリングするには、モジュールの build.gradle ファイル内で variantFilter ブロックを使用します。下記のサンプルコードは、「minApi21」プロダクト フレーバーと「demo」プロダクト フレーバーを組み合わせたバリアントをビルドしないよう、Gradle に指定しています。

android {
 ...
 buildTypes {...}

 flavorDimensions "api", "mode"
 productFlavors {
    demo {...}
    full {...}
    minApi24 {...}
    minApi23 {...}
    minApi21 {...}
  }

  variantFilter { variant ->
    def names = variant.flavors*.name
    // To check for a build type instead, use variant.buildType.name == "buildType"
    if (names.contains("minApi21") && names.contains("demo")) {
      // Gradle ignores any variants that satisfy the conditions above.
      setIgnore(true)
    }
  }
}
...

アプリをテストする

ローカル ユニットテストや統合ユニットテストを実施する方法については、アプリをテストするをご覧ください。

lint オプションを設定する

特定の lint オプションを設定するには、モジュール レベルの build.gradle ファイル内で lintOptions ブロックを使用します。Android プロジェクトで lint を使用する方法については、lint を使用してコードを改善するをご覧ください。

android {
  ...
  lintOptions {
    // Turns off checks for the issue IDs you specify.
    disable 'TypographyFractions','TypographyQuotes'
    // Turns on checks for the issue IDs you specify. These checks are in
    // addition to the default lint checks.
    enable 'RtlHardcoded', 'RtlCompat', 'RtlEnabled'
    // To enable checks for only a subset of issue IDs and ignore all others,
    // list the issue IDs with the 'check' property instead. This property overrides
    // any issue IDs you enable or disable using the properties above.
    check 'NewApi', 'InlinedApi'
    // If set to true, turns off analysis progress reporting by lint.
    quiet true
    // if set to true (default), stops the build if errors are found.
    abortOnError false
    // if true, only report errors.
    ignoreWarnings true
  }
}
...

インストルメント化テスト用のマニフェスト設定

Gradle がテスト APK をビルドすると、自動的に AndroidManifest.xml ファイルが生成され、マニフェストに <instrumentation> ノードが設定されます。このノードの設定を変更するには、テスト用ソースセット内に別のマニフェスト ファイルを作成するか、下記のサンプルコードのように、モジュール レベルの build.gradle ファイルを設定します。

android {
  ...
  // Each product flavor you configure can override properties in the
  // defaultConfig block. To learn more, go to Configure Product Flavors.
  defaultConfig {
    ...
    // Specifies the application ID for the test APK.
    testApplicationId "com.test.foo"
    // Specifies the fully-qualified class name of the test instrumentation runner.
    testInstrumentationRunner "android.test.InstrumentationTestRunner"
    // If set to 'true', enables the instrumentation class to start and stop profiling.
    // If set to false (default), profiling occurs the entire time the instrumentation
    // class is running.
    testHandleProfiling true
    // If set to 'true', indicates that the Android system should run the instrumentation
    // class as a functional test. The default value is 'false'
    testFunctionalTest true
  }
}
...

テストのビルドタイプを変更する

デフォルトでは、すべてのテストは、「debug」ビルドタイプに対して実行されます。テスト対象を別のビルドタイプに変更するには、モジュール レベルの build.gradle ファイルの testBuildType プロパティを使用します。たとえば、「staging」ビルドタイプに対してテストを実行するには、次のスニペットのようにファイルを編集します。

android {
    ...
    testBuildType "staging"
}

Gradle テスト オプションを設定する

すべてのテストを対象に、オプションを指定して Gradle のテスト実行方法を変更するには、モジュール レベルの build.gradle ファイル内で testOptions ブロックを設定します。

android {
  ...
  // Encapsulates options for running tests.
  testOptions {
    // Changes the directory where Gradle saves test reports. By default, Gradle saves test reports
    // in the path_to_your_project/module_name/build/outputs/reports/ directory.
    // '$rootDir' sets the path relative to the root directory of the current project.
    reportDir "$rootDir/test-reports"
    // Changes the directory where Gradle saves test results. By default, Gradle saves test results
    // in the path_to_your_project/module_name/build/outputs/test-results/ directory.
    // '$rootDir' sets the path relative to the root directory of the current project.
    resultsDir "$rootDir/test-results"
  }
}

ローカル ユニットテストだけを対象にオプションを指定するには、testOptions.unitTests ブロックを設定します。

android {
  ...
  testOptions {
    ...
    // Encapsulates options for local unit tests.
    unitTests {
      // By default, local unit tests throw an exception any time the code you are testing tries to access
      // Android platform APIs (unless you mock Android dependencies yourself or with a testing
      // framework like Mockito). However, you can enable the following property so that the test
      // returns either null or zero when accessing platform APIs, rather than throwing an exception.
      returnDefaultValues true

      // Encapsulates options for controlling how Gradle executes local unit tests. For a list
      // of all the options you can specify, read Gradle's reference documentation.
      all {
        // Sets JVM argument(s) for the test JVM(s).
        jvmArgs '-XX:MaxPermSize=256m'

        // You can also check the task name to apply options to only the tests you specify.
        if (it.name == 'testDebugUnitTest') {
          systemProperty 'debug', 'true'
        }
      }
    }
  }
}

ビルドを最適化する

このセクションでは、フルビルドおよび増分ビルドの速度を向上させる設定について説明します。詳細については、ビルド速度を最適化するをご覧ください。

コードを圧縮する

Android Studio は ProGuard ルールファイルを使用する R8 を使用してコードを圧縮します。新しいプロジェクトの場合、Android Studio は Android SDK の tools/proguard/folder にあるデフォルト設定ファイル(proguard-android.txt)を使用します。コードをさらに圧縮する場合は、同じ場所にある proguard-android-optimize.txt ファイルを使用してみてください。

android {
  buildTypes {
    release {
      minifyEnabled true
      proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'),
                                           'proguard-rules.pro'
    }
  }
  ...
}
...

各ビルド バリアントに固有のルールを追加するには、それぞれのフレーバーに対して追加の proguardFiles プロパティを設定します。たとえば、下記のサンプルコードの場合、「flavor2」に対して flavor2-rules.pro を追加しています。release ブロックのルールも適用されるため、「flavor2」のリリース バージョンは 3 つのルールをすべて使用することになります。

android {
  ...
  buildTypes {
    release {
      minifyEnabled true
      proguardFiles getDefaultProguardFile('proguard-android.txt'),
             'proguard-rules.pro'
    }
  }
  productFlavors {
    flavor1 {
      ...
    }
    flavor2 {
      proguardFile 'flavor2-rules.pro'
    }
  }
}
...

アプリを公開する

Google Play にアプリを公開する方法については、アプリを公開するをご覧ください。

アプリに署名する

Android Studio を使用すれば、UI から簡単にリリースビルドの署名を設定できますが、モジュールの build.gradle ファイル内の signingConfigs ブロックで手動で設定することも可能です。

android {
  ...
  defaultConfig { ... }

  // Encapsulates signing configurations.
  signingConfigs {
    // Creates a signing configuration called "release".
    release {
      // Specifies the path to your keystore file.
      storeFile file("my-release-key.jks")
      // Specifies the password for your keystore.
      storePassword "password"
      // Specifies the identifying name for your key.
      keyAlias "my-alias"
      // Specifies the password for your key.
      keyPassword "password"
    }
  }
  buildTypes {
    release {
      // Adds the "release" signing configuration to the release build type.
      signingConfig signingConfigs.release
      ...
    }
  }
}
...

プロジェクトからプライベートな署名情報を削除する

デフォルトでは、署名設定はプレーン テキストとしてモジュールの build.gradle ファイルに記録されます。チームやオープンソース プロジェクトで作業している場合は、この機密情報を次の手順でビルドファイルから削除できます。

  1. プロジェクトのルート ディレクトリ内に keystore.properties というファイルを作成して、以下の情報を格納します。
    storePassword=myStorePassword
    keyPassword=myKeyPassword
    keyAlias=myKeyAlias
    storeFile=myStoreFileLocation
    
  2. build.gradle ファイル内で、次のように keystore.properties ファイルを読み込みます(android ブロックの前に追加する必要があります)。
    // Creates a variable called keystorePropertiesFile, and initializes it to the
    // keystore.properties file.
    def keystorePropertiesFile = rootProject.file("keystore.properties")
    
    // Initializes a new Properties() object called keystoreProperties.
    def keystoreProperties = new Properties()
    
    // Loads the keystore.properties file into the keystoreProperties object.
    keystoreProperties.load(new FileInputStream(keystorePropertiesFile))
    
    android {
      ...
    }
    ...
    
  3. keystoreProperties オブジェクト内に格納された署名情報を入力します。
    android {
      signingConfigs {
        config {
          keyAlias keystoreProperties['keyAlias']
          keyPassword keystoreProperties['keyPassword']
          storeFile file(keystoreProperties['storeFile'])
          storePassword keystoreProperties['storePassword']
        }
      }
      ...
    }
    ...
    
  4. 通知バーにある [Sync Now] をクリックします。

アプリ署名の詳細については、アプリに署名するをご覧ください。

アプリ開発を簡素化する

ここでは、Android アプリを簡単に開発するための方法について説明します。

カスタム フィールドとリソース値をアプリのコードと共有する

Gradle は、ビルド時に BuildConfig クラスを生成します。アプリのコードは、このクラスを参照することで、現在のビルドに関する情報を取得します。また、buildConfigField() メソッドを使用して Gradle ビルド設定ファイル内の BuildConfig クラスにカスタム フィールドを追加すると、アプリのランタイム コード内でその値にアクセスできるようになります。同様に、resValue() を使用してアプリのリソース値を追加できます。

android {
  ...
  buildTypes {
    release {
      // These values are defined only for the release build, which
      // is typically used for full builds and continuous builds.
      buildConfigField("String", "BUILD_TIME", "\"${minutesSinceEpoch}\"")
      resValue("string", "build_time", "${minutesSinceEpoch}")
      ...
    }
    debug {
      // Use static values for incremental builds to ensure that
      // resource files and BuildConfig aren't rebuilt with each run.
      // If these rebuild dynamically, they can interfere with
      // Apply Changes as well as Gradle UP-TO-DATE checks.
      buildConfigField("String", "BUILD_TIME", "\"0\"")
      resValue("string", "build_time", "0")
    }
  }
}
...

アプリのコード内で、次のようにプロパティにアクセスできます。

Kotlin

...
Log.i(TAG, BuildConfig.BUILD_TIME)
Log.i(TAG, getString(R.string.build_time))

Java

...
Log.i(TAG, BuildConfig.BUILD_TIME);
Log.i(TAG, getString(R.string.build_time));

プロパティをマニフェストと共有する

マニフェスト内とコード内で同一のプロパティを宣言することが必要となる場合があります(FileProvider のプロバイダを宣言する場合など)。このような場合は、同じプロパティを複数の場所で更新して変更を反映する代わりに、下記のサンプルコードのように、モジュールの build.gradle ファイル内で単一のプロパティを定義し、それをマニフェストとコードの両方で利用できるようにします。詳細については、マニフェストにビルド変数を追加するをご覧ください。

android {
  // For settings specific to a product flavor, configure these properties
  // for each flavor in the productFlavors block.
  defaultConfig {
    // Creates a property for the FileProvider authority.
    def filesAuthorityValue = applicationId + ".files"
    // Creates a placeholder property to use in the manifest.
    manifestPlaceholders =
      [filesAuthority: filesAuthorityValue]
      // Adds a new field for the authority to the BuildConfig class.
      buildConfigField("String",
                       "FILES_AUTHORITY",
                       "\"${filesAuthorityValue}\"")
  }
  ...
}
...

マニフェスト内で、次のようにプレースホルダにアクセスします。

<manifest>
  ...
  <application>
    ...
    <provider
      android:name="android.support.v4.content.FileProvider"
      android:authorities="${filesAuthority}"
      android:exported="false"
      android:grantUriPermissions="true">
      ...
    </provider>
  </application>
</manifest>

アプリのコード内で FILES_AUTHORITY フィールドにアクセスするには、次のように指定します。

Kotlin

...
val contentUri: Uri = FileProvider.getUriForFile(context, BuildConfig.FILES_AUTHORITY, myFile)

Java

...
Uri contentUri = FileProvider.getUriForFile(getContext(),
  BuildConfig.FILES_AUTHORITY,
  myFile);