Debugging log · Gradle

"…requires libraries to compile against version X or later"

I bumped one AndroidX library to its latest version, synced, and the build stopped before it even compiled anything — complaining that the dependency needed a newer compile SDK than my project used. Nothing in my code had changed. This is one of those errors that looks alarming but is really just Gradle enforcing a version contract, and the fix is a single number.

The short version: a library you depend on was built against a newer Android API level than your compileSdk. The checkDebugAarMetadata task enforces that your app compiles against at least that level. Raise compileSdk to the version the message asks for. This is a compile-time setting only — it does not change which devices your app runs on.

The error

Execution failed for task ':app:checkDebugAarMetadata'.
> Dependency 'androidx.core:core:1.15.0' requires libraries and
  applications that depend on it to compile against version 35
  or later of the Android APIs.
  :app is currently compiled against android-34.

The message is unusually clear for a Gradle error: it names the exact dependency and the exact API level it wants. The only confusing part is why raising this is safe, which is where people hesitate.

Why this happens

When a library is compiled against, say, API 35, it may reference APIs that only exist from 35 onward. If your app compiled against API 34, those references could be unresolved at build time. AGP's AAR-metadata check catches this early and refuses to build, rather than letting you hit confusing errors later. It's a guardrail, not a bug — the library is simply newer than your compile target.

The fix — raise compileSdk

Set compileSdk to at least the version named in the error:

android {
    compileSdk = 35   // was 34
}

Sync and rebuild. That's usually the entire fix. If the AGP version is too old to know about that SDK, you may also see a note to update the Android Gradle Plugin — bump AGP to a version that supports the new compileSdk, then set the level.

Why raising compileSdk is safe

This is the part worth internalizing, because it's the crux of the confusion. The three SDK settings do different jobs:

compileSdk — the API level your code is compiled and checked against. It affects the build, not runtime behavior.
minSdk — the oldest Android version your app installs on. This is what determines device reach.
targetSdk — the version your app is tested and behaves as, controlling opt-in behavior changes.

Raising compileSdk alone does not drop any devices — that's minSdk's job, and you're not touching it. You're only letting the compiler see the newer APIs the library needs.

Don't "fix" this by downgrading the library back to an older version unless you truly must. It works, but you lose the fixes and features you upgraded for. Raising compileSdk addresses the actual requirement.

If it still fails after raising compileSdk

Update AGP if the new compileSdk isn't recognized — the plugin must be new enough to support that API level.
Install the SDK platform for that level via the SDK Manager if the build can't find android-35.
Check every module — a library module can carry its own compileSdk, and the failing one might not be :app.
Do a clean sync after the change so cached metadata doesn't keep reporting the old level.

Version numbers above are examples — use the exact API level and library version your own error names.