PC パソコン

Android Studio「INSTALL_FAILED_OLDER_SDK」の解決方法

Android Studioから実機やAndroid Emulatorへアプリをインストールしようとした際に、「INSTALL_FAILED_OLDER_SDK」というエラーが表示されることがあります。

Installation failed with message INSTALL_FAILED_OLDER_SDK

このエラーは、基本的にアプリが要求している最低Androidバージョンより、インストール先端末のAndroidバージョンが古い場合に発生します。

AndroidアプリではminSdkによって対応する最低APIレベルを指定します。たとえばアプリのminSdkが26なのに、Android 7.1相当のAPI 25端末へインストールしようとすると、その端末ではアプリを実行できないためインストールが拒否されます。

この記事では、「INSTALL_FAILED_OLDER_SDK」が発生する原因と、Android Studioで確認したい設定や解決方法を順番に解説します。

INSTALL_FAILED_OLDER_SDKとは

Androidアプリには、そのアプリを実行できる最低Android APIレベルを指定するminSdkがあります。

たとえば次の設定では、アプリはAPI 26以上を必要とします。

android { defaultConfig { minSdk 26 } }

Kotlin DSLでは次のようになります。

android { defaultConfig { minSdk = 26 } }

このAPKをAPI 25以下のAndroid端末へインストールしようとすると、Androidは対応していない端末だと判断し、インストールを拒否することがあります。

ADBでは次のようなエラーが表示される場合があります。

adb: failed to install app-debug.apk: Failure [INSTALL_FAILED_OLDER_SDK]

主な原因

1.端末のAndroidバージョンがminSdkより古い

最も一般的な原因です。

たとえばアプリ側が次の設定になっているとします。

minSdk = 26

これをAPI 25の端末へインストールすることはできません。

API 26はAndroid 8.0に相当するため、それより古いAndroidバージョンの端末はアプリの対応範囲外になります。

2.minSdkを最近引き上げた

依存ライブラリの変更やアプリの仕様変更に伴い、minSdkを高く設定した後で、以前使っていた古いテスト端末へRunするとエラーになることがあります。

以前は問題なくインストールできていた場合でも、Gradle設定を変更した直後ならminSdkを確認してください。

3.依存ライブラリによって最低APIレベルの条件が変わった

新しいライブラリを追加した結果、プロジェクト全体として以前より高いAndroid APIを必要とするケースがあります。

Manifest mergerやGradleビルド時の警告なども確認してください。

4.古いAndroid Emulatorを選択している

Android Studioで複数のAVDを作成している場合、意図せず古いAPIレベルのEmulatorを選択していることがあります。

たとえば開発対象がAPI 26以上なのに、API 23のAVDへインストールしようとしていればエラーになります。

5.古い実機をテスト端末として使用している

長期間使用しているAndroid端末では、OSアップデートが提供されず、アプリ側の最低対応バージョンを満たせなくなることがあります。

解決方法1:端末のAndroid APIレベルを確認する

まず、インストール先のAndroidバージョンを確認してください。

実機では通常、設定 → デバイス情報 → Androidバージョンなどから確認できます。

ADBを使用する場合は、次のコマンドでAPIレベルを確認できます。

adb shell getprop ro.build.version.sdk

たとえば次のように表示された場合、端末のAPIレベルは25です。

25

Androidバージョン自体を確認したい場合は、次のコマンドも利用できます。

adb shell getprop ro.build.version.release

出力例:

7.1.2

解決方法2:プロジェクトのminSdkを確認する

次に、Android Studio側の最低対応APIレベルを確認します。

Groovy形式のbuild.gradleでは、一般的に次のような設定があります。

android { defaultConfig { applicationId "com.example.myapp" minSdk 26 targetSdk 35 } }

Kotlin DSLでは次の形式です。

android { defaultConfig { applicationId = "com.example.myapp" minSdk = 26 targetSdk = 35 } }

端末のAPIレベルがminSdkより小さければ、その端末はアプリの対応対象外です。

重要:targetSdkやcompileSdkではなく、INSTALL_FAILED_OLDER_SDKでまず確認するのはminSdkです。

minSdk・targetSdk・compileSdkの違い

Android開発では複数のSDKバージョン設定があるため、混同しやすいポイントです。

  • minSdk:アプリをインストール・実行できる最低APIレベル
  • targetSdk:アプリが動作確認・最適化の対象としているAPIレベル
  • compileSdk:アプリをコンパイルするときに使用するAndroid APIレベル

たとえば次の設定でも問題ありません。

minSdk = 24 targetSdk = 35 compileSdk = 35

この場合、API 24以上の端末でアプリを実行できる可能性があります。

「compileSdkが35だからAndroid 15でしか動かない」という意味ではありません。

解決方法3:より新しいAndroid端末を使用する

アプリ側のminSdkを下げる必要がない場合は、最低APIレベルを満たす実機またはEmulatorを使用するのが最も安全な解決方法です。

たとえばアプリが次の設定なら、

minSdk = 26

API 26以上のAndroid端末をテスト対象として選びます。

古い実機しかない場合は、新しいAPIレベルのAndroid Emulatorを作成してテストできます。

解決方法4:新しいAndroid Emulatorを作成する

Android StudioのDevice Managerから、アプリのminSdk以上のSystem Imageを使用したAVDを作成します。

たとえばminSdk = 26なら、API 26以上のSystem Imageを選択してください。

作成後、そのEmulatorを起動してAndroid StudioからRunを実行します。

