Solved: Your app is not installable on Android API less than 30

Problem statement

The app is not installable on devices with Android API less than 30. The app signing key had been upgraded for an unknown reason, and there is an issue with rolling out the release when the minSdk version is less than 30.

Proposed solution

Regarding Multiple APKs support

To roll out a new release, we need to upload an app bundle and an APK signed with the legacy key in every release. Google Play will use the app bundles to generate APKs signed with the new key for devices on Android R* (API level 30) or later. The legacy APKs will be used for older Android releases (up to API level 29).

For this case, it helps to support different platform versions with each APK.

How multiple APKs work

The concept of using multiple APKs on Google Play is that there is only one entry in Google Play for the application, but different devices might download different APKs. This means that:

• You maintain only one set of product details/content, meaning you cannot charge a different price for different APKs.
• All users see only one version of your application on Google Play, preventing confusion between different versions.
• All user reviews apply to the same application listing, even though different devices may receive different APKs.
• When a device updates its Android system, Google Play automatically updates the app to a compatible version.

API Level Considerations

The multiple APKs approach relies on the android:minSdkVersion and android:maxSdkVersion attributes in the manifest file.

For example, you can publish your application with:

• one APK that supports API levels 16 - 19 (Android 4.1.x - 4.4.4); using only APIs available since API level 16 or lower
• Another APK that supports API levels 21 and above (Android 5.0+); using APIs available since API level 21 or lower.

To learn how to build separate APKs that each target a different range of APIs, go to Configure Product Flavors.

If an APK has a higher android:minSdkVersion, it must also have a higher android:versionCode to ensure proper versioning and updates through Google Play.

This ensures that when a device receives a system update, Google Play can offer the user an update for your application; because updates are based on an increase in the app version code.

This requirement is described further in the section below about Rules for multiple APKs.

You should avoid using android:maxSdkVersion in general, because as long as you've properly developed your application with public APIs, it is always compatible with future versions of Android.

If you want to publish a different APK for higher API levels, you still do not need to specify the maximum version, because if the android:minSdkVersion is "16" in one APK and "21" in another, devices that support API level 21 or higher will always receive the second APK (because its version code is higher, as per the previous note).

Rules for multiple APKs

Before you publish multiple APKs for your application, you need to understand the following rules:

• All APKs you publish for the same application must have the same package name and be signed with the same key.
• Each APK must have a unique version code.
• Each APK must not exactly match the configuration support of another APK. and thus, each APK will declare support for different devices.
• An APK that requires a higher API level must have a higher version code.
• If multiple APKs differ only by API levels, or if they also use another distinguishing factor (e.g., screen size) but have overlapping filters, their version codes must increase in correlation with API levels.

For example, say you have an active APK for screen sizes small - normal with version code 0400, then try to replace it with an APK for the same screen sizes with version code 0300. This raises an error, because it means users of the previous APK will not be able to update the application.
This is true only when either: the APKs differ based only on the supported API levels or when the APKs do use another supported filter, but there is an overlap between the APKs within that filter.

This is important because a user's device receives an application update from Google Play only if the version code for the APK on Google Play is higher than the version code of the APK currently on the device. This ensures that if a device receives a system update that then qualifies it to install the APK for higher API levels, the device receives an application update because the version code increases.

Examples of the rules

• If an APK for API levels 16+ (Android 4.1.x+) has a version code of 0400, then an APK for API levels 21+ (Android 5.0+) must have a version code of 0401 or higher.
• If one APK supports API level 16+ and screen sizes small to large, while another supports API level 21+ and screen sizes large to xlarge, the version codes must increase with API levels since large screens overlap. In this case, the API level filter is used to distinguish each APK, but so is the screen size. Because the screen sizes overlap (both APKs support large screens), the version codes must still be in order. This ensures that a large screen device that receives a system update to API level 21 will receive an update for the second APK.
• If one APK supports API level 16+ with small to normal screens and another supports API level 21+ with large to xlarge screens, the version codes do not need to increase, since there is no overlap within the screen size filter, there are no devices that could potentially move between these two APKs, so there's no need for the version codes to increase from the lower API level to the higher API level.

Assigning version codes

Each APK must have a unique versionCode, formatted to maintain order and allow flexibility for updates.

Each APK for the same application must have a unique version code, specified by the  android:versionCode attribute. You must be careful about assigning version codes when publishing multiple APKs, because they must each be different, but in some cases, must or should be defined in a specific order, based on the configurations that each APK supports.

Ordering version codes

An APK that requires a higher API level must usually have a higher version code. For example, if you create two APKs to support different API levels, the APK for the higher API levels must have the higher version code. This ensures that if a device receives a system update that then qualifies it to install the APK for higher API levels, the user receives a notification to update the app.

Using a version code scheme

In order to allow different APKs to update their version codes independent of others (for example, when you fix a bug in only one APK, so don't need to update all APKs), you should use a scheme for your version codes that provides sufficient room between each APK so that you can increase the code in one without requiring an increase in others. You should also include your actual version name in the code, so that it's easy for you to associate the version code and version name.

versionCode 21012
versionName '0.1.2'

//21: API level (constant)
//012: version name (incremental)

versionCode 30012
versionName '0.1.2'

//30: API level (constant)
//012: version name (incramental)

Reference:

• Multiple APK support, developer.android