How to change the API in Android Studio: a complete guide to SDK versions

Development of mobile applications for the operating system Android is inextricably linked with constant platform updates. Google releases new versions of the OS every year, introducing new features, improving security, and changing permissions rules. For a developer, this means the need to regularly update their project so that it meets modern store standards Google Play and works correctly on current devices.

The process of changing the API level (API Level) often raises questions among novice specialists, as it affects several configuration files and can lead to compilation errors. In this article, we will look in detail at how to correctly change the SDK version in Android Studio, what is the difference between different types of versions, and how to avoid common problems when migrating to a new API level.

Changing the target version of an application is not just about changing a number in the code. This is a complex process that requires checking library compatibility, analyzing legacy methods, and testing the interface on new emulators. Understanding the versioning architecture will allow you to keep the project up to date without losing functionality on older devices.

Understanding API levels and their role in the project

Before making changes to the configuration, it is necessary to clearly distinguish three key parameters that control versions in the assembly file. Confusion between them is the most common cause of errors when trying to “change API”. In the build system, Gradle these parameters determine what features you can use and what devices your application will run on.

The parameter compileSdkVersion indicates which version Android SDK your project will be compiled against. Increasing this value gives access to new APIs and platform features, but does not affect which devices can run the application. You can use new methods, but you must ensure that they do not crash on older versions of the OS.

The second critical parameter is minSdkVersion. This is the minimum version of Android on which your application can run. Setting a value too high here will automatically cut out users with older smartphones, while a value too low will limit you to using modern features without writing a lot of compatibility conditions.

The third parameter, targetSdkVersiontells the system that your application has been tested and optimized to run on the specified version of Android. It is this setting that controls system behavior with respect to your application, including the application of new security rules and permissions. Google Play Requires this setting to comply with current store requirements.

⚠️ Attention: Increasing targetSdkVersion may result in unexpected application behavior if you are using legacy methods for handling permissions or background tasks. The system will begin to apply new restrictions specific to the target version.

Preparing the development environment and installation SDK

To change the API level, first of all, you need to make sure that the required version of the platform is already installed in your development environment. Android Studio It will not allow you to compile a project specifying an SDK version that is not physically present on your computer. The installation process of components is carried out through the built-in SDK manager.

Open the IDE settings by going to the menu Tools → SDK Manager. In the window that opens, you will see a list of available Android versions. The tab SDK Platforms contains system images, and the tab SDK Tools contains build tools. Find the required version of Android in the list (for example, Android 14 or API 34) and make sure that there is a checkmark next to it.

If the required version is not installed, check it and press the button Apply or OK. The manager will download the necessary files, including system images for the emulator and platform files. This process may take some time depending on the speed of your Internet connection.

• 📦 Make sure that not only the platform is installed, but also the appropriate version Build-Tools.
• 💾 Check for updates for Android SDK Platform-Tools in the tools tab.
• 🔄 After installing new components, it is recommended to synchronize project (Sync Project).

Changing the configuration in the build.gradle file

The main work of changing the API occurs in the build configuration file. Modern versions use a script-based approach or a classic approach. The structure may be slightly different depending on whether you use the new versioning system for catalogs (Version Catalogs) or a classic block Android Studio a script-based approach is used Kotlin DSL (build.gradle.kts) or classic Groovy (build.gradle). The structure may be slightly different depending on whether you are using the new Version Catalogs system or the classic block android.

In the classic version of an application module file (usually build.gradle application module (usually app/build.gradle), you need to find a block android and a section inside it defaultConfig. This is where the key versioning parameters are located. Changing the values ​​in this block requires subsequent synchronization of the project with the Gradle files.

android {
compileSdk 34

defaultConfig {
applicationId "com.example.myapp"
minSdk 24
targetSdk 34
versionCode 1
versionName "1.0"
}
// ... the rest of the configuration
}

If you use the current approach with Version Catalogs (file libs.versions.toml), then the version values ​​are placed in a separate file in the project root. In this case, you need to edit the file toml, finding the section [versions], and change the values there, or refer to new versions directly in the module build file.

After making changes to the assembly file code, Android Studio automatically prompts you to synchronize the project. Click the Sync Nowbutton that appears at the top of the editor. During the synchronization process, Gradle will download new dependencies and check the compatibility of the specified versions with the installed SDK components.

Solving compatibility issues and migrating code

Simply changing numbers in the configuration file often leads to compilation errors or warnings (Warnings). This indicates that your code is using methods that have been marked as deprecated (@Deprecated) or whose behavior has changed in a new version of the API. Ignoring these warnings may lead to unstable operation of the application.

When increasing targetSdkVersion the system begins to strictly control access to resources. For example, starting with Android 10 (API 29), access to external memory has changed, and Android 12 (API 31) has tightened the requirements for the accuracy of location data and working with the clipboard. You may need to add OS version checks before calling certain methods.

To ensure safe use of new APIs on older devices, a version checking construct is used. This allows you to call the modern method only if the device supports it, and execute an alternative script otherwise. This approach ensures maximum audience coverage while using advanced features.

if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.S) {
// Code for Android 12 (API 31) and higher
clipboard.setPrimaryClip(clipData)
} else {
// Fallback for older versions
clipboard.setText(text)
}