ポイント:複数のEmulatorがある場合は、Run時に選択しているAVDのAPIレベルも確認してください。

解決方法5:必要ならminSdkを下げる

古いAndroid端末も正式にサポートしたい場合は、アプリ側のminSdkを下げられるか検討します。

たとえば現在次の設定なら、

minSdk = 26

アプリの機能やライブラリが対応していることを確認したうえで、次のように変更できる場合があります。

minSdk = 24

ただし、数字だけを下げれば必ず動くわけではありません。

API 26以上でしか利用できない機能を使用している場合は、古いAndroidバージョン向けの分岐処理などが必要になります。

古いAndroidでも動かす場合のバージョン分岐

新しいAPIだけで利用できる処理を使用する場合は、Androidバージョンによって処理を分けることがあります。

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) { // Android 8.0(API 26)以上で実行する処理 } else { // 古いAndroid向けの処理 }

これにより、minSdkを低く維持しながら新しいAndroid専用APIを条件付きで使用できる場合があります。

注意:APIレベルの条件分岐だけでは対応できないライブラリや機能もあります。利用している依存関係の最低対応APIも確認してください。

解決方法6:依存ライブラリのminSdk条件を確認する

新しいライブラリを追加した直後に問題が発生した場合は、そのライブラリが要求する最低Android APIレベルを確認します。

たとえば、プロジェクト側では低いminSdkを設定したいのに、依存ライブラリ側がより高い最低APIを要求している場合があります。

この場合は次のいずれかを検討します。

  • アプリのminSdkを上げる
  • より古いAndroidにも対応するライブラリバージョンを使用する
  • 別のライブラリへ置き換える
  • 該当機能を古いAndroidでは使用しない設計にする

解決方法7:APK自体のminSdkを確認する

「Gradleでは正しく設定したはずなのにインストールできない」という場合は、最終的に生成されたAPKの最低SDKを確認すると原因を切り分けられます。

Android SDK Build Toolsのaaptを使う場合は、次のように確認できます。

aapt dump badging app-debug.apk

出力には次のような情報が含まれる場合があります。

sdkVersion:'26' targetSdkVersion:'35'

sdkVersionがAPKの最低APIレベルです。

端末側のAPIレベルと比較してください。

解決方法8:正しいBuild Variantを使用しているか確認する

productFlavorsを使用している場合、ビルドvariantによってminSdkが異なることがあります。

たとえば次のように開発版と製品版で条件を分けているプロジェクトでは、選択するvariantによって対応端末が変わる可能性があります。

productFlavors { modern { minSdk 26 }
legacy {
    minSdk 23
}

}

Android StudioのBuild Variantsから、現在どのvariantを実行しているか確認してください。

解決方法9:Manifest mergerの結果を確認する

アプリ本体や依存ライブラリに複数のManifestが存在するプロジェクトでは、最終的なAndroidManifest.xmlがマージされます。

設定変更やライブラリ追加後に最低SDK条件が変わったように見える場合は、Android StudioのMerged Manifestなどを確認すると原因を探しやすくなります。

Gradleのビルド時にSDKバージョンの競合に関する警告やエラーが出ていないかも確認してください。

Android端末をOSアップデートする

実機がメーカーから新しいAndroidバージョンへのアップデートを提供されている場合は、OSアップデートでアプリの最低APIレベルを満たせることがあります。

ただし、端末によっては新しいAndroidバージョンが提供されないため、その場合は別の実機またはEmulatorを使用する必要があります。

「INSTALL_FAILED_OLDER_SDK」が突然出るようになった場合

以前は同じ端末にインストールできていたのに突然エラーが出るようになった場合は、次の変更がなかったか確認してください。

  • GradleのminSdkを引き上げた
  • 新しい依存ライブラリを追加した
  • ライブラリのバージョンを更新した
  • Build Variantを変更した
  • productFlavorの設定を変更した
  • 別の古い実機やEmulatorを選択している

特にライブラリ更新やGradle設定変更の直後であれば、変更前後のminSdkを比較してください。

それでも解決しない場合

「INSTALL_FAILED_OLDER_SDK」が続く場合は、次の順番で確認してください。

  • adb shell getprop ro.build.version.sdkで端末APIを確認する
  • GradleのminSdkを確認する
  • 生成済みAPKの最低SDKを確認する
  • 正しい実機・Emulatorを選択しているか確認する
  • Build VariantやproductFlavorを確認する
  • 最近追加・更新した依存ライブラリを確認する
  • 古いAndroidもサポートする必要があるか再検討する

まとめ

Android Studioの「INSTALL_FAILED_OLDER_SDK」は、主にアプリのminSdkよりインストール先Android端末のAPIレベルが低い場合に発生します。

まず次の2つを比較してください。

端末のAPIレベル adb shell getprop ro.build.version.sdk

アプリの最低APIレベル
minSdk

端末のAPIレベルがminSdkより低ければ、そのままではアプリをインストールできません。

  1. 端末のAPIレベルを確認する
  2. プロジェクトのminSdkを確認する
  3. 必要なら新しい実機またはEmulatorを使う
  4. 古いAndroidを対応対象にするならminSdkを下げられるか検討する
  5. 新しいAPIを使う部分にはバージョン分岐を検討する
  6. 依存ライブラリやBuild Variantの最低SDK条件も確認する

単にエラーを消すためだけにminSdkを下げるのではなく、そのAndroidバージョンでアプリの全機能が安全に動作できるかを確認したうえで対応することが重要です。