How to change the application version and SDK in Android Studio

Development of mobile applications for the operating system Android requires constant monitoring of the versions of the tools used. In the environment Android Studio the concept of “application version” can be interpreted in two ways: it is either the version of the platform SDK itself on which the project is based, or the version of the specific app that you are developing (code version and user version). Errors in the configuration of these parameters often lead to the fact that the project simply does not compile or does not run on the emulator.

Inexperienced developers often encounter red error lines immediately after importing a project from the repository or creating a new module. Usually the problem lies in a mismatch between the versions compileSdkVersion, targetSdkVersion and the version of the plugin used Gradle. Understanding the version hierarchy allows you to quickly eliminate dependency conflicts and ensure stable operation of the development environment.

In this article we will analyze in detail the process of changing all key version parameters. You will learn where to look for SDK Manager settings, how to properly edit files build.gradle and what consequences entail downgrading or upgrading the target version of Android. Proper configuration of these parameters is the foundation for successfully building APK or AAB files.

The difference between the SDK version and the application version

Before making changes, it is necessary to clearly distinguish between concepts. Version SDK (Software Development Kit) determines which Android system APIs are available for your code to use. If you specify an SDK version lower than that required by the libraries used, the compiler will throw an unresolved symbol error.

The version of the application itself is divided into two parameters: versionCode and versionName. The first parameter is an integer and is used by the store Google Play to determine the priority of updates. The second value is the string visible to the user in the phone settings. Changing one of them does not affect the other, but both must be configured correctly for publication.

A common mistake is trying to change the platform version through the project settings without updating the assembly files. Android Studio caches configurations, so after changing the SDK in the manager, you may need to completely synchronize the project (Sync Project with Gradle Files). Ignoring this step results in the IDE continuing to use the old library paths.

⚠️ Attention: Downgrading compileSdkVersion below the level required by the included support libraries (AndroidX) is guaranteed to result in compilation errors. Always check the documentation of third-party libraries before changing this setting.

Configuring platform versions via the SDK Manager

To change the version of the operating system for which development is being carried out, a built-in tool is used SDK Manager. This interface allows you to download system images, platform tools, and system images for emulators. It is accessed through the main menu Tools → SDK Manager or through the icon in the top toolbar.

In the window that opens, you will see a list of available Android versions. Check mark in column Installed indicates that the components of this version are already downloaded to your computer. To change the active version of a project, you must make sure that the desired version (for example, Android 14 or API 34) is installed. If it is not there, check the box and click the button Apply to download.

After installing the new platform, it must be selected as the target for a specific project. This is done not in the manager itself, but in the module settings. Go to File → Project Structure (or click Ctrl+Alt+Shift+S). In the Modules section, select your main module (usually app) and in the Properties tab, change the value Compile Sdk Version to the one you just installed.

• 📱 Make sure that the version Build Tools is compatible with the selected platform version, otherwise the builder will not be able to generate the resulting file.
• 💾 When installing new versions of the SDK, free up disk space, as one complete package can take up more than 2 GB of space.
• 🔄 After changing the version in Project Structure be sure to click the OK n wait until the files are indexed.

Editing the build.gradle file to change the code version

The main place where the application version settings are stored is the file build.gradle module level (not to be confused with the project level file). In modern versions Android Studio this file may have the extension .ktsif the Kotlin language is used for build scripts. You can open it in the project tree by following the path Gradle Scripts → build.gradle (Module: app).

Inside the block android there is a section defaultConfig. This is where the key version parameters are written. The parameter versionCode must be a unique integer that increases with each new build. Parameter versionName takes a string value, such as "1.0.5", which is displayed in the app store.

android {
defaultConfig {
applicationId "com.example.myapp"
minSdkVersion 24
targetSdkVersion 34
versionCode 5
versionName "1.0.5"
}
}

Changing these values ​​does not require a restart of the IDE, but does require synchronization. As soon as you save the file (Ctrl+S), a notification will appear at the top of the window asking you to synchronize the project. Clicking the button Sync Now will apply the new values ​​to the build configuration. If you plan to upload to Google Play Console, remember that versionCode can never be less than or equal to the previous loaded value.

Manage dependency versions and Gradle Plugin

Often the problem with the application version is not in the code itself, but in the version of the plugin Gradle or libraries. At the beginning of the file build.gradle (project level) the version of the Android Gradle Plugin is indicated. If it is outdated, new SDK features may not be available, and if it is too new, old build methods may not work.

Dependencies in the block dependencies also have their own versions. Using a tight version link (for example implementation 'androidx.core:core-ktx:1.9.0') may cause a conflict if another library requires a newer or older version of the same component. To solve this problem, it is recommended to use version variables in a block ext or Version Catalogs in a file libs.versions.toml.

