it's simply a binary yes/no situation?

Yep, that is my view. I did not remove all of the scoring code, but if we agree on this I probably should.

The rationale for a score was that there are certain Android features that users tend to cargo cult that they aren't using, and so I wanted to flag them as something that could be deleted et voilà --> JVM project. For example, lots of Android modules (in the past, anyway), have a BuildConfig.java that they aren't using, or there might be template-generated resources (colors and strings) that they aren't using. Maybe I need to be more explicit about that, vs trying to calculate a "score"? Are my assumptions here still valid (in 2025)?

Android features that users tend to cargo cult that they aren't using

But currently the plugin does not detect if some features are actually being used (like buildconfig), it only detects that they are enabled, which IMO is not useful (especially in square's build where we disable everything by default and have other checks to determine if you are using resources or not for example).

I think I'm trying to make the argument that the status quo is not useful to any builds, and my proposal here is at least useful to square 😄.

Hi! I want to share the same feedback from our experience. We are currently introducing DAGP in our modularized project and are also getting a lot of :

Module structure advice
This project uses limited Android features and could be a JVM project.
* Has Android library dependencies.

Those are all not actionable in any way, only noisy and, initially, confusing.

or there might be template-generated resources (colors and strings) that they aren't using

It sounds to me that it should be the task of other tools to flag such issues (like Android Lint).