Debugging log · Build

targetSdk 36 build errors: the ones I actually hit

Bumping ten apps to compileSdk/targetSdk 36 produced a predictable sequence of build errors — the same few, in roughly the same order, across projects. If your build just went red after setting the target to 36, here's the roundup with the fix for each, so you can jump to yours. For the wider story, see migrating 10 apps to target API 36.

1. AGP doesn't know about API 36

Set compileSdk = 36 on an older Android Gradle Plugin and the build refuses — it can't compile against an API level it's never heard of. The fix is to move to an AGP that supports Android 16:

// build.gradle(.kts) — plugins / classpath
com.android.tools.build:gradle  →  8.9.1   // 8.9.0+ supports API 36

If you were on AGP 8.6 or 8.7, this is your first stop; nothing else compiles until AGP is new enough.

2. Gradle version too low for the new AGP

Bumping AGP triggers the next link in the chain — a plain version-compatibility message that the Gradle wrapper is too old:

distributionUrl=...gradle-8.11.1-bin.zip   // AGP 8.9 needs Gradle 8.11.1+

Update gradle/wrapper/gradle-wrapper.properties and re-sync. These first two errors are a cascade: SDK forces AGP, AGP forces Gradle.

3. Kotlin plugin complains about the AGP version

On older projects (Kotlin 1.9.x) the Kotlin Gradle plugin warns or errors that the applied AGP is newer than it was tested with. Moving Kotlin to 2.0.21+ clears it. Note that with a newer Kotlin and an older-but-supported AGP you may still see a non-fatal "higher than the maximum tested" warning — that one is safe to ignore and the build still completes.

4. "SDK location not found" / missing platform

Even with the right AGP, the build fails if the Android 16 platform isn't installed. Open the SDK Manager and install Android 16 (API 36) and Build-Tools 36. Also confirm your Gradle JDK is 17, which AGP 8.x requires. This is environment, not code — the fix is in the SDK Manager, not the build file.

5. lint-vital fails the release build

This one only appears on the release build, because release runs lintVital, which is fatal by default. A common trigger is ExtraTranslation:

Error: "some_key" is translated here but not found in
default locale [ExtraTranslation]

It means a string exists in a locale file (e.g. values-en) but not in the default values/strings.xml. These are usually dead strings left over from a removed feature. The right fix is to delete the orphaned strings from the locale file, not to silence the check with a baseline. A quick way to catch them all: compare each locale's string keys against the default and remove any that don't exist in the default.

6. "The process cannot access the file" (Windows)

This looks alarming and code-related but isn't:

...lint-cache/...RuntimeIssueRegistry-....jar:
The process cannot access the file because it is being
used by another process

It's a Windows file lock on a lint-cache jar — a stray Gradle daemon, an antivirus scan, or a file-sync client (OneDrive/Dropbox) holding the file. Nothing to do with your code. Fix: gradlew --stop, then clean and rebuild; if it persists, close the IDE and delete the module's build folder, or reboot. Read the whole error line — the useful part ("used by another process") is at the end.

7. Runtime, not build: content under the system bars

Not a compile error, but it shows up the first time you run the app: targeting 36 enforces edge-to-edge, so toolbars and buttons can slide under the status and navigation bars. That has its own fix — see content hidden behind the status bar. Worth knowing so you don't mistake it for a layout regression you caused.

Tooling versions and Play requirements change over time; confirm the current AGP/Gradle/SDK combination and the target API requirement against the official Android and Play Console documentation before shipping.