Fix Outdated Kotlin Runtime Warnings in Android Studio Gradle Projects

This page explains the difference between the Kotlin plugin installed in Android Studio and the Kotlin runtime dependency used by an Android app. You will learn how to declare Kotlin versions in Gradle, keep the Kotlin Gradle plugin and kotlin-stdlib aligned, and safely sync the project after making changes.

A Kotlin Android project uses Kotlin in more than one place:

• Android Studio Kotlin plugin: Adds Kotlin editing, inspections, navigation, and IDE support.
• Kotlin Gradle plugin: Lets Gradle compile Kotlin source files.
• Kotlin standard library (kotlin-stdlib): Runtime classes and functions your compiled app uses, such as collections, ranges, and utility functions.

The warning appears because Android Studio sees a Kotlin runtime library in your project's Gradle dependencies that may not match the Kotlin tooling version it expects.

For a Gradle project, dependencies are controlled by Gradle files, not by Android Studio's library-update button. Therefore, the IDE cannot safely change the runtime automatically: projects can have multiple modules, version variables, dependency constraints, or shared build configuration.

The usual fix is to define one Kotlin version in Gradle and reuse it for both:

1. the Kotlin Gradle plugin, and
2. the kotlin-stdlib dependency.

This reduces the chance that one module compiles with one Kotlin version while packaging a different runtime version.

Think of Kotlin versions as parts of a tool set:

• The IDE plugin is the instruction manual in the workshop.
• The Kotlin Gradle plugin is the machine that builds the product.
• The standard library is the set of parts included with the product.

The instruction manual may be updated separately from the machine and parts. What matters most for building the app is that the build machine and included parts are compatible. Keeping their version numbers in one Gradle variable is like ordering both parts from the same tool-set box.

In older Android Gradle projects, Kotlin was commonly configured in the root build.gradle file:

buildscript {
    ext.kotlin_version = '1.1.2'

    dependencies {
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
    }
}

Then the app module's build.gradle uses the same variable:

apply plugin: 'kotlin-android'

dependencies {
    implementation "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"
}

The important part is this shared value:

$kotlin_version

When you update the Kotlin version, change it once in the root Gradle configuration, then let every Kotlin dependency use that value.

In projects using the modern Gradle plugins block, the equivalent idea is:

plugins {
    id 'org.jetbrains.kotlin.android' version '2.0.0' apply false
}

And in the Android module:

plugins {
    id 'org.jetbrains.kotlin.android'
}

dependencies {
    implementation 'org.jetbrains.kotlin:kotlin-stdlib:2.0.0'
}

Use a Kotlin version that is published and compatible with your Android Gradle Plugin and Gradle versions. Do not copy an Android Studio plugin build suffix, such as -release-Studio2.3-3, into a Maven dependency unless that exact artifact is documented and available.

Consider this older-style Gradle setup.

// Root build.gradle
buildscript {
    ext.kotlin_version = '1.1.2'

    dependencies {
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
    }
}

// app/build.gradle
dependencies {
    implementation "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"
}

When Gradle builds the app:

1. Gradle assigns '1.1.2' to kotlin_version.
2. The build classpath resolves org.jetbrains.kotlin:kotlin-gradle-plugin:1.1.2.
3. The app dependency resolves org.jetbrains.kotlin:kotlin-stdlib:1.1.2.
4. Kotlin source is compiled with the configured Gradle plugin.
5. The Kotlin standard library is included as an app dependency when needed.

To update the project, change the version in one place:

ext.kotlin_version = 'NEW_COMPATIBLE_VERSION'

Then use Sync Project with Gradle Files. Gradle downloads the new artifacts and recalculates dependency versions.

If the warning still appears after syncing, use Build > Clean Project and Build > Rebuild Project. Also inspect all modules, because another module may declare a hard-coded older kotlin-stdlib version.

Kotlin version alignment matters in many everyday situations:

• Android apps with multiple modules: A feature module should not silently use a different Kotlin runtime from the app module.
• Shared libraries: An Android library should declare Kotlin dependencies predictably so applications can resolve compatible versions.
• CI builds: A build server does not use your local Android Studio settings; Gradle configuration must contain the required versions.
• Dependency upgrades: Updating Android Gradle Plugin, Gradle, or Kotlin may require checking compatibility among all three tools.
• Debugging build failures: Errors involving missing Kotlin classes or metadata versions often point to inconsistent Kotlin artifacts.

Real projects avoid repeating literal version strings throughout module build files.

Centralize the version

Older Gradle builds often use an extra property:

ext.kotlin_version = '1.1.2'

Modern projects commonly use a version catalog in gradle/libs.versions.toml:

[versions]
kotlin = "2.0.0"

[plugins]
kotlin-android = { id = "org.jetbrains.kotlin.android", version.ref = "kotlin" }

[libraries]
kotlin-stdlib = { module = "org.jetbrains.kotlin:kotlin-stdlib", version.ref = "kotlin" }

