Module structure (JVM) advice ignores build-type source splits

[KarolKsionek]

Plugin version
3.12.0

Gradle version
Any currently supported version (8.11+); the behavior is not Gradle-version-specific.

JDK version
Not relevant to this issue (reproduced on JDK 17 and 21).

(Optional) Android Gradle Plugin (AGP) version
Any currently supported AGP; reproduced with com.android.library modules.

Describe the bug
The module-structure advice ("This project uses limited Android features and could be a JVM project." / "...should be a JVM project.") does not take build-type source sets into account.

An Android library module that uses no Android features in its main source set, but which defines build-type-specific source sets (e.g. a debug and/or release source set), is still advised to be converted to a plain JVM/Kotlin module. That conversion is not possible: build types — and the per-build-type source sets they enable — are an Android Gradle Plugin construct with no equivalent in a plain java-library / org.jetbrains.kotlin.jvm module. Following the advice would drop those build-type source sets.

The plugin already captures the relevant signal: the android_score entry in moduleAdvice exposes a hasBuildTypeSourceSplits boolean, and it is true for the affected modules. So the information is collected but is not factored into the could/should-be-JVM determination — modules with hasBuildTypeSourceSplits = true are still emitted as JVM-conversion candidates.

To Reproduce
Steps to reproduce the behavior:

1. Create an Android library module (com.android.library) that uses no Android features in src/main (no resources, no android.* / androidx.* API that requires AGP, no BuildConfig, etc.).
2. Give it a build-type-specific source set, e.g. a src/debug source set with build-type-specific code, so the module genuinely relies on build types.
3. Run buildHealth (or the module-structure analysis for that module).
4. Observe the advice: "This project uses limited Android features and could be a JVM project." The corresponding android_score moduleAdvice shows hasBuildTypeSourceSplits = true.

Expected behavior
A module that has build-type source splits should not be advised to become a plain JVM module, since build types / per-build-type source sets cannot be represented in a JVM module. hasBuildTypeSourceSplits = true should disqualify a module from the "could/should be a JVM project" advice (or at minimum weigh strongly against it). The same reasoning applies to product-flavor source sets, which are likewise AGP-only.

Additional context
The distinction matters in practice: when separating genuine JVM-conversion candidates from false positives, the only differentiator for some modules is precisely that they declare build-type (or flavor) source sets while having no Android API usage in main. Since that signal is already collected (hasBuildTypeSourceSplits), honoring it would remove a class of non-actionable advice. This appears distinct from #1206 (which concerns modules that cannot drop Android dependencies).

[autonomousapps]

The module advice concept does not ignore build type source splits. I have excerpted some code below. hasBuildTypeSourceSplits increases the "score" by 0.25. The threshhold for "should be JVM" is 2.0. If the score is below 2.0, then the advice says the module "could" be JVM (by changing some aspect of the module). If the score is 0, then the advice says it "should" be JVM, because no Android features are used.

I think the discussion here is about whether the source split concept should have a higher weight in the score. I'm open to that discussion. I disagree that the existence of source splits should absolutely remove a module from conversion consideration. I believe that, in many cases, build maintainers use source splits unnecessarily and should be prompted to reconsider that practice. The same idea holds (conceptually) for things like build config or android dependencies. In many cases, build config isn't used and android dependencies could be swapped 1:1 for JVM dependencies. It can be a bit of work but it pays off, and that's the point of this advice.

Hmm how about this. Maybe the various weights that influence the final score and the could/should concept should be user-configurable. Maybe you really think that certain elements should absolutely remove a module from consideration. We can disagree and that's ok.

To reiterate because I've already written a lot: what do you think about a new feature that would allow users to configure the weights that go into the score? This would give you a finer grain of control vs simply disabling the module advice analysis (which you can already do).

AndroidScore

  @delegate:Transient
  private val score: Float by unsafeLazy {
    var count = 0f
    if (hasAndroidAssets) count += 2
    if (hasAndroidRes) count += 2
    if (usesAndroidClasses) count += 2
    if (hasBuildConfig) count += 0.5f
    if (hasAndroidDependencies) count += 100f
    if (hasBuildTypeSourceSplits) count +=  0.25f
    count
  }

  /** True if this project uses no Android facilities at all. */
  public fun shouldBeJvm(): Boolean = score == 0f

  /** True if this project only uses some limited number of Android facilities. */
  public fun couldBeJvm(): Boolean = score < THRESHOLD