Build Typeとは — Gradleでのdebugとrelease設定

Build Typeとは？

Build Typeとは、AndroidプロジェクトのGradle設定の要素で、アプリケーションのコンパイルとパッケージ化のパラメータを記述します。各Build Typeは、debuggable（デバッグ有効）、minificationEnabled（コード圧縮有効）、shrinkResources（リソース圧縮有効）、proguardFiles（ProGuardルールファイル）、signingConfig（署名証明書）などの名前付きオプションセットです。Build Typesは、appモジュールのbuild.gradleファイルのandroid.buildTypesブロックで宣言されます。

Build Typeの主な目的は、開発ワークフロー（高速ビルド、詳細ログ、デバッグ）とプロダクションリリース（最適化されたコード、最小サイズ、セキュリティ）を分離することです。デバッグビルドは数秒でコンパイルされ、開発者に最大限の情報を提供する必要があります。リリースビルドは、ユーザーにとって可能な限り高速でコンパクトである必要があります。Build Typeはインフラストラクチャ設定であり、アプリケーションの機能には関係しません。

Android Gradle Pluginは、各Build Typeに対して自動的にsource set — src/<buildType>/ディレクトリ（例：src/debug/、src/release/）を作成します。このsource setに配置されたリソース、コード、マニフェストファイルは、そのビルドタイプにのみ適用されます。たとえば、src/debug/にはADBからのインストール許可を持つAndroidManifest.xmlを配置でき、src/release/には配置しません。Build Typeのsource setは、Product Flavorのsource setよりも優先されます。

Build TypeとProduct Flavorの違い

主な違い：Build Typeは「どのようにビルドするか？」という質問に答え、Product Flavorは「何をビルドするか？」に答えます。Build Typeはdebug、release、stagingにできます。Product Flavorはfree、paid、enterpriseにできます。Build Typeはアプリケーションの機能を変更せず（画面の追加や削除は行わない）、Product Flavorは変更します。Build Typeはデバッガを無効にしたり難読化を有効にしたりでき、Product FlavorはapplicationIdやリソースを変更できます。両者は連携し、各Build Typeが各Product Flavorと組み合わされてBuild Variantを形成します。

標準Build Types：debugとrelease

DebugはAGPによってデフォルトで作成されるBuild Typeです。debuggable=trueであり、デバッガの接続、Log.dログの表示、Android Studioプロファイラの使用が可能です。Minificationは無効であるため、ビルドは高速です。デバッグビルドでは、applicationIdに「.debug」サフィックスが付加され（オーバーライドされていない場合）、デバッグバージョンをリリースバージョンと同一デバイスに並行してインストールできます。デバッグビルドは、Android SDKが自動的に作成するdebug.keystoreの証明書で署名されます。

Releaseはアプリケーション公開用のBuild Typeです。debuggable=false、minificationEnabled=true（デフォルト）、shrinkResources=trueです。開発者はプロダクション証明書でsigningConfigを指定する必要があり、指定しないとビルドはリリースと見なされません。リリースビルドは、難読化、最適化、コード圧縮にProGuardまたはR8を使用します。Android Studioはリリースビルドにデバッガを接続できません（debuggable=falseの場合）。適切なProGuardルールが設定されている場合、minification中にすべてのLog.dおよびLog.v呼び出しがコードから削除されます。

重要：デバッグビルドはリリースの動作をテストしません。Minificationはコードの動作を変更する可能性があります — リフレクション、シリアル化、Gson/SQLite、その他のライブラリはしばしばProGuardルールを必要とします。したがって、公開前には必ずリリースビルドを作成してテストしてください。Google Play ConsoleとFirebase Test Labでは、公開前に実機での自動テスト用にリリースビルドをアップロードできます。

android {
    buildTypes {
        debug {
            debuggable true
            minification false
            signingConfig signingConfigs.debug
            versionNameSuffix "-debug"
        }

        release {
            debuggable false
            minification true
            shrinkResources true
            proguardFiles "proguard-rules.pro"
            signingConfig signingConfigs.release
            ndk { abiFilters "arm64-v8a", "x86_64" }
        }
    }
}

