🟤

flutter run --debug(release) と app/build.gralde

2024/06/27に公開

まえがき

Flutterアプリを開発していて、多用するflutter runコマンドのオプションに --debugと--releaseというビルドタイプがある。

それぞれを指定したときにandroid/app/build.gradleのbuildTypesやsigningConfig（リリース作業の時にkeystoreのプロパティなどを設定するときに編集するところ）の関係がこんがらがったので整理してみた

--debug と --release 違い

まず、flutter run --debug。
--debugオプションはデフォルトオプションでもあるので、flutter runとしただけでも--debugとして実行したことになる。

--debugでは、名前の通りデバッグビルドを行ってアプリをデバッグモードで実行するオプションである。
このモードでは、Flutterで有名なホットリロードやホットリスタートなどの開発用の機能が利用可能になり、
要は、デバッグがしやすいアプリの実行を提供してくれる。

--releaseでは、リリースビルドを行って最適化されたコードと最小限のデバッグ情報のみを含めるため、実際に製品版としてリリースするアプリのパフォーマンスに近い形で動作する。

主な違いまとめ

特徴	デバッグビルド	リリースビルド
目的	デバッグやテスト	配布
コンパイル方法	JITコンパイル	AOTコンパイル
デバッグ機能	ホットリロード、ホットリスタート、ステップ実行 etc.	無効
署名	デフォルトのデバッグキーで署名	カスタムのリリースキーで署名
アプリサイズ	大きい	小さい

flutter run --debug(release) と app/build.gradle

Flutterプロジェクトを作成した直後の android/app/build.graldeのbuildTypesは以下のようになっている。

...
    buildTypes {
        release {
            // TODO: Add your own signing config for the release build.
            // Signing with the debug keys for now, so `flutter run --release` works.
            signingConfig signingConfigs.debug
        }
    }
...

`flutter run --debug` と build.gradle

flutter run --debugを実行すると、Flutterは内部でGradleを使用してデバッグビルドを行います。このとき、buildTypes.debug に定義された設定が適用される。

なので、buildTypes.debugを読み込みたいですが、Flutterプロジェクト作成直後のこのbuild.gradleファイルにはbuildTypes.releaseのみでbuildTypes.debugは定義がない。

これはデバッグビルドでは署名設定は通常必要ではなく、Gradleビルドシステムは、特に設定がない場合はデフォルトのデバッグビルド設定を提供してくれるので、それを適用するという意味で定義がなく、このままで良い。

`flutter run --release` と build.gradle

flutter run --releaseを実行すると、Flutterは内部でGradleを使用してリリースビルドを行うと同時に、app/build.gradle の buildTypes.release に定義を適用する。

また、signingConfig signingConfigs.debugは、アプリに対する署名モードを指定している。

上記のgradleファイルの場合は、buildTypes.releaseがsigningConfig signingConfigs.debugとなっているので、この定義を適用する。

ただし、Flutterプロジェクト作成直後のこのbuild.gradleファイルにはsigningConfigsの定義はないが、ここもGradleビルドシステムのデフォルト設定を提供してくれるので、それを適用するという意味で定義がなく、このままで良い。

一方で、配布用のリリースビルドを作成するときはFlutterのドキュメントにもあるとおり、以下のようにapp/build.graldeにsigningConfigsを追加で定義し、signingConfigs.debugをsigningConfigs.release に変えるとある。

...
signingConfigs {
    release {
        keyAlias keystoreProperties['keyAlias']
        keyPassword keystoreProperties['keyPassword']
        storeFile keystoreProperties['storeFile'] ? file(keystoreProperties['storeFile']) : null
        storePassword keystoreProperties['storePassword']
    }
}

buildTypes {
    release {
        signingConfig signingConfigs.release
    }
}
...

上記の場合、flutter run --releaseコマンドが実行されると、app/build.gradleのbuildTypes.releaseの定義を見ていき、その中で signingConfig が signingConfigs.releaseとなっているので、その定義を見にいく。

signingConfigs.releaseには、署名のためのキーストアの情報が定義されているので、これらを適用してビルドファイルに対して署名を行うという流れになる。

なので、flutter run --releaseを実行する場合は、上記の定義が正しく設定されていないとビルドに失敗します。

あとがき

今回の内容を整理したきっかけは、 GitHub Actions でFlutterアプリのAndroidビルド(.aabファイル)を Play Console のテストトラックにアップロードするという設定を行う過程で、android/app/build.gradleのbuildTypesのsigningConfigs.debugの部分をシェルスクリプトでsigningConfigs.releaseに書き換えるというワークフローのジョブステップを定義したことであり、
わざわざこれを書き換えるシェルスクリプトを用意するくらいなら、初めからここの定義はsigningConfigs.releaseでいいのでは？　という発想からである。

結論としては、シェルスクリプトを残すことにした。
理由は、この記事の内容の通りflutter run --releaseはbuildTypes.releaseの定義を参照するので、ローカルでリリースビルドを確認したい時に署名情報が必要になり、このローカル手配を手間でありローカルに署名情報を置きたいくないという意図があるからでした。