What Are SDK Versions?

In the Android ecosystem, there are three critical types of SDK versions: Min SDK Version, Target SDK Version, and Compile SDK Version. Each serves a distinct purpose:

• Min SDK Version: This indicates the lowest Android version that an application can support. For instance, a Min SDK version of 21 means the app is compatible with Android Lollipop and later.
• Target SDK Version: This specifies the Android version for which the app is optimized to run.
• Compile SDK Version: This denotes the Android version used during the application's compilation. For example, if API 31 is set as the compile SDK version, the app can only utilize features available up to API 31, or else it will result in a compile-time error.

It's important to note that these SDK versions aren't limited to a single module or application; they can be configured for every module and at the library level as well.

Section 3.1 Approach 1: Seek an Alternative Library

Searching for an alternative library should be the first course of action since it avoids the need for significant changes to your existing code. However, you should consider factors such as the library's size, its active development status, and of course, the relevant SDK versions.

If you're fortunate enough to find a suitable alternative, you're in luck! Otherwise, the next steps will require adjustments to your current setup.

Section 3.2 Approach 2: Upgrade the Application's Min SDK

If you've exhausted the alternative options, upgrading your application's Min SDK may be necessary. The effort involved will depend on the project's complexity and architecture.

To begin, you need to modify the minSdkVersion in the build.gradle file at the app level under the defaultConfig section. Once you've done that, synchronize the project, and consult the Android developer documentation for guidelines on upgrading Min SDK versions.

After syncing, be prepared for potential compile-time errors, particularly if you're upgrading from Android 5 to Android 6, which may require implementing runtime permission consents. Once you've resolved compile-time errors, thorough testing of the entire application is essential to identify any runtime issues.

Section 3.3 Approach 3: When Upgrading Is Not an Option

This approach is necessary when:

• An alternative library cannot be used for specific reasons.
• Upgrading the application's Min SDK is not feasible due to factors like reduced market coverage or team capacity.

In this case, the library must be integrated without changing the application's Min SDK version. This means the library's functionality should only be utilized under certain conditions, specifically when the device's Android version meets or exceeds the library's Min SDK version.

To address technical aspects, begin by integrating the library in the app's build.gradle file or the relevant sub-module. After syncing, you will likely encounter compile-time errors due to incompatible Min SDK versions.

To resolve this, add the following code to your manifest file:

<uses-sdk

android:minSdkVersion="16"

android:targetSdkVersion="30" />

Then, ensure to include this code in the application node:

<application

android:usesLibrary="library_name" />

The uses-sdk tag defines the application's compatibility with specified Android platform versions. The uses-library element indicates that the application must link to a shared library.

Although this resolves compile-time issues, it is also critical to prevent runtime crashes. To do this, restrict access to the SDK based on the minimum SDK version of the library:

if(Build.VERSION.SDK_INT >= Build.VERSION_CODES.N) {

// Initialize the SDK here

}