カスタムBuild Typesの作成

initWithによる継承

debugとreleaseに加えて、カスタムBuild Typesを作成できます — たとえばstaging（中間環境）やbenchmark（パフォーマンステスト用）。カスタムBuild Typeは、debugやreleaseと同じようにbuildTypesブロックで宣言されます。名前は任意ですが、英語で意味的に明確な名前を使用することをお勧めします。stagingでは通常、debuggable=true（staging環境での問題診断用）とminification=true（本番前に難読化をテストするため）が設定されます。

カスタムBuild Typeは自動的に対応するsource set（src/staging/）を取得し、assembleStagingのようなタスクを生成します。AGPはカスタムタイプの数に制限を課しませんが、新しいタイプごとにBuild Variantsの数が倍増します。実用的な上限は4〜5個のBuild Typesです：debug、staging、benchmark、release、および必要に応じてdebugMinified（ProGuardルールテスト用にminificationを有効にしたdebug）。

カスタムBuild Typeでは、initWithを使用してdebugからdebuggableを継承できます。initWithキーワードは、指定されたBuild Typeのすべてのパラメータをコピーし、その後オーバーライドできます。これはdebugをベースにstagingを作成するのに便利です：initWith debug + 追加でminificationを有効化。initWithがない場合、ベースタイプのすべてのパラメータを手動で列挙する必要があります。

android {
    buildTypes {
        staging {
            initWith debug
            minification true
            shrinkResources true
            proguardFiles "staging-proguard-rules.pro"
            versionNameSuffix "-staging"
        }

        benchmark {
            initWith release
            signingConfig signingConfigs.debug
            matchingFallbacks = ["release"]
        }
    }
}

// matchingFallbacks — benchmarkタイプを持たないライブラリ向け
// ライブラリがreleaseしか持たない場合 — AGPがそれを使用

異なるビルドタイプの署名設定

SigningConfigは、APKまたはAABの署名に使用する証明書を決定します。Androidでは、インストール可能なすべてのアプリケーションに署名が必要であり、署名がないとシステムはインストールを許可しません。デバッグビルドの場合、AGPはdebug.keystoreを使用します — Android SDK Toolsによって生成された既知のパスワードを持つプリインストール証明書です。リリースビルドの場合は、Android Studio（Build → Generate Signed Bundle/APK）またはkeytoolコマンドラインを介して独自の証明書を作成する必要があります。

署名キーの保存は重要なセキュリティ上の懸念事項です。リリースキーはソースコードリポジトリに保存しないことをお勧めします。代わりに、keystore.propertiesファイル（.gitignoreに追加）、CI/CD環境変数、またはAndroid Studioの暗号化ストレージを使用します。CI/CD（GitHub Actions、GitLab CI）では、署名キーはsecretsに保存され、システムプロパティを介してbuild.gradleに渡されます。例：storePassword = System.getenv("KEYSTORE_PASSWORD")。

各Build Typeは独自のsigningConfigを参照できます。releaseの場合はプロダクション証明書、debugの場合はdebug.keystore、stagingの場合は別のstaging証明書です。署名設定はアプリケーションのインストール可能性に直接影響します：debugをdebug.keystoreで署名し、stagingをプロダクションキーで署名した場合、署名の不一致によりstagingをdebugバージョン上にインストールできません。applicationIdも異なる必要があります — これにはapplicationIdSuffixを使用します。

android {
    signingConfigs {
        debug {
            storeFile file("debug.keystore")
            storePassword "android"
            keyAlias "androiddebugkey"
            keyPassword "android"
        }
        release {
            storeFile file("release-key.jks")
            storePassword System.getenv("KEYSTORE_PASS")
            keyAlias "my-key"
            keyPassword System.getenv("KEY_PASS")
        }
    }

    buildTypes {
        release {
            signingConfig signingConfigs.release
        }
    }
}

Minification、ProGuard、R8

Resource Shrinking