When updating the Gradle Wrapper version (file gradle-wrapper.properties), you may need to clear the cache. Old Artefacts in local storage sometimes prevent new libraries from loading correctly. The command ./gradlew clean in the terminal helps eliminate artifacts from previous builds that may conflict with new version settings.

Parameter	Configuration file	Impact on the project
compileSdk	build.gradle (Module)	Defines available APIs for code compilation
minSdk	build.gradle (Module)	Minimum Android version for installing the application
Gradle Plugin	build.gradle (Project)	Project Build Tool Version
versionCode	build.gradle (Module)	Internal version number for updates

What are Version Catalogs?

This is a new way to manage dependencies in Gradle, allowing library versions to be declared in one central file (libs.versions.toml), making it easier to update versions across the entire project immediately.

Resolving version conflicts and compilation errors

The situation when, after changing the version, the project stops building is standard for development. Errors like Unresolved reference often mean that you have downgraded compileSdkVersionand the code uses methods that only appeared in a newer version. In this case, it is necessary to either return a high version of the SDK, or rewrite the code, eliminating unsupported calls.

Library version conflicts are resolved through the dependency resolution mechanism. You can explicitly specify which version of the library to use in case of conflict by adding a block resolutionStrategy to the configuration. This is especially true when working with large projects, where different modules can run different versions of the same components AndroidX.

Sometimes Android Studio “sticks” to the old configuration even after making changes. In such cases, cache invalidation helps. Select File → Invalidate Caches...from the menu, check all the boxes and press Invalidate and Restart. This will force the IDE to rescan all files and re-download indexes, which often eliminates phantom version errors.

⚠️ Attention: Changing minSdkVersion to a higher value will make your application unavailable for devices with an older version of Android. Check device support statistics before increasing this threshold.

Using Flavor for different versions of the application

In professional development, it is often necessary to support several versions of one application at the same time: for example, free (Free) and paid (Paid), or version for debugging (Debug) and release (Release). For this purpose, build.gradle mechanism is used. It allows you to set different names and even resources for each variation. Flavors are configured inside the block. You can define different string resources per application version. For example, for the free version Product Flavors. It allows you to set different applicationId, names and even resources for each variation.

Flavors are configured inside the block android. You can define different string resources per application version. For example, for the free version versionName there may be "1.0-Free", and for the paid version - "1.0-Pro". When building a project, you select the desired option in the tab Build Variants at the bottom of the IDE window.

This approach allows you to manage versions flexibly without creating separate projects. You can define logic in code that will change the behavior of the application depending on the current build. For example, disable advertising in the flavor paid or change the server address for staging environment.

• 🛠 Set up different application icons for each flavor to visually distinguish between versions on the device.
• 🔐 Use different keys signatures (Keystore) for debug and release versions in the settings signingConfigs.
• 📦 Export APK files with version suffixes so as not to confuse build artifacts.

⚠️ Attention: The interface and capabilities of Android Studio are regularly updated. The location of some menu items or the names of tabs in new versions of the IDE (for example, Hedgehog, Giraffe) may differ from those described. Check the current paths in the official documentation if you do not find the required item.

Frequently asked questions (FAQ)

How to roll back the Gradle Plugin version to an older one?

To do this, open file build.gradle at the project level (root). Find the line classpath 'com.android.tools.build:gradle:x.y.z' inside the block dependencies. Replace the version number with the required one (for example, 7.4.2) and synchronize the project. Make sure that the Gradle Wrapper version in the file gradle-wrapper.properties is also compatible with the selected plugin version.

Why does Android Studio not see the installed version of Android?

Most often the problem is that the SDK Platform is installed, but the components Build-Tools for this version are not selected. Open SDK Manager, go to the tab SDK Tools and make sure the checkbox is opposite Android SDK Build-Tools. Also check the path to the SDK in the settings File → Settings → Appearance & Behavior → System Settings → Android SDK.

Is it possible to change the versionCode automatically with each build?

Yes, this can be done using the script in build.gradle. You can read the current date or number of commits in Git and assign this value to a variable versionCode. This guarantees the uniqueness of the build number without manual intervention by the developer.

Does changing the application version affect already installed users?

Changing versionName (visible name) does not affect the ability to update. However, if you change applicationId or sign the application with a different key, the app store will consider it a completely new application, and updating the old one will not work - the user will have to delete the old version before installing the new one.

Where are the files of old SDK versions stored after updating?

SDK files are stored in the directory specified in the Android settings Studio (by default this is a folder Android/Sdk in the user's home directory). Inside the folder platforms there are images of systems of different versions. It is not recommended to remove them manually; it is better to use the SDK Manager interface to safely remove unnecessary versions.