Android minimum target SDK matrix

Google has progressively introduced and tightened requirements around the targetSdkVersion apps must declare in order to be installed on devices and distributed through Google Play. These requirements exist as two distinct mechanisms: an on-device installation block enforced by Android itself, and Google Play's submission requirements that control app visibility and distribution. Together, they push the ecosystem towards modern, secure API levels.

Starting with Android 14, Google introduced an OS-level enforcement that outright prevents the installation of applications targeting very old API levels. When an app fails this check, Android throws an INSTALL_FAILED_DEPRECATED_SDK_VERSION security exception, and the installation is blocked regardless of the source - whether sideloaded, pushed via an EMM, or installed from a store.

The only bypass available is through ADB:

adb install --bypass-low-target-sdk-block name_of_package.apk

This on-device block has incremented as follows:

Apps already installed on a device before an OS upgrade are not affected; the block only applies to new installations.

For further details on the on-device block, see:

• Android 14 blocks apps targeting old Android versions
• Android 15 blocks app installs targeting Android versions below 7.0

Separately from the on-device block, Google Play enforces its own targetSdkVersion requirements for app submission and visibility. These requirements have been in place since 2018 and follow an annual cadence, typically requiring developers to target an API level within one version of the latest Android release.

There are two aspects to Google Play's enforcement:

1. Submission requirements - New apps and updates must target a minimum API level to be submitted to Google Play.
2. Visibility requirements - Existing apps that aren't updated will eventually become undiscoverable to users on newer Android versions, though users who previously installed the app can still find and reinstall it.

For organisations managing devices through an EMM, both mechanisms are relevant:

• On-device block: If a managed device is running Android 14 or later, any enterprise app targeting below the minimum API level will fail to install, whether pushed silently via the EMM or installed manually. This is particularly important for legacy line-of-business apps that may not have been updated in some time.
• Google Play requirements: Apps distributed through managed Google Play must meet the submission requirements to be updated, and will gradually lose visibility to users on newer Android versions if left unmaintained.

The practical takeaway is that organisations should ensure all enterprise applications target at least API level 24 (Android 7.0) today to guarantee installation across Android 14-16 devices, and should plan for this minimum to increase in future Android releases.

To validate the on-device minimum targetSdkVersion behaviour, the following demo APKs are available for sideloading. Each targets a specific API level and can be used to confirm which apps will and won't install on a given Android version:

To test, push an APK via ADB:

adb install bayton-sdk-demo-target22-android5.1.apk

On Android 14+ this will fail for APKs below the minimum targetSdkVersion with INSTALL_FAILED_DEPRECATED_SDK_VERSION. To bypass the block for testing purposes:

adb install --bypass-low-target-sdk-block bayton-sdk-demo-target22-android5.1.apk

The above applications have never been on Google Play and will likely trigger a Play Protect warning, you can bypass this when it pops up, otherwise you will receive a INSTALL_FAILED_VERIFICATION_FAILURE error. This is separate to the target SDK warnings.

• Android versions matrix - API levels, release dates, and end-of-life dates
• Google Play's target API level requirements
• Android developer documentation on meeting Google Play's target API level requirement
• Android 14 blocks apps targeting old Android versions
• Android 15 blocks app installs targeting Android versions below 7.0