概要

Android Studio でプロジェクトを作成すると、デフォルトで debug と release という 2 つのビルドタイプが用意されています。デフォルトのままでも問題はありませんが、これらを適切にカスタマイズし、さらに独自のタイプを追加することで、開発効率が向上します。

本記事では、BuildType の基本的な役割と、よく使われる便利なプロパティについて解説します。

結論

Android Studio の BuildType（ビルドタイプ） を適切に設定することで、開発・検証・リリースの各フェーズを安全かつ効率的に進めることができます。

アプリの共存

applicationIdSuffix を設定することで、1台の端末に「開発版」と「本番版」を同時にインストールして動作比較が可能になる

設定の効率化

initWith() を活用することで、既存の設定を継承しつつ必要な差分（API接続先や署名など）だけを記述できる

リリース最適化

isMinifyEnabled や isShrinkResources を有効にすることで、コードの難読化とファイルサイズの軽量化を実現し、製品クオリティを高められる

プロジェクトの規模やチームの運用に合わせて BuildType をカスタマイズし、スマートな開発を目指したいものです。

デフォルトの 2 種類

通常、Android アプリは以下の 2 つの状態で管理されます。

Type	概要
debug	開発で使用。デバッグ機能が有効で、署名設定も簡略化。
release	本番で使用。難読化や最適化が行われ、製品用の署名が必要。

任意のタイプの作成

実際の現場では staging 環境が必要になることが多々あります。
BuildType は、こうした任意のタイプを自由に追加することが可能です。

buildTypes {
    // ... debug, release の設定 ...

    // staging を新しく作る
    create("staging") {
        // debug の設定をコピー
        initWith(getByName("debug"))

        // applicationId 末尾に .staging を追加
        applicationIdSuffix = ".staging"
        // versionName 末尾に "-staging" を追加
        versionNameSuffix = "-staging"

        // サーバー接続先をステージング用に
        buildConfigField("String", "BASE_URL", "\"https://stg.api.com\"")
    }
}

設定のポイント

`initWith()` による設定の継承

initWith を使うと、既存のビルドタイプ（例：debug）の設定をすべて引き継ぐことができます。これにより、署名設定などを省略しつつ、「差分」だけを記述できるため、管理が非常に楽になります。

`applicationIdSuffix` でアプリを共存させる

applicationIdSuffix を使い、 .staging と指定すると、アプリ ID の末尾に識別子が追加されます（例：com.example.app.staging）。 Android 端末はアプリ ID でアプリを識別するため、これにより 1 台のスマホの中に「本番版」「デバッグ版」「ステージング版」を同時にインストールして共存させることが可能になります。

`buildConfigField`

buildConfigField は、ビルド時に BuildConfig というクラスを自動生成し、その中に独自の定数を埋め込む機能です。
ソースコードを書き換えることなく、ビルドのタイミング（Debug 用か Staging 用かなど）に応じてアプリの挙動や接続先を切り替えるために使用します。

// 基本的な構文: buildConfigField(型, 定数名, 値)
buildConfigField("String", "BASE_URL", "\"https://stg.api.com\"")

// 使用例
val apiClient = Retrofit.Builder()
    .baseUrl(BuildConfig.BASE_URL) // Gradleで定義した値がここに入る
    .build()

アプリ最適化に関わる、覚えておくべき重要プロパティ

ビルドタイプを設定する際、特に重要なのが以下のプロパティです。

`isMinifyEnabled`（コードの最適化）

isMinifyEnabled = true に設定すると、R8（または ProGuard）によるコードの圧縮と難読化が有効になります。リリースビルドでは必須の設定です。

`isShrinkResources`（リソースの最小化）

isShrinkResources を isMinifyEnabled と併用することで、プロジェクト内で使用されていない画像やレイアウトファイルを削除し、APK サイズをさらに軽量化します。

最低限必須のビルド設定例は下記になります。

buildTypes {
    // ① Debugの設定：アプリIDを分けて本番版と共存させる
    debug {
        applicationIdSuffix = ".debug"
        versionNameSuffix = "-debug"
    }

    // ② Releaseの設定：徹底的に最適化
    release {
        isMinifyEnabled = true     // コード圧縮・難読化を有効
        isShrinkResources = true   // 未使用リソースを削除

        // Baseline Profile の自動生成設定
        baselineProfile.automaticGenerationDuringBuild = true

        // ProGuard ルール指定
        proguardFiles(
            getDefaultProguardFile("proguard-android-optimize.txt"),
            "proguard-rules.pro"
        )
    }
}

この記事で触れていないこと

Product Flavor（プロダクトフレーバー）

Build Type と非常によく似た概念に Product Flavor があります。

Build Type（本記事で解説）

デバッグ用・リリース用といった「ビルドの工程や最適化」の違い

Product Flavor

無料版・有料版、あるいは「A社用」「B社用」といった「製品のバリエーション」の違い

これらを組み合わせた「ビルドバリアント（Build Variant）」の高度な活用法については、内容が多岐にわたるため、この記事では書きません。

各環境ごとのリソース（アイコンなど）の切り替え

applicationIdSuffix を使うとアプリの共存は可能になりますが、ホーム画面で「どっちが本番でどっちがデバッグか」を見分けるには、アイコンやアプリ名を変える工夫が必要です。これら「ソースセット（src/main 以外のディレクトリ管理）」の使い分けについても、この記事では書きません。

参考リンク