Android ビルドシステムは、アプリリソースとソースコードをコンパイルして、テスト、デプロイ、署名、配布が可能な APK または Android App Bundle にパッケージ化します。
Android Studio は、高度なビルド ツールキットである Gradle を使用してビルドプロセスの自動化と管理を行う一方で、柔軟なカスタムビルド構成の定義を可能にしています。各ビルド構成でそれぞれ独自のコードとリソースのセットを定義しつつ、アプリのすべてのバージョンに共通する部分を再利用できます。Android Gradle プラグインは、ビルド ツールキットと連携して、Android アプリのビルドとテストに固有のプロセスと構成可能な設定を提供します。
Gradle と Android Gradle プラグインは Android Studio から独立して実行されます。つまり、Android Studio から、使用しているマシンのコマンドラインから、または Android Studio がインストールされていないマシン(継続的インテグレーション サーバーなど)のコマンドラインから、Android アプリをビルドできます。
Android Studio を使用しない場合は、コマンドラインからアプリをビルドして実行する方法をご確認ください。コマンドライン、リモートマシン、Android Studio のいずれからプロジェクトをビルドした場合でも、ビルドの出力は同じになります。
注: Gradle と Android Gradle プラグインは Android Studio から独立して実行されるため、各ビルドツールはそれぞれ個別にアップデートする必要があります。Gradle と Android Gradle プラグインをアップデートする方法については、リリースノートをご覧ください。
Android ビルドシステムは柔軟であるため、アプリの主要なソースファイルを変更せずにカスタムビルド構成を作成できます。このページでは、Android ビルドシステムの仕組みと、Android ビルドシステムを通じて複数のビルド構成をカスタマイズし、自動化する方法について説明します。アプリのデプロイについて詳しくは、アプリをビルドして実行するをご覧ください。Android Studio を使用してカスタムビルド構成の作成をすぐに開始するには、ビルド バリアントを設定するをご覧ください。
ビルドプロセス
ビルドプロセスには、プロジェクトを Android Application Package(APK)または Android App Bundle(AAB)に変換するさまざまなツールとプロセスが含まれます。
Android Gradle プラグインはビルドプロセスの大部分を行いますが、ビルドプロセスの特定の側面を理解し、要件に合わせてビルドを調整できるようにすると便利です。
プロジェクトによってビルド目標が異なる場合があります。たとえば、 サードパーティ ライブラリが Android Archive(AAR)または Java Archive(JAR)を生成 使用できます。 ただし、アプリは最も一般的なタイプのプロジェクトであり、アプリ プロジェクトのビルドでは、アプリのデバッグまたはリリース用の APK または AAB が生成され、これを外部ユーザーにデプロイ、テスト、またはリリースできます。
このページではアプリ開発に焦点を当てていますが、ビルドの手順やコンセプトの多くは、ほとんどのビルドタイプに共通です。
Android ビルドの用語集
Gradle と Android Gradle プラグインを使用すると、以下のビルド要素を構成できます。
- ビルドタイプ
-
ビルドタイプは、アプリをビルドしてパッケージ化する際に Gradle が使用する特定のプロパティを定義するものです。一般的に、ビルドタイプは開発ライフサイクルの各段階に応じて構成されます。
たとえば、debug ビルドタイプの場合は、デバッグ オプションが有効化され、デバッグキーを使用してアプリに署名します。release ビルドタイプの場合は、圧縮と難読化が行われ、配布するためにリリースキーを使用してアプリに署名します。
アプリをビルドするには、少なくとも 1 つのビルドタイプを定義する必要があります。Android Studio は、デフォルトで debug ビルドタイプと release ビルドタイプを作成します。アプリのパッケージ設定のカスタマイズを開始する場合は、ビルドタイプの設定をご覧ください。
- プロダクト フレーバー
- プロダクト フレーバーは、アプリの無料版や有料版など、ユーザーにリリースできるさまざまなアプリ バージョンを示します。プロダクト フレーバーをカスタマイズすることで、さまざまなコードとリソースを使用しつつ、すべてのアプリ バージョンに共通する部分を共有し、再利用できます。プロダクト フレーバーはオプションであり、手動で作成する必要があります。さまざまなアプリ バージョンの作成を開始する場合は、プロダクト フレーバーの設定をご覧ください。
- ビルド バリアント
- ビルド バリアントは、ビルドタイプとプロダクト フレーバーを組み合わせたものです。Gradle はこの構成を使用してアプリをビルドします。ビルド バリアントを使用すると、開発時にプロダクト フレーバーのデバッグ バージョンをビルドし、配布時にプロダクト フレーバーの署名付きリリース バージョンをビルドできます。ビルド バリアントは直接構成するものではなく、ビルド バリアントを形成するビルドタイプとプロダクト フレーバーを構成します。追加のビルドタイプまたはプロダクト フレーバーを作成すると、それに応じてビルド バリアントも追加作成されます。ビルド バリアントを作成、管理する方法については、ビルド バリアントを設定するをご覧ください。
- マニフェスト エントリ
- ビルド バリアント構成内で、マニフェスト ファイルの一部のプロパティ値を指定できます。このビルド値は、マニフェスト ファイル内の既存の値をオーバーライドします。これは、異なるアプリ名、最小 SDK バージョン、ターゲット SDK バージョンを使用してアプリの複数のバリアントを生成する場合に役立ちます。複数のマニフェストが存在する場合、マニフェスト マージツールがマニフェスト設定をマージします。
- 依存関係
- ビルドシステムは、ローカル ファイル システムやリモート リポジトリのプロジェクト依存関係を管理します。つまり、依存関係のバイナリ パッケージを手動で検索してダウンロードしたり、プロジェクト ディレクトリにコピーしたりする必要はありません。詳細については、ビルド依存関係を追加するをご覧ください。
- 署名
- ビルドシステムを使用すると、ビルド構成で署名設定を指定して、ビルドプロセス中に自動的にアプリに署名できます。デバッグ バージョンの場合、ビルドシステムは、既知の認証情報を使用してデフォルトのキーと証明書で署名を行い、ビルド時にパスワード プロンプトが表示されないようにします。リリース バージョンの場合、対象ビルドの署名設定を明示的に定義していない限り、署名は行いません。リリースキーがない場合は、アプリに署名するに記載されているとおり、リリースキーを生成できます。署名付きリリースビルドは、ほとんどのアプリストアでアプリを配布するために必要です。
- コードとリソースの圧縮
- ビルドシステムを使用すると、ビルド バリアントごとに異なる ProGuard ルールファイルを指定できます。アプリをビルドする際、ビルドシステムは適切なルールセットを適用し、R8 などの組み込みの圧縮ツールを使用してコードとリソースを圧縮します。コードとリソースを圧縮すると、APK や AAB のサイズを縮小できます。
- 複数 APK のサポート
- ビルドシステムを使用すると、特定の画面密度またはアプリケーション バイナリ インターフェース(ABI)に必要なコードとリソースのみを含む、さまざまな APK を自動的にビルドできます。詳細については、複数の APK をビルドするをご覧ください。ただし、単一の AAB をリリースすることをおすすめします。このアプローチでは、画面密度と ABI に加えて言語でも分割でき、Google Play に複数のアーティファクトをアップロードせずに済みます。2021 年 8 月以降に送信された新しいアプリはすべて、AAB を使用する必要があります。
Android ビルドの Java バージョン
ソースコードが Java、Kotlin、またはその両方で記述されていても、 いくつかの場所で JDK または Java 言語を選択する必要がある バージョンを指定します。Android ビルドの Java バージョンをご覧ください。 をご覧ください。
ビルド構成ファイル
カスタムビルド構成を作成するには、1 つまたは複数のビルドに変更を加える必要があります。 ビルド構成ファイルが増えます。これらの プレーンテキストファイルでは、ドメイン固有言語(DSL)を使用して ビルドロジックを操作するには、 Kotlin スクリプト これは、Kotlin 言語の一種です。また、 Groovy: Java 仮想マシン(JVM)の動的言語を使用してビルドを構成します。
Kotlin スクリプトや Groovy の知識がなくても、 ビルドする(Android Gradle プラグインはほとんどの DSL 要素を導入するため) できます。Android Gradle プラグイン DSL の詳細については、 DSL リファレンス ドキュメント Kotlin スクリプトも 基盤となる Gradle Kotlin DSL を使用します。
新しいプロジェクトを開始すると、Android Studio によって自動的に 適切なデフォルトに基づいてデータが入力されます。プロジェクト ファイル構造は次のようになります。
└── MyApp/ # Project ├── gradle/ │ └── wrapper/ │ └── gradle-wrapper.properties ├── build.gradle(.kts) ├── settings.gradle(.kts) └── app/ # Module │ ├── build.gradle(.kts) │ ├── build/ │ ├── libs/ │ └── src/ │ └── main/ # Source set │ ├── java/ │ │ └── com.example.myapp │ ├── res/ │ │ ├── drawable/ │ │ ├── values/ │ │ └── ... │ └── AndroidManifest.xml
Android アプリの標準プロジェクト構造には、数種類の Gradle ビルド構成ファイルが含まれています。ビルドの構成を開始する前に、各ファイルのスコープと目的、定義する必要のある基本的な DSL 要素について理解しておくことが重要です。
Gradle ラッパー ファイル
Gradle ラッパー(gradlew
)は、Terraform に組み込まれている
Gradle 自体をダウンロードして起動するコードです。
これにより、ビルド実行の一貫性が高まります。デベロッパーは
アプリケーション ソースを実行し、gradlew
を実行します。必要な Gradle がダウンロードされます。
Gradle が起動して、アプリをビルドします。
gradle/wrapper/gradle-wrapper.properties
ファイル
プロパティ distributionUrl
が含まれています。このプロパティは、
Gradle を使用してビルドを実行します。
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-8.0-bin.zip
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
Gradle 設定ファイル
settings.gradle.kts
ファイル(Kotlin DSL の場合)
settings.gradle
ファイル(Groovy DSL 用)がルート
ディレクトリにあります。この設定は、プロジェクト レベルのリポジトリを定義します
設定を作成し、ビルドに含める必要のあるモジュールを Gradle に通知します。
。マルチモジュール プロジェクトでは、マルチモジュール プロジェクトに含める各モジュールを
行います。
ほとんどのプロジェクトで、このファイルはデフォルトで次のようになります。
Kotlin
pluginManagement { /** * The pluginManagement.repositories block configures the * repositories Gradle uses to search or download the Gradle plugins and * their transitive dependencies. Gradle pre-configures support for remote * repositories such as JCenter, Maven Central, and Ivy. You can also use * local repositories or define your own remote repositories. The code below * defines the Gradle Plugin Portal, Google's Maven repository, * and the Maven Central Repository as the repositories Gradle should use to look for its * dependencies. */ repositories { gradlePluginPortal() google() mavenCentral() } } dependencyResolutionManagement { /** * The dependencyResolutionManagement.repositories * block is where you configure the repositories and dependencies used by * all modules in your project, such as libraries that you are using to * create your application. However, you should configure module-specific * dependencies in each module-level build.gradle file. For new projects, * Android Studio includes Google's Maven repository and the Maven Central * Repository by default, but it does not configure any dependencies (unless * you select a template that requires some). */ repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { google() mavenCentral() } } rootProject.name = "My Application" include(":app")
Groovy
pluginManagement { /** * The pluginManagement.repositories block configures the * repositories Gradle uses to search or download the Gradle plugins and * their transitive dependencies. Gradle pre-configures support for remote * repositories such as JCenter, Maven Central, and Ivy. You can also use * local repositories or define your own remote repositories. The code below * defines the Gradle Plugin Portal, Google's Maven repository, * and the Maven Central Repository as the repositories Gradle should use to look for its * dependencies. */ repositories { gradlePluginPortal() google() mavenCentral() } } dependencyResolutionManagement { /** * The dependencyResolutionManagement.repositories * block is where you configure the repositories and dependencies used by * all modules in your project, such as libraries that you are using to * create your application. However, you should configure module-specific * dependencies in each module-level build.gradle file. For new projects, * Android Studio includes Google's Maven repository and the Maven Central * Repository by default, but it does not configure any dependencies (unless * you select a template that requires some). */ repositoriesMode.set(RepositoriesMode.FAIL_ON_PROJECT_REPOS) repositories { google() mavenCentral() } } rootProject.name = "My Application" include ':app'
トップレベル ビルドファイル
トップレベルの build.gradle.kts
ファイル(Kotlin DSL の場合)
build.gradle
ファイル(Groovy DSL 用)がルート
ディレクトリにあります。通常は、使用するプラグインの一般的なバージョンを定義します。
モジュールごとに設定できます。
次のコードサンプルは、 新しいプロジェクトを作成した後、トップレベルのビルド スクリプトを作成します。
Kotlin
plugins { /** * Use `apply false` in the top-level build.gradle file to add a Gradle * plugin as a build dependency but not apply it to the current (root) * project. Don't use `apply false` in sub-projects. For more information, * see Applying external plugins with same version to subprojects. */ id("com.android.application") version "8.5.0" apply false id("com.android.library") version "8.5.0" apply false id("org.jetbrains.kotlin.android") version "1.9.23" apply false }
Groovy
plugins { /** * Use `apply false` in the top-level build.gradle file to add a Gradle * plugin as a build dependency but not apply it to the current (root) * project. Don't use `apply false` in sub-projects. For more information, * see Applying external plugins with same version to subprojects. */ id 'com.android.application' version '8.5.0' apply false id 'com.android.library' version '8.5.0' apply false id 'org.jetbrains.kotlin.android' version '1.9.23' apply false }
モジュール レベル ビルドファイル
モジュール レベルの build.gradle.kts
(Kotlin DSL の場合)または
build.gradle
ファイル(Groovy DSL 用)は、
project/module/
ディレクトリ。このファイルを使用すると、属する個々のモジュールのビルド設定を構成できます。構成
これらのビルド設定を使用すると、次のようなカスタム パッケージ オプションを提供できます。
ビルドタイプとプロダクト フレーバーの追加が可能で、
main/
アプリ マニフェストまたはトップレベルのビルド スクリプト。
Android SDK の設定
アプリのモジュール レベルのビルドファイルには、アプリケーションのモジュール レベルのビルド コンパイル時、プラットフォームの動作選択時、使用する Android SDK バージョン アプリケーションを実行する最小バージョンを指定します。
-
compileSdk
-
compileSdk
は、実行する Android API と Java API を決定します。 ソースコードのコンパイル時に使用できます。最新の Android を使うには コンパイルする際は、最新の Android SDK を使用してください。一部の Android プラットフォーム API を使用できない場合がある 使用できますGoogle Chat では <ph type="x-smartling-placeholder"></ph> 新しい機能の使用を条件付きで保護する、または <ph type="x-smartling-placeholder"></ph> AndroidX 互換性ライブラリを使用して、 Android API レベル。
各 Android SDK には、アプリケーションで使用する Java API のサブセットが用意されています。 <ph type="x-smartling-placeholder"></ph>のテーブル Java または Kotlin のソースコードで使用できる Java API は、Android SDK バージョンに基づいて利用可能な Java API レベルを示します。 新しい Java API は、以前のバージョンの Android で desugaring: 有効にする必要があります。
compileSdk
が競合すると、Android Studio に警告が表示される 最新バージョンの Android Studio、AGP、またはプロジェクトのライブラリを使用している 必要があります。 -
minSdk
-
minSdk
には、使用する Android の最小バージョンを指定します。 指定することもできますminSdk
を設定すると、 アプリがアプリをインストールできるようになります。以前のバージョンの Android をサポートするには、より多くの条件付きチェックが必要になる場合があります または AndroidX 互換性ライブラリをさらに使用します。すべきこと 下位のバージョンをサポートする場合の維持費を、 まだその以前のバージョンを使用しているユーザーの割合詳しくは、 Android Studio の [New project] ウィザードに表示されるバージョン チャート 現在のバージョン使用率を表示する必要があります。
Android Studio でコードを編集する場合や、Android Studio 内でチェックを実行する場合は、 使用していると、利用できない API について lint が警告する
minSdk
にあります。この問題は、次の方法で修正する必要があります。 <ph type="x-smartling-placeholder"></ph> 新しい機能を条件付きにする、または <ph type="x-smartling-placeholder"></ph> 下位互換性のためのAppcompat
。 -
targetSdk
-
targetSdk
には次の 2 つの目的があります。- アプリケーションのランタイム動作を設定します。
- テストした Android のバージョンを証明するものです。
より新しいバージョンの Android を搭載したデバイスで
targetSdk
の場合、Android はアプリを互換モードで実行します 動作は、バージョン 1.0.0.0 のtargetSdk
。たとえば、API 23 でランタイムが導入された場合など すべてのアプリですぐに導入できるわけではありません。targetSdk
を 22 に設定すると、これらのアプリを実行できます。 実行時の権限を使用せず、機能を使用できる可能性がある API 23 デバイス 最新のcompileSdk
バージョンに含まれています。Google Play 分散ポリシーにより、 対象 API レベルの追加ポリシーをご覧ください。targetSdk
の値は次の値以下にしてくださいcompileSdk
のものと比較します。
注: compileSdk
と targetSdk
の値は
同じである必要はありません。次の基本原則に留意してください。
compileSdk
を使用すると、新しい API にアクセスできますtargetSdk
: アプリのランタイム動作を設定します。targetSdk
はcompileSdk
以下にしてください
app-module ビルド スクリプトのサンプル
このサンプル Android アプリ モジュールのビルド スクリプトは、 基本的な DSL 要素と設定:
Kotlin
/** * The first section in the build configuration applies the Android Gradle plugin * to this build and makes the android block available to specify * Android-specific build options. */ plugins { id("com.android.application") } /** * Locate (and possibly download) a JDK used to build your kotlin * source code. This also acts as a default for sourceCompatibility, * targetCompatibility and jvmTarget. Note that this does not affect which JDK * is used to run the Gradle build itself, and does not need to take into * account the JDK version required by Gradle plugins (such as the * Android Gradle Plugin) */ kotlin { jvmToolchain(11) } /** * The android block is where you configure all your Android-specific * build options. */ android { /** * The app's namespace. Used primarily to access app resources. */ namespace = "com.example.myapp" /** * compileSdk specifies the Android API level Gradle should use to * compile your app. This means your app can use the API features included in * this API level and lower. */ compileSdk = 33 /** * The defaultConfig block encapsulates default settings and entries for all * build variants and can override some attributes in main/AndroidManifest.xml * dynamically from the build system. You can configure product flavors to override * these values for different versions of your app. */ defaultConfig { // Uniquely identifies the package for publishing. applicationId = "com.example.myapp" // Defines the minimum API level required to run the app. minSdk = 21 // Specifies the API level used to test the app. targetSdk = 33 // Defines the version number of your app. versionCode = 1 // Defines a user-friendly version name for your app. versionName = "1.0" } /** * The buildTypes block is where you can configure multiple build types. * By default, the build system defines two build types: debug and release. The * debug build type is not explicitly shown in the default build configuration, * but it includes debugging tools and is signed with the debug key. The release * build type applies ProGuard settings and is not signed by default. */ buildTypes { /** * By default, Android Studio configures the release build type to enable code * shrinking, using minifyEnabled, and specifies the default ProGuard rules file. */ getByName("release") { isMinifyEnabled = true // Enables code shrinking for the release build type. proguardFiles( getDefaultProguardFile("proguard-android.txt"), "proguard-rules.pro" ) } } /** * The productFlavors block is where you can configure multiple product flavors. * This lets you create different versions of your app that can * override the defaultConfig block with their own settings. Product flavors * are optional, and the build system does not create them by default. * * This example creates a free and paid product flavor. Each product flavor * then specifies its own application ID, so that they can exist on the Google * Play Store, or an Android device, simultaneously. * * If you declare product flavors, you must also declare flavor dimensions * and assign each flavor to a flavor dimension. */ flavorDimensions += "tier" productFlavors { create("free") { dimension = "tier" applicationId = "com.example.myapp.free" } create("paid") { dimension = "tier" applicationId = "com.example.myapp.paid" } } /** * To override source and target compatibility (if different from the * toolchain JDK version), add the following. All of these * default to the same value as kotlin.jvmToolchain. If you're using the * same version for these values and kotlin.jvmToolchain, you can * remove these blocks. */ //compileOptions { // sourceCompatibility = JavaVersion.VERSION_11 // targetCompatibility = JavaVersion.VERSION_11 //} //kotlinOptions { // jvmTarget = "11" //} } /** * The dependencies block in the module-level build configuration file * specifies dependencies required to build only the module itself. * To learn more, go to Add build dependencies. */ dependencies { implementation(project(":lib")) implementation("androidx.appcompat:appcompat:1.7.0") implementation(fileTree(mapOf("dir" to "libs", "include" to listOf("*.jar")))) }
Groovy
/** * The first line in the build configuration applies the Android Gradle plugin * to this build and makes the android block available to specify * Android-specific build options. */ plugins { id 'com.android.application' } /** * Locate (and possibly download) a JDK used to build your kotlin * source code. This also acts as a default for sourceCompatibility, * targetCompatibility and jvmTarget. Note that this does not affect which JDK * is used to run the Gradle build itself, and does not need to take into * account the JDK version required by Gradle plugins (such as the * Android Gradle Plugin) */ kotlin { jvmToolchain 11 } /** * The android block is where you configure all your Android-specific * build options. */ android { /** * The app's namespace. Used primarily to access app resources. */ namespace 'com.example.myapp' /** * compileSdk specifies the Android API level Gradle should use to * compile your app. This means your app can use the API features included in * this API level and lower. */ compileSdk 33 /** * The defaultConfig block encapsulates default settings and entries for all * build variants and can override some attributes in main/AndroidManifest.xml * dynamically from the build system. You can configure product flavors to override * these values for different versions of your app. */ defaultConfig { // Uniquely identifies the package for publishing. applicationId 'com.example.myapp' // Defines the minimum API level required to run the app. minSdk 21 // Specifies the API level used to test the app. targetSdk 33 // Defines the version number of your app. versionCode 1 // Defines a user-friendly version name for your app. versionName "1.0" } /** * The buildTypes block is where you can configure multiple build types. * By default, the build system defines two build types: debug and release. The * debug build type is not explicitly shown in the default build configuration, * but it includes debugging tools and is signed with the debug key. The release * build type applies ProGuard settings and is not signed by default. */ buildTypes { /** * By default, Android Studio configures the release build type to enable code * shrinking, using minifyEnabled, and specifies the default ProGuard rules file. */ release { minifyEnabled true // Enables code shrinking for the release build type. proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro' } } /** * The productFlavors block is where you can configure multiple product flavors. * This lets you create different versions of your app that can * override the defaultConfig block with their own settings. Product flavors * are optional, and the build system does not create them by default. * * This example creates a free and paid product flavor. Each product flavor * then specifies its own application ID, so that they can exist on the Google * Play Store, or an Android device, simultaneously. * * If you declare product flavors, you must also declare flavor dimensions * and assign each flavor to a flavor dimension. */ flavorDimensions "tier" productFlavors { free { dimension "tier" applicationId 'com.example.myapp.free' } paid { dimension "tier" applicationId 'com.example.myapp.paid' } } /** * To override source and target compatibility (if different from the * tool chain JDK version), add the following. All of these * default to the same value as kotlin.jvmToolchain. If you're using the * same version for these values and kotlin.jvmToolchain, you can * remove these blocks. */ //compileOptions { // sourceCompatibility JavaVersion.VERSION_11 // targetCompatibility JavaVersion.VERSION_11 //} //kotlinOptions { // jvmTarget = '11' //} } /** * The dependencies block in the module-level build configuration file * specifies dependencies required to build only the module itself. * To learn more, go to Add build dependencies. */ dependencies { implementation project(":lib") implementation 'androidx.appcompat:appcompat:1.7.0' implementation fileTree(dir: 'libs', include: ['*.jar']) }
Gradle プロパティ ファイル
Gradle には、ルート プロジェクト ディレクトリにプロパティ ファイルも 2 つあります。このファイルを使用することで、Gradle ビルド ツールキット自体の設定を指定できます。
-
gradle.properties
- Gradle デーモンの最大ヒープサイズなど、プロジェクト レベルの Gradle 設定を構成できます。詳細については、ビルド環境をご覧ください。
-
local.properties
- 以下の項目など、ビルドシステムのローカル環境プロパティを構成します。
ndk.dir
- NDK へのパス。このプロパティは非推奨になりました。ダウンロードしたバージョンの NDK はすべて、Android SDK ディレクトリ内のndk
ディレクトリにインストールされています。sdk.dir
- Android SDK のパス。cmake.dir
- CMake へのパス。ndk.symlinkdir
- Android Studio 3.5 以降では、インストールされている NDK のパスよりも短くできる、NDK へのシンボリック リンクが作成されます。
NDK を短いパスに再マッピングする(Windows のみ)
Windows では、インストールされている NDK フォルダ内のツール(ld.exe
など)のパスが長くなります。長いパスは適切にサポートされません。
パスを短くするには、local.properties
でプロパティ ndk.symlinkdir
を設定して、Android Gradle プラグインが NDK へのシンボリック リンクを作成するようにリクエストします。シンボリック リンクのパスは、既存の NDK フォルダより短くできます。たとえば、ndk.symlinkdir = C:\
は次のシンボリック リンクになります。
C:\ndk\19.0.5232133
プロジェクトと Gradle ファイルを同期する
プロジェクト内のビルド構成ファイルに変更を加えた場合、プロジェクト ファイルを同期するよう Android Studio から求められます。同期すると、ビルド構成の変更をインポートして、構成がビルドエラーを引き起こさないか確認するチェックを実行できるようになります。
プロジェクト ファイルを同期するには、画面内の [今すぐ同期] をクリックします
通知バーが表示されます。
図 1 または [Sync Project] をクリックします。
を選択します。Android Studio でエラーが検出された場合は、
たとえば、ソースコードで使用されている API 機能が、
compileSdkVersion
より高い API レベルで利用可能
- [メッセージ] ウィンドウに問題の説明が表示されます。
![](https://developer.android.google.cn/static/images/tools/as-gradlesync.png?authuser=0000&hl=ja)
ソースセット
Android Studio は、各モジュールのソースコードとリソースをソースセットとして論理的にグループ化します。新しいモジュールを作成すると、Android Studio はそのモジュール内に main/
ソースセットを作成します。モジュールの
main/
ソースセットには、そのすべてのリソースで使用されるコードとリソースが含まれています。
ビルド バリアント
追加のソースセット ディレクトリはオプションです。新しいビルド バリアントを構成しても、Android Studio によって自動的に作成されることはありません。ただし、main/
と同様のソースセットを作成すると、アプリの特定バージョンをビルドするときにのみ Gradle が使用するファイルとリソースを整理できます。
-
src/main/
- このソースセットには、すべてのビルド バリアントに共通するコードとリソースが含まれています。
-
src/buildType/
- 特定のビルドタイプだけを対象とするコードとリソースを含めるには、このソースセットを作成します。
-
src/productFlavor/
- 特定のプロダクト フレーバーだけを対象とするコードとリソースを含めるには、このソースセットを作成します。
注: 複数のプロダクト フレーバーを組み合わせるようにビルドを構成した場合、フレーバー ディメンション間のプロダクト フレーバーの組み合わせごとにソースセット ディレクトリを作成できます(
src/productFlavor1ProductFlavor2/
)。 -
src/productFlavorBuildType/
- 特定のビルド バリアントだけを対象とするコードとリソースを含めるには、このソースセットを作成します。
たとえば、アプリの「fullDebug」バージョンを生成する場合、ビルドシステムは以下のソースセットのコード、設定、リソースをマージします。
src/fullDebug/
(ビルド バリアントのソースセット)src/debug/
(ビルドタイプのソースセット)src/full/
(プロダクト フレーバーのソースセット)-
src/main/
(メインのソースセット)
注: Android Studio で新しいファイルまたはディレクトリを作成するときは、[File] > [New] メニュー オプションを使用して、特定のソースセット用のファイルまたはディレクトリを作成します。ビルド構成に応じてソースセットを選択できます。必要なディレクトリが存在しない場合は、Android Studio が自動的に作成します。
異なるソースセット内に同一ファイルの別バージョンが含まれている場合、Gradle は次の優先順位に基づいて、使用するファイルを決定します(左側のソースセットが右側のソースセットのファイルや設定をオーバーライドします)。
ビルド バリアント > ビルドタイプ > プロダクト フレーバー > メイン ソースセット > ライブラリ依存関係
これにより、Gradle は、ビルドしようとしているビルド バリアントに固有のファイルを使用しつつ、他のアプリ バージョンと共通するアクティビティ、アプリロジック、リソースを再利用できるようになります。
Gradle は複数のマニフェストをマージする際も同じ優先順位を使用するため、最終マニフェストでビルド バリアントごとにさまざまなコンポーネントまたは権限を定義できます。カスタム ソースセットの作成について詳しくは、ソースセットの作成をご覧ください。
バージョン カタログ
共通の依存関係を持つ複数のモジュールがビルドに含まれている場合や、 共通の依存関係を持つ独立したプロジェクトが複数ある場合、 使用 バージョン カタログや部品構成表(BOM)などを 共通バージョンを指定します。
他のビルドシステム
Bazel を使用した Android アプリのビルド 可能ですが、公式にはサポートされていませんAndroid Studio は、 Bazel プロジェクトをサポートしています。
Bazel を使用するビルドの現在の制限事項については、既知の問題をご覧ください。