v0.11.0: addDebugLicense() regression persists for projects with product flavors

[rvandermeulen]

Issue #353 reported addDebugLicense() failures on debugOssLicensesTask and was closed as fixed in v0.11.0. However, the fix appears incomplete for projects that use product flavors; the regression persists when the variant combines a flavor name with the debug build type.

Error:

Could not find method addDebugLicense() for arguments [] on task
':app:focusDebugOssLicensesTask' of type
com.google.android.gms.oss.licenses.plugin.LicensesTask.

Project structure:

flavorDimensions "product"
productFlavors {
    focus { ... }
    klar { ... }
}
// build types: debug, release
// → variants: focusDebug, focusRelease, klarDebug, klarRelease

The task focusDebugOssLicensesTask fails; focusReleaseOssLicensesTask succeeds. Projects without a separate flavor dimension (where variants are just build type names like debug, nightly, release) are not affected, consistent with the original fix only covering the no-flavor case.

Versions: plugin 0.11.0, AGP 8.13.2, Gradle 9.4.1

[rvandermeulen]

Possible cause

In LicensesTask.groovy, addDebugLicense() is declared private, while every other helper method in the class (initOutputDir, addGooglePlayServiceLicenses, addLicense, etc.) is protected. When Gradle's ExtensibleDynamicObject attempts to dispatch the method call during task execution, it cannot resolve private methods, so it falls through to the "Could not find method" error path.

This path is triggered for debug variants because DependencyTask writes ABSENT_ARTIFACT when METADATA_LIBRARY_DEPENDENCIES_REPORT is absent (expected for debug build types), and LicensesTask.action() then calls addDebugLicense() to handle that case.

Suggested fix

Change the visibility of addDebugLicense() from private to protected:

-    private void addDebugLicense() {
+    protected void addDebugLicense() {

This is consistent with the visibility of all other helper methods in the class.

[rvandermeulen]

Following up with more detail after local reproduction in our project.

Repro

The failure reproduces consistently with ./gradlew clean test, which runs jobs for all variants including multiple product flavors. It does not reproduce when invoking focusDebugOssLicensesTask directly. This points to Gradle daemon/metaclass state accumulated across prior variant task executions as a factor.

What the stack trace shows

Caused by: org.gradle.internal.metaobject.AbstractDynamicObject$CustomMessageMissingMethodException:
  Could not find method addDebugLicense() for arguments [] on task ':app:focusDebugOssLicensesTask'
    at AbstractDynamicObject.invokeMethod(AbstractDynamicObject.java:172)
    at LicensesTask_Decorated.invokeMethod(Unknown Source)
    at LicensesTask.action(LicensesTask.groovy:101)

Gradle generates LicensesTask_Decorated as a runtime subclass of LicensesTask and overrides invokeMethod to delegate to AbstractDynamicObject. When action() calls addDebugLicense(), Groovy dispatches it through LicensesTask_Decorated.invokeMethod, which cannot resolve private methods.

Why it is intermittent

Groovy's metaclass is initialized lazily per class in the daemon. The non-debug flavor tasks (focusBetaOssLicensesTask, etc.) run first and do not call addDebugLicense(). Depending on the state of the LicensesTask metaclass by the time the debug variant task runs, the method may or may not be reachable. This explains why standalone task invocations sometimes succeed while clean test fails consistently.

Suggested fix (updated)

The fix remains the same: changing addDebugLicense() from private to protected makes it visible through Gradle's AbstractDynamicObject dispatch regardless of metaclass initialization order, eliminating the non-determinism.

[rvandermeulen]

Confirmed the fix locally by building the plugin from source with addDebugLicense() changed to protected, publishing to mavenLocal, and running ./gradlew clean test. Both focusDebugOssLicensesTask and klarDebugOssLicensesTask passed.

[timothyfroehlich]

Thanks for the report and the investigation! I'll take a look at this soon.