build.gradle で Android App Bundle の署名の設定をする

署名の設定

まず、Google Play App Signing の利用を前提に、アプリ署名の鍵類とアップロード署名の鍵類は、別のものを用意する想定である。
開発者はリリース時のアプリ署名を知る必要がないので、ここではアプリ署名を扱わない。アップロード署名した aab(Android App Bundle) ファイルをリリース管理者へ渡すまでが開発者の責務とする。

開発者が手元でのデバッグで apk ファイルを作成する場合はデバッグ署名し、リリース管理者へ渡す aab ファイルを作成する場合はアプリ署名する、というのを実現する署名の設定は次のようになる。

app/build.gradle

// ...

android {
    // ...

    defaultConfig {
        // ...

        // 基本的にはデバッグ署名を適用
        signingConfig signingConfigs.debug
    }

    signingConfigs {
        debug {
            // 開発者の誰かのデバッグ証明書をリポジトリに格納してしまう
	    // デフォルトのデバッグ証明書の場合はパスワード類の記載は必要なし
            storeFile rootProject.file('keysotore/debug.keystore')
        }
        upload {
            // アップロード証明書をリポジトリに格納してしまう。秘匿すべきはアプリ署名の方なので
            storeFile rootProject.file('keysotore/upload.keystore')
            storePassword 'hoge' // 直に書いてしまう
            keyAlias 'fuga' // 直に書いてしまう
            keyPassword 'piyo' // 直に書いてしまう
        }
    }

    // aab ファイルを作成する場合はアップロード署名を適用する
    for (taskName in gradle.startParameter.taskNames) {
        if (taskName.startsWith('bundle')) {
            defaultConfig.signingConfig = signingConfigs.upload
            break
        }
    }

    buildTypes {
        release {
            // ...
        }
    }

// ...

CI で動作確認用のアプリを配布する場合

上記の build.gradle で作成される、デバッグ署名された apk ファイルをそのまま配布すればよいが、もし Google Play で行われる aab -> apk の変換のステップをきちんと踏んで作成された apk ファイルで動作確認したい場合は、aab -> apk の変換の CI ワークフローを構築すればよい（CI で用意されていなければ bundletool を使って実現できる）。この変換の際、署名は引き継がれないので、CI 上で再度デバッグ署名する。
デバッグ署名でなくアプリ署名した apk ファイルで動作確認したい、という場合は、前述の再署名の際にアプリ署名を利用すればよいが、CI 上にアプリ署名を用意する必要があり、開発者がアプリ署名を触らないで済むという Google Play App Signing のメリットが無くなってしまうのでオススメはできない。もしアプリ署名した apk ファイルで動作確認したい場合は、Google Play からダウンロードする機能があるので、CI で自動配布みたいなことはできず手動となってしまうがそちらを利用した方がよいと思われる。

認証系の SDK を利用する場合

Firebase Auth や Facebook SDK 等、認証系の SDK を利用する場合は、SaaS 側へ証明書のフィンガープリントを登録することが求められるケースがある。その際は、デバッグ署名とアプリ署名の２つのフィンガープリントを登録すればよい。