EErrorHarbor
Error Library

Plugin with id 'com.android.application' Not Found: Fix Gradle Plugin Resolution

When Gradle says plugin id com.android.application was not found, first identify how this project declares Android Gradle Plugin. Modern plugins {}/version-catalog builds and legacy buildscript { classpath(...) } builds do not use the same resolution path. Prove the declaration model before adding repositories, versions, or migrating DSL.

Android Gradle PluginAndroid Studio · GradleLast reviewed Sep 27, 2026
🎯 You’re likely in the right place if:
Gradle reports that plugin id `com.android.application` was not found.The error occurs during project configuration or sync, before app compilation.The project uses a `plugins {}` block, version catalog, or migrated Gradle configuration.
Choose the path that matches what you see
Modern plugins{} / version catalogTrace pluginManagement, the plugin version source and Google repository access.
Repository config is correct but no plugin version existsSupply the Android Gradle Plugin version at the project/version-catalog level.
Legacy buildscript/classpath projectTrace the buildscript repository/classpath declaration; do not force a plugins{} migration just to fix this error.
Project is intentionally mid-migrationIdentify which mechanism owns com.android.application in the failing build before deleting either configuration.
Resolution fails only behind a proxy/firewallTest access to Google Maven/Gradle repositories before changing build files further.
Difficulty: ModerateRisk: Low first
🔎 First check — identify the plugin declaration model

Search the root/module build files and version catalog before editing repositories. If com.android.application comes from a modern plugins {} declaration or alias, inspect pluginManagement. If the project still supplies AGP through buildscript/classpath, follow that legacy resolution path instead.

pluginManagement { repositories { google() mavenCentral() gradlePluginPortal() } }

Verify: You can point to exactly one intended source of the Android plugin version/resolution for the failing module. Do not add pluginManagement as a generic fix to a project that is intentionally using the legacy buildscript model.

Was google() missing from pluginManagement?
ADSENSE · reserved slot after the first useful step

Why this happens

Modern Gradle plugin DSL resolution is configured separately from ordinary project dependency repositories, and Android Gradle Plugin artifacts are available through Google's Maven repository. Legacy Android builds can instead put the AGP artifact on the buildscript classpath and then apply the plugin by id. Because both patterns exist in real projects, the same visible plugin id can fail for different repository/version reasons.

Diagnose before changing more

1
Which mechanism owns com.android.application?
Modern plugins DSL/root plugin declaration, version-catalog alias, or legacy buildscript classpath? Diagnose that mechanism rather than mixing fixes across all three.
2
For plugins{} / aliases, where does the version come from?
A module can apply the plugin without repeating a version when the root build or version catalog already supplies it. Do not assume every module declaration needs its own version.
3
For the modern plugin DSL, does settings.gradle(.kts) contain google() inside pluginManagement?
Putting google() only in dependencyResolutionManagement is not the same as making it available for plugin resolution.
4
Did this project recently migrate DSL or AGP versions?
Check that the plugin declaration style and version source still match the project structure.
5
Legacy buildscript/classpath?
Check the buildscript repository and AGP classpath coordinates/version. pluginManagement is not a drop-in repair for a build that has not migrated to the plugins DSL.
6
Does resolution fail only on one network/CI machine?
Keep the build files stable and test repository/proxy/offline access in the failing environment before changing plugin versions.

Fix #2 — declare the Android plugin version at the project level

If your project does not use a version catalog, declare a project-compatible Android Gradle Plugin version in the top-level build file and apply it in the app module. Current Android documentation uses the same plugins { id("com.android.application") version "…" apply false } model for AGP 9.x. Do not blindly paste the current documentation's version into an older project: AGP, Gradle and JDK compatibility still has to match your project.

// top-level build.gradle.kts plugins { id("com.android.application") version "" apply false } // app/build.gradle.kts plugins { id("com.android.application") }
🟡 Before changing configuration: Use an AGP version compatible with the project’s Gradle and JDK versions.

Verify: Sync or run ./gradlew tasks. The build should resolve com.android.application and move past the plugin-not-found stage.

Did Fix #2 work?

Fix #3 — legacy buildscript or migration: repair the mechanism you actually use

If this is a legacy project, verify its existing buildscript { repositories { ... } dependencies { classpath(...) } } path instead of introducing pluginManagement solely to silence the error. If the project is intentionally migrating to the plugins DSL, migrate as a deliberate project change: establish the modern version source and plugin repositories, then remove the obsolete ownership only after the new path resolves.

./gradlew tasks
🟡 Keep it reversible: Run from the project root. If resolution fails before tasks are listed, read the first plugin-resolution error rather than changing unrelated dependencies.

Verify: Run the same Gradle command from the project root. If a new compatibility or dependency error appears, the plugin-resolution problem is fixed—diagnose the new error separately.

Did Fix #3 work?

What not to do

Do not paste the newest AGP version into an older project without checking Gradle and JDK compatibility.Do not add google() only under normal dependency repositories when the failure is specifically plugin resolution.Do not keep two competing plugin-declaration systems indefinitely after a migration is complete.Do not force a legacy project onto the plugins DSL merely because com.android.application could not resolve.Do not add a plugin version to every app/module declaration when the root build or version catalog already owns that version.Do not change AGP versions to troubleshoot a proxy/offline repository failure until repository access is proven.

Still seeing the error?

If the intended declaration model and its repositories/version source are correct but Gradle still cannot resolve the plugin, preserve the first concrete resolution message. A repository/proxy/offline failure, nonexistent plugin version, and AGP/Gradle/JDK compatibility failure are different stages. Once Gradle resolves com.android.application and reports a later compatibility/configuration error, stop applying plugin-not-found fixes.

Before escalating, capture:the exact Gradle plugin-not-found messagesettings.gradle/settings.gradle.kts pluginManagement blocktop-level plugin declaration or version catalog entryGradle and JDK versionswhether repository access works inside the failing environmentwhether the project uses plugins DSL, version-catalog alias, legacy buildscript/classpath, or an intentional migrationthe first concrete repository/version/compatibility error after plugin lookup

References and related guides

checkDebugAarMetadata FailedIf an AAR declares a compileSdk, AGP or SDK-extension requirement →Android Resource Linking Failed (AAPT2)When the build reaches resources, read the first concrete AAPT2 error →Android Developers: Configure your buildOfficial pluginManagement and top-level plugin configuration →Android Developers: About Android Gradle PluginCurrent AGP 9.x plugin declaration and upgrade guidance →Android Developers: Migrate build configuration to Kotlin DSLOfficial examples for com.android.application and plugin repositories →Gradle: Declaring repositoriesHow plugin repositories differ from dependency repositories →

Still stuck? Ask the community

Share your operating system, software version, exact error text, and which fix you already tried. Another reader may have seen the same setup.

Keep it safe: never post passwords, API keys, access tokens, recovery codes, license keys, private URLs, or confidential logs.
Powered by GitHub DiscussionsSign in with GitHub to comment. Reading comments does not require sign-in.

Loading community discussion…