Minificationとは、未使用コードを削除し、クラス、メソッド、フィールドを短い名前に名前変更するプロセスです。AGPはProGuard（レガシー）またはR8（推奨、AGPバージョン3.4以降に組み込み）を使用してminificationを実行します。R8は4つの操作を実行します：shrinking（未使用クラスの削除）、optimisation（コードの簡略化）、obfuscation（名前変更）、preverify（互換性情報の追加）。結果として、APKは小さくなり、逆コンパイルが困難になります。

MinificationルールはProGuardルールファイルで定義されます — -keep、-dontwarn、-keepclassmembersなどの構文を持つテキストファイルです。ルールがないと、R8はリフレクション（Gson、Retrofit、Room、Kotlinシリアル化）を介して使用されるクラスを削除または名前変更します。Android Studioのプロジェクトテンプレートはproguard-rules.proファイルを作成し、特定のライブラリのルールが追加されます。ライブラリには組み込みルールが含まれる場合もあり、jar/aarから自動的に組み込まれます。

Shrink resources（shrinkResources=true）は、APKから未使用のリソースを削除します。R8はまずコードで使用されていないリソースを特定し（R.javaとマニフェスト参照を確認）、その後最終ビルドから削除します。getIdentifier()やサードパーティライブラリを介して使用されるリソースの場合は、リソースにtools:keep="@layout/my_layout"を追加する必要があります。Minificationと組み合わせることで、resource shrinkingはAPKサイズを40〜60%削減できます。

# proguard-rules.pro — 必須ルール
# Gson：シリアル化用にクラスを保持
-keepclassmembers class com.example.** {
    <fields>;
}

# Retrofit：APIインターフェースを保持
-keep,allowobfuscation interface com.example.api.*

# Room：DAOとEntityを保持
-keep class * extends androidx.room.RoomDatabase
-keep @interface androidx.room.** { *; }

# Kotlin Coroutines：Continuationの削除を防止
-keepnames class kotlinx.coroutines.internal.*

# OkHttp：service loaderを保持
-keep class okhttp3.** { *; }

BuildConfigFieldとBuild Typeのリソース

BuildConfigは、defaultConfig、productFlavors、buildTypesで定義された定数を含む自動生成Java/Kotlinクラスです。buildConfigFieldを使用してカスタムフィールドを追加できます：buildConfigField "String"、"API_URL"、'"https://api.example.com"'。buildTypeで宣言されたBuildConfigFieldは、そのタイプのすべてのバリアントで利用可能です。buildTypeの値はproductFlavorの値をオーバーライドし、productFlavorはdefaultConfigをオーバーライドします。

デバッグビルドでは、API_URLをlocalhostやstagingサーバーに設定し、releaseではプロダクションに設定すると便利です。BuildConfig.FLAVORとBuildConfig.BUILD_TYPEも自動的に生成され、現在のflavorとbuild typeの名前を保持します。コードではif (BuildConfig.DEBUG) { /* ログ */ }のように使用できます — DEBUG定数はdebug build typeの場合のみtrueです。BuildConfig.DEBUGはAGPがすべてのBuildConfigに追加する標準フィールドです。

Build Typeのリソースは、source set src/<buildType>/res/を介して定義されます。たとえば、src/debug/res/values/strings.xmlには「Server: Dev」という文字列を含め、src/release/res/には「Server: Prod」を含めることができます。マニフェストリソースもsource setを介してオーバーライドされます：src/debug/AndroidManifest.xmlには、デバッグビルドのみで<uses-permission android:name="android.permission.INTERNET" />を含めることができます。これはコードでBuildConfigをチェックするよりもクリーンで、プログラムで設定できない属性（networkSecurityConfigなど）でも機能します。

// src/debug/kotlin/.../DebugConfig.kt
object DebugConfig {
    val apiUrl = "http://localhost:8080/api"
    val enableLogging = true
    val enableCrashReporting = false
}

// src/release/kotlin/.../ReleaseConfig.kt
object ReleaseConfig {
    val apiUrl = "https://api.production.com/v2"
    val enableLogging = false
    val enableCrashReporting = true
}

// 使用法：メインクラスがリフレクションを介してConfigをロード
fun getConfig(): AppConfig = when (BuildConfig.BUILD_TYPE) {
    "debug" -> DebugConfig
    else -> ReleaseConfig
}