Android Studio「The APK is not signed」の解決方法

The APK is not signed APK is not signed ERROR: JAR_SIG_NO_SIGNATURES DOES NOT VERIFY

「The APK is not signed」とは

APKには、開発者が持つ秘密鍵を利用したデジタル署名が必要です。

署名には主に次の役割があります。

• APKを作成した署名者を識別する
• APKが署名後に改変されていないか確認する
• 同じアプリの更新版が正しい署名者から提供されているか確認する
• 署名ベースのAndroidセキュリティ機能を利用する

Androidでは証明書を認証局から取得する必要はなく、一般的なAndroidアプリでは開発者自身が保持する秘密鍵に対応した証明書で署名します。 :contentReference[oaicite:2]{index=2}

代表的な発生状況

• Release APKをビルドしたとき
• Android StudioからAPKをエクスポートしたとき
• assembleReleaseを実行したとき
• 手動ビルドしたAPKをadbでインストールしたとき
• 第三者ストアへAPKをアップロードしたとき
• 署名設定を削除したあと
• 別PCへプロジェクトを移行したあと
• build.gradle.ktsやbuild.gradleを書き換えたあと
• CI/CDでRelease APKを生成したとき
• APKを後処理・再圧縮したあと

主な原因

1．Release Build TypeにSigningConfigが設定されていない

もっとも多い原因です。

Android公式ドキュメントでは、GradleはReleaseビルドについて、SigningConfigを明示的に設定しない限りAPKやAABを署名しないとされています。 :contentReference[oaicite:3]{index=3}

たとえば、

buildTypes { getByName("release") { isMinifyEnabled = false } }

だけではRelease署名設定がありません。

2．app-release-unsigned.apkを使っている

ビルド方法によっては、次のような未署名APKが生成されることがあります。

app-release-unsigned.apk

このファイルをそのままインストール・配布すると署名エラーになります。

3．Keystoreを作っただけでSigningConfigへ設定していない

KeystoreファイルがPCに存在していても、それだけではRelease APKは自動的に署名されません。

Gradleに、

storeFile storePassword keyAlias keyPassword

を設定し、Release Build Typeと関連付ける必要があります。 :contentReference[oaicite:4]{index=4}

4．SigningConfigはあるがReleaseへ割り当てていない

次のようにSigningConfigを作っただけでは不十分です。

signingConfigs { create("release") { ... } }

Release Build Typeへ、

signingConfig = signingConfigs.getByName("release")

を設定する必要があります。

5．手動でAPKを作成したあと署名していない

Android StudioやGradleの自動署名を使わず、APKを手動生成した場合は、Android SDK Build Toolsのapksignerなどで署名する必要があります。

6．署名後にAPKを編集した

署名済みAPKを展開・編集・再圧縮すると、署名が無効になる場合があります。

APK Signature Scheme v2以降ではAPK全体に近い範囲が署名保護されるため、署名後の変更によってインストールできなくなります。Android公式の過去リリース資料でも、署名後の変更はv2署名を無効にすると説明されています。 :contentReference[oaicite:5]{index=5}

7．CI/CDで署名用Secretが設定されていない

ローカルでは署名済みRelease APKが生成されるのにCIだけ未署名になる場合は、Keystoreや環境変数がCIへ渡されていない可能性があります。

8．別のBuild Variantをビルドしている

想定しているReleaseではなく、署名設定のないFlavorや別のBuild Typeをビルドしている場合があります。

9．Keystore設定をセキュリティ対策で外部化したが読み込めていない

環境変数やkeystore.propertiesから署名情報を読み込む構成では、ファイルや環境変数が存在しないとRelease署名設定が完成しません。

確認手順1：apksignerで署名を確認する

最初にAPKそのものを確認します。

apksigner verify app-release.apk

より詳しく確認する場合：

apksigner verify --verbose --print-certs app-release.apk

署名されていないAPKでは検証に失敗します。

確認手順2：APKファイル名を確認する

出力フォルダを確認します。

app/build/outputs/apk/release/

次のような名前なら注意してください。

app-release-unsigned.apk

unsignedという名前が含まれている場合、そのAPKは署名工程を別途行う前提で生成されている可能性があります。

確認手順3：Release SigningConfigを確認する

module-levelのbuild.gradle.ktsまたはbuild.gradleを開きます。

次の2点を確認します。

1. signingConfigsにRelease設定がある
2. buildTypes.releaseがそのSigningConfigを使用している

解決方法1：Kotlin DSLでRelease SigningConfigを設定する

android { signingConfigs { create("release") { storeFile = file("release.jks") storePassword = "STORE_PASSWORD" keyAlias = "release" keyPassword = "KEY_PASSWORD" } }
buildTypes {
    getByName("release") {
        signingConfig = signingConfigs.getByName("release")
    }
}

}

Android公式ドキュメントでも、Release SigningConfigを作成し、Release Build Typeに割り当てる例が示されています。 :contentReference[oaicite:6]{index=6}

解決方法2：GroovyでRelease SigningConfigを設定する

android { signingConfigs { release { storeFile file("release.jks") storePassword "STORE_PASSWORD" keyAlias "release" keyPassword "KEY_PASSWORD" } }
buildTypes {
    release {
        signingConfig signingConfigs.release
    }
}

}

設定後にRelease APKを再生成してください。

解決方法3：Android Studioから署名済みAPKを作る

手動でGradleを編集したくない場合は、Android Studioの署名作成機能を利用できます。

Build → Generate Signed App Bundle or APK

APKを選択し、次を入力します。

• Key store path
• Key store password
• Key alias
• Key password

Android公式ドキュメントでは、Android StudioとGradleを利用して秘密鍵で署名されたRelease APKを自動生成できると説明されています。 :contentReference[oaicite:7]{index=7}

解決方法4：Keystoreをまだ持っていない場合は作成する

Android StudioのGenerate Signed App Bundle or APK画面から新しいKeystoreを作成できます。

作成後、Keystoreと秘密鍵は必ず安全に保管してください。

Android公式ドキュメントでも、Keystoreと秘密鍵を安全な場所へ保存し、確実なバックアップを保持するよう注意されています。 :contentReference[oaicite:8]{index=8}

解決方法5：手動でapksignerを使って署名する

未署名APKがある場合、Android SDK Build Toolsのapksignerで署名できます。

apksigner sign --ks release.jks app-release-unsigned.apk

元ファイルを残す場合：

apksigner sign --ks release.jks --out app-release.apk app-release-unsigned.apk

署名後に必ず検証します。

apksigner verify --verbose --print-certs app-release.apk

解決方法6：Key Aliasを明示する

Keystore内に複数の鍵がある場合：

apksigner sign \ --ks release.jks \ --ks-key-alias release \ --out app-release.apk \ app-release-unsigned.apk

実際のAliasは次で確認します。

keytool -list -v -keystore release.jks

解決方法7：Keystoreが正しいか確認する

keytool -list -v -keystore release.jks

確認する項目：

• Keystore Password
• Alias
• 証明書情報
• SHA-256フィンガープリント

別アプリ用Keystoreを指定していないか確認してください。

解決方法8：Release Build Typeへの割り当て漏れを直す

次のような設定では、SigningConfigを作成しただけです。

signingConfigs { create("release") { ... } }

次も必要です。

buildTypes { getByName("release") { signingConfig = signingConfigs.getByName("release") } }

Android公式ドキュメントもこの構成を使用しています。 :contentReference[oaicite:9]{index=9}

解決方法9：環境変数を使用している場合は値を確認する

Android公式ドキュメントでは、パスワードをBuild Scriptへ直接書かず、環境変数から取得する方法も案内されています。 :contentReference[oaicite:10]{index=10}

Kotlin DSL：

storePassword = System.getenv("KSTOREPWD") keyPassword = System.getenv("KEYPWD")

macOS / Linux：

printenv KSTOREPWD printenv KEYPWD

Windows PowerShell：

$env:KSTOREPWD $env:KEYPWD

解決方法10：keystore.propertiesを確認する

たとえば：

storeFile=/Users/user/AndroidKeys/release.jks storePassword=STORE_PASSWORD keyAlias=release keyPassword=KEY_PASSWORD

確認するポイント：

• ファイルが存在するか
• Keystoreパスが正しいか
• Aliasが正しいか
• パスワードに不要な空白がないか
• Releaseビルド時に実際に読み込まれているか

解決方法11：署名情報をGitへ直接保存しない

Gradleへ次のように直接パスワードを書くことはできます。

storePassword = "password" keyPassword = "password"

しかしAndroid公式ドキュメントでも、Release KeyやKeystoreのPasswordをBuild Scriptへ直接保存するのは適切なセキュリティ対策ではないとされています。 :contentReference[oaicite:11]{index=11}

環境変数やローカルの秘密設定ファイル、CI/CD Secretなどで管理してください。

解決方法12：正しいBuild Variantを選択する

Android StudioのBuild Variants画面で、意図したRelease Variantを選択してください。

Flavorを使用している場合：

freeDebug freeRelease paidDebug paidRelease

など複数のVariantが存在します。

Release SigningConfigが一部Variantだけに適用されていない可能性も確認してください。

解決方法13：GradleからRelease APKを再ビルドする

macOS / Linux：

./gradlew clean ./gradlew assembleRelease

Windows：

gradlew.bat clean gradlew.bat assembleRelease

SigningConfigが正しく設定されていれば、署名済みRelease APKが生成されます。

解決方法14：ビルド成果物を再確認する

通常は次のような場所を確認します。

app/build/outputs/apk/release/

生成されたAPKごとに、

apksigner verify --verbose --print-certs APK_FILE

を実行し、どのファイルが署名済みか確認してください。

解決方法15：zipalignと署名の順番を確認する

手動でAPKを処理する場合は、基本的に、

Build ↓ 必要なAPK処理 ↓ zipalign ↓ apksigner sign ↓ apksigner verify

の順番にします。

署名後にAPKの内容を変更すると署名が無効になるためです。

解決方法16：署名後にAPKを再圧縮しない

次のような処理を署名後に行っていないか確認してください。

• APKをZIPとして開いてファイル追加
• Manifestの直接編集
• 画像ファイル置換
• 独自のZIP圧縮
• CI/CDの後処理

APK Signature Scheme v2以降では、署名後の変更が署名検証失敗につながります。 :contentReference[oaicite:12]{index=12}

解決方法17：CI/CDでKeystoreファイルを確認する

CI/CDでKeystoreをBase64などから復元している場合は、復元直後に確認します。

keytool -list -v -keystore release.jks

ここで失敗する場合は、APK署名以前にKeystore復元処理に問題があります。

解決方法18：CI/CDで署名済みAPKを検証する

Releaseパイプラインの最後に、

apksigner verify --verbose --print-certs app-release.apk

を実行すると、未署名APKの配布を防ぎやすくなります。

Debug APKはなぜ普通にインストールできる？

Android StudioではDebug Build Typeについて、一般的なDebug Keystoreを使用する署名設定が自動で構成されます。Android公式ドキュメントでも、新規プロジェクトではDebug Buildが汎用Debug Keystoreで署名されると説明されています。 :contentReference[oaicite:13]{index=13}

そのため、

app-debug.apk → 自動署名される app-release.apk → Release SigningConfigが必要

という違いがあります。

Debug KeystoreでRelease APKを署名してよい？

開発中の一時的なテストなら技術的に可能な場合がありますが、公開用Release APKをDebug Keyで署名するのは避けてください。

本番配布には適切に管理したRelease KeyまたはUpload Keyを使用してください。

APKが署名済みか最短で確認する方法

apksigner verify --verbose --print-certs app-release.apk

これで検証できなければ、署名工程またはAPK後処理を見直します。

「The APK is not signed」と「APK signature verification failed」の違い

「The APK is not signed」は、署名が存在しない、または有効な署名として認識されない状態を比較的直接示します。

一方、

APK signature verification failed

では、署名が存在していても、APKの変更や署名データの破損によって検証に失敗している場合があります。

「The APK is not signed」と署名不一致は別問題

APKが正しく署名されていても、すでにインストールされている同じApplication IDのアプリと異なる鍵で署名されていれば更新できません。

APKが署名済み ≠ 既存アプリと同じ署名鍵

既存アプリの更新問題では、旧APKと新APKの証明書を比較してください。

APKの署名証明書を確認する

apksigner verify --print-certs app-release.apk

Keystore側：

keytool -list -v -keystore release.jks

両方の証明書情報を確認すると、意図した鍵で署名されているか判断できます。

Google Play App Signingを使用している場合

Google Play App Signingでは、開発者がアップロードに使用するUpload Keyと、Google Playが配布APKへ使用するApp Signing Keyが別になっている場合があります。

そのため、ローカルで生成するAPKやAABでは、現在のUpload KeyまたはRelease署名構成を正しく使用してください。

また、Keystoreや秘密鍵は安全に管理し、バックアップする必要があります。現在のAndroid公式ドキュメントでもこの点が強調されています。 :contentReference[oaicite:14]{index=14}

最短で解決したい場合

1. apksigner verify --verbose --print-certs app.apkを実行する
2. ファイル名にunsignedが入っていないか確認する
3. Release SigningConfigが存在するか確認する
4. Release Build TypeへSigningConfigが割り当てられているか確認する
5. KeystoreとAliasを確認する
6. Release APKを再ビルドする
7. 必要ならapksigner signで手動署名する
8. 署名後すぐにapksigner verifyする

それでも解決しない場合

「The APK is not signed」が続く場合は、次を確認してください。

• 本当にRelease APKを使用しているか
• app-release-unsigned.apkを使っていないか
• Release SigningConfigが存在するか
• SigningConfigがRelease Build Typeに割り当てられているか
• 正しいKeystoreを使用しているか
• Key Aliasが正しいか
• Store PasswordとKey Passwordが正しいか
• keystore.propertiesが読み込まれているか
• 環境変数が設定されているか
• CI/CDにKeystoreとSecretが渡されているか
• 署名後にAPKを変更していないか
• apksigner verifyで確認したか
• 別のBuild Variantを誤って使用していないか

まとめ

Android Studio「The APK is not signed」は、主にRelease APKへ有効なデジタル署名が設定されていない場合に発生します。

Androidでは、すべてのAPKをインストールまたは更新する前に署名する必要があります。 :contentReference[oaicite:15]{index=15}

最初に次を実行してください。

apksigner verify --verbose --print-certs app-release.apk

署名されていなければ、Release SigningConfigを設定します。

signingConfigs { create("release") { storeFile = file("release.jks") storePassword = "STORE_PASSWORD" keyAlias = "release" keyPassword = "KEY_PASSWORD" } }

buildTypes {
getByName("release") {
signingConfig = signingConfigs.getByName("release")
}
}

現在のAndroid公式ドキュメントでも、GradleはReleaseビルドを自動署名せず、SigningConfigを明示的に作成してRelease Build Typeへ割り当てる必要があると説明されています。 :contentReference[oaicite:16]{index=16}

未署名APKを手動署名する場合は、

apksigner sign --ks release.jks --out app-release.apk app-release-unsigned.apk

を利用し、その直後に、

apksigner verify --verbose --print-certs app-release.apk

で確認してください。

また、署名後にAPKを変更すると署名が無効になるため、APKの編集や最適化をすべて完了してから最後に署名することが重要です。 :contentReference[oaicite:17]{index=17}