Gradle build troubleshooting

This page covers build-time issues you may hit when the Kotzilla Gradle plugin runs alongside your own custom Gradle tasks. For the plugin's configuration options, see Kotzilla Gradle plugin configuration.

A build task conflicts with a Kotzilla task

Symptom

Your build fails with a Gradle work-validation error such as:

Reason: Task ':your-module:generateKotzillaBuildIdRelease' uses this output of task
':your-module:yourTask' without declaring an explicit or implicit dependency.
This can lead to incorrect results being produced, depending on what order the tasks are executed.

Cause

This happens when one of your own build tasks generates files into a source directory — for example src/main/assets, src/main/res, src/main/java, src/main/kotlin, or src/commonMain/…. Common culprits are asset packagers, resource generators, and code generators (protobuf/gRPC, OpenAPI, jOOQ, ANTLR, and similar).

The Kotzilla plugin reads your source directories to compute a stable build identifier, so Gradle asks you to declare the ordering between your generating task and Kotzilla's task.

note

This is a coupling between your task and Kotzilla's, not a Kotzilla bug in your app — nothing ships incorrectly. It only needs an explicit ordering so Gradle knows which task runs first.

Fix

Add one of the following to the build script of the module that owns both tasks (the module named in the error). Put it at the top level of the file.

Option 1 — declare the dependency (recommended). Kotzilla's build-id task will run after your generating task:

tasks.matching { it.name.startsWith("generateKotzillaBuildId") }
    .configureEach { it.dependsOn("yourTask") }

Option 2 — order only, without coupling execution. Use this if you don't want Kotzilla's task to trigger yours:

tasks.matching { it.name.startsWith("generateKotzillaBuildId") }
    .configureEach { it.mustRunAfter("yourTask") }

Option 3 — generate outside src/ (cleanest long-term). Have your task write into build/generated/… and register that as a generated source directory, so its output lives outside the tracked source tree entirely:

// Android
android.sourceSets.getByName("main").assets.srcDir(layout.buildDirectory.dir("generated/my-assets"))

tip

tasks.matching { it.name.startsWith("generateKotzillaBuildId") } covers every build variant in one statement (generateKotzillaBuildIdDebug, generateKotzillaBuildIdRelease, and so on). Replace "yourTask" with the exact task name from the error message.

Controlling when Kotzilla tasks run

By default, the plugin attaches a few tasks to your assemble/bundle lifecycle so they "just work" — a ProGuard mapping upload and a build report. If you run a release build for a reason that does not need them (a local smoke build, an APK-only CI job, an offline build), you can turn them off:

Behaviour	How to disable
ProGuard mapping upload after assemble/bundle	kotzilla { uploadMappingFile = false }
Build report network call after assemble	kotzilla { buildReport = false }
Build report on an offline build	run Gradle with --offline (the report call is skipped)
Any single Kotzilla task, one invocation only	--exclude-task <taskName>, e.g. --exclude-task uploadMappingFileRelease
All Kotzilla plugin behaviour in a module	kotzilla { enabled = false }

See Kotzilla Gradle plugin configuration for the full DSL.

Known limitations

ProGuard mapping comment on AGP 8.13+

On Android Gradle Plugin 8.13 and later, the plugin no longer writes its build-identifier comment into mapping.txt (AGP finalizes the published mapping file in a step that runs after the point where Kotzilla would annotate it).

This has no impact on crash symbolication or issue detection. The build identifier is still delivered to Kotzilla through the session data and the mapping upload, so nothing is lost — the in-file comment was only a convenience. No action is required.

note

If you inspect your mapping.txt on AGP 8.13+ and don't find a Kotzilla build-id comment, that is expected and not an error.