⚠️ Attention: Using an annotation @SuppressLint to hide warnings is only permissible if you are absolutely sure of security code. Blindly suppressing warnings often masks real compatibility issues.

What is Support Library and AndroidX?

In the past, library support was required to use new features on older devices. Now all components have been transferred to AndroidX, which automatically provides compatibility when the dependencies are configured correctly.

Updating dependencies and libraries

Changing project-level APIs often requires updating third-party libraries. Many popular libraries, such as Retrofit, Glide or Roomalso depend on SDK versions. If you lift compileSdkVersionbut leave older versions of libraries, you may encounter version conflicts or missing required classes.

Check your project's dependency file. Make sure that the library versions you are using support the new API level. Library developers usually specify the minimum and target SDK versions in the documentation. Incompatibility may manifest itself in errors like MethodNotFound during runtime.

Component	Recommended version	Min. API	Note
Android Gradle Plugin	8.x.x	API 21+	Requires JDK 17
AndroidX Core	1.12.0+	API 14+	Basic utilities
Material Components	1.11.0+	API 21+	UI elements
ConstraintLayout	2.1.4+	API 14+	Interface layout

Particular attention should be paid to the plugin Android Gradle Plugin. New versions of a plugin often require an update to the Java Development Kit (JDK). Starting from plugin version 8.0, the use of JDK 17is a mandatory requirement. Check the JDK settings in the menu File → Project Structure → SDK Location.

Testing on emulators and real devices

The final and most important stage of changing the API is comprehensive testing. Changing the target version may silently break the layout, change the behavior of animations, or break permissions. Theoretical compatibility does not guarantee correct operation in practice.

Use Android Virtual Device (AVD) to create emulators with different OS versions. Run the application on an emulator with the minimum supported version (minSdk) and on an emulator with the target version (targetSdk). This will allow you to identify regressions and problems specific to certain versions of the platform.

Pay attention to the system logs (Logcat). When running on a new version of Android, the system may display warnings about using hidden APIs or violating background policies. Also check the application in the "Don't keep activities" mode to identify problems with saving state.

• 📱 Test the application on a real device with the latest version of Android.
• 🐞 Enable the display of borders of interface elements to check the layout.
• 🔒 Check critical permission requests (camera, geolocation, notifications).

⚠️ Attention: Emulator interfaces may differ from real devices due to differences in GPU drivers and hardware configuration. Always do final testing on a physical smartphone before publishing.

Frequently asked questions (FAQ)

What happens if I set the targetSdk below the required Google Play?

When you try to upload a new application or update in the Google Play Console, you will receive a build rejection error. The store requires that targetSdkVersion meets current requirements (usually the latest or penultimate major version of Android). The application will not pass moderation.

Is it possible to use the new API if minSdk is old?

Yes, this is possible and is standard practice. You can use the new API methods, but you must wrap them in a version check (if (Build.VERSION.SDK_INT >= ...)). For some functions, you can use Backport libraries from AndroidX.

How can I find out what behavioral changes await my version of the API?

All information about Behavior Changes is published in the official documentation for Android developers for each OS version. The "Behavior changes" section describes in detail what will change for applications with a certain targetSdkVersion.

Is it necessary to change the compileSdk when updating the targetSdk?

It is desirable, but not strictly necessary within one major version. However, to access new methods and classes introduced in the new version of Android, you will have to raise compileSdkVersion to the appropriate level. It is recommended to keep compileSdk always at the latest available version.

Why does the application crash on startup after changing the API?

The most likely reason is using a remote method or changing permission requirements. Check the logs Logcat immediately after the crash. Also make sure that all dependencies are updated and compatible with the new compilation version.