We have an Android project with around 90 library modules. During the configuration phase around 10k tasks are created and not executed. In total around 13k tasks are created and only 3k are executed. Mostly “testXYZ” tasks. This is under section “com.android.library”. For example:
assembleDebugAndroidTest, assembleDebugUnitTest, bundleDebugAndroidTestResources, bundleDebugUnitTestResources, etc.
We’re using “gradlew assembleBuildTypeFlavor” for this example to get Gradle build scan and the same is used for day to day deployment on devices.
Why are these tasks created and can they be filtered out for builds which don’t need them?
We’re using the newest Gradle (5.6.2), AGP (3.5.1) and so on.
PS: Can’t / shouldn’t be some of the above cached when there is no change to both gradle and kotlin / java / resource files?
During the configuration phase around 10k tasks are created and not executed
That’s definitely not normal. When you inspect the build scan you can also see which plugin created the tasks. Usually this is some unoptimized plugin or custom tasks configuration that uses non-lazy APIs. Lazy Configuration and making sure you’re not using eager APIs might help.
As mentioned above this under section “com.android.library” so this should be official Android plugin - see screenshot. Also, I already tried delete every our custom task just to be sure that we’re not causing it.
As far as I know plugin reporting is not always accurate. What other plugins do you use? I had similar case with test tasks being created always, I used tasks.withType<Test> { instead of tasks.withType<Test>().configureEach {. It’s enough that any plugin does someting similar to trigger your problem