This provides one source of truth.

Prefer dependency resolution over IDE updates

For Gradle projects, developers normally:

1. Update the version declaration in Gradle.
2. Sync the project.
3. Run tests and build the app.
4. Check the dependency tree if versions conflict.

For example, Gradle can show resolved dependencies:

./gradlew :app:dependencies

If another dependency requests an old Kotlin artifact, the report helps identify where it came from.

Keep compatibility in mind

Do not upgrade Kotlin in isolation when a project is old. Verify that the selected Kotlin version supports the project's Gradle and Android Gradle Plugin versions. Upgrade related build tooling together when necessary.

Editing only the Android Studio plugin

Updating the IDE plugin does not automatically update your project's Gradle dependencies. The project can still compile with an older Kotlin Gradle plugin or use an older standard library.

Hard-coding different versions

This configuration can cause compatibility problems:

// Root build.gradle
ext.kotlin_version = '1.1.2'

// app/build.gradle
dependencies {
    implementation 'org.jetbrains.kotlin:kotlin-stdlib:1.0.7'
}

Avoid this by referencing the same version variable:

implementation "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"

Copying an IDE-specific plugin suffix into Gradle

A version such as 1.1.2-release-Studio2.3-3 can identify an Android Studio plugin build. It is not automatically a valid version for Maven artifacts such as kotlin-stdlib.

Use the Kotlin version published for Gradle and Maven dependencies, or use the version explicitly recommended by your project's Kotlin documentation.

Updating one module only

Large projects may have several build.gradle files. Search the project for:

kotlin-stdlib
kotlin-gradle-plugin
org.jetbrains.kotlin

Remove or update unexpected hard-coded versions.

Assuming the warning always means the app is broken

IDE warnings can sometimes be caused by tooling-version detection rather than a runtime failure. Still, centralizing and aligning declared Gradle versions is the correct first action. If the build succeeds and all Gradle Kotlin dependencies are aligned, consider updating Android Studio/Kotlin tooling or checking known issues for that historical tool version.

// Older root build.gradle
buildscript {
    ext.kotlin_version = '1.1.2'
    dependencies {
        classpath "org.jetbrains.kotlin:kotlin-gradle-plugin:$kotlin_version"
    }
}

// Older app/build.gradle
dependencies {
    implementation "org.jetbrains.kotlin:kotlin-stdlib:$kotlin_version"
}

• Update Kotlin dependencies in Gradle, not only in Android Studio settings.
• Keep kotlin-gradle-plugin and kotlin-stdlib aligned when possible.
• Use one version variable or a version catalog.
• Run Sync Project with Gradle Files after editing build files.
• Search every module for hard-coded kotlin-stdlib versions.
• Do not assume an Android Studio plugin suffix is a Maven artifact version.
• If upgrading fails, verify compatibility among Kotlin, Gradle, and Android Gradle Plugin.

Why does Android Studio say it cannot update Kotlin runtime automatically?

Gradle owns dependency declarations in Android projects. Android Studio cannot safely guess which module, shared variable, version catalog, or dependency rule should be changed.

Where do I change the Kotlin runtime version?

Find org.jetbrains.kotlin:kotlin-stdlib in a module build.gradle file. Ideally, make it use the same centralized version as the Kotlin Gradle plugin.

Is the Android Studio Kotlin plugin version the same as the Kotlin standard library version?

Not necessarily. The IDE plugin may include an Android Studio-specific suffix. Your Gradle dependencies should use published Kotlin artifact versions.

Do I need to declare kotlin-stdlib manually in every modern Kotlin project?

Not always. Modern Kotlin Gradle plugin setups may add standard library dependencies automatically. Check your project configuration and avoid adding conflicting explicit versions.

What should I do after changing build.gradle?

Sync Gradle, build the project, and run tests. If an old version remains, inspect the Gradle dependency report and search other modules for Kotlin declarations.

Can different Kotlin versions cause build errors?

Yes. Common symptoms include incompatible Kotlin metadata, missing classes, compiler errors, or unexpected behavior caused by dependency resolution.

Should I always install the newest Kotlin version?

Use a version compatible with your project's Gradle and Android Gradle Plugin versions. Older projects may need coordinated upgrades rather than a single Kotlin-only update.

• Gradle dependencies — Kotlin runtime libraries are resolved through Gradle dependency declarations.
• Kotlin Gradle plugin — This plugin compiles Kotlin code and should be configured consistently with Kotlin libraries.
• Android Gradle Plugin — Android builds depend on compatibility between AGP, Gradle, and Kotlin.
• Dependency version conflicts — Explains how Gradle chooses one version when multiple libraries request different versions.
• Gradle version catalogs — A modern way to define shared dependency and plugin versions in one location.
• Multi-module Android projects — Multiple modules make centralized version management especially important.
• Gradle sync — Reloads build configuration after changes to Gradle files.