Understanding of Fingerprinting inputs

Context: We wanted to improve our release build time in our Android app, so we have integrated gradle enterprise plugin to investigate through Build Scans.

Issue: Upon looking at some of the longest running tasks we see that some tasks has high Fingerprinting inputs and very minuscule Task action execution. [Please refer to the attached screenshots]

Below are the tasks which have this issue.

app:bundleReleaseJsAndAssets → Number of Input files are around 108396. This task is a React Native task which generates minified js Bundle

module2:packageReleaseAssets → Input files are around 22
module3:mergeReleaseShaders → Input files are around 57
module4:mergeReleaseShaders → Input files are around 44
module5:mergeReleaseShaders → Input files are around 22
module6:mergeReleaseShaders → Input files are around 562
module7:packageReleaseAssets → Input files are around 32
module8:packageReleaseAssets → Input files are around 38

All the tasks doesn’t share any inputs or outputs directory, as confirmed from debugging the tasks in Android
Studio.

Questions

  1. How come fingerprinting input takes 2-3min when the input files are very few?
  2. Does the other tasks actions affect the fingerprinting input of tasks which are running parallel? If so how to avoid this?

Configuration:
Background build scan publication: On
Build Cache: On
Build output capturing: On
Configure on demand: On
Daemon: On
File system watching: On
Parallel: On
Test output capturing: On
Configuration Cache: Off
Continue on failure: Off
Continuous: Off
Dry run: Off
Offline: Off
Re-run tasks: Off
Re-run tasks: Off
Refresh dependencies: Off
Task inputs file capturing: Off

If you don’t like Gradle, just don’t use it, but please don’t make posts like this, that helps nobody.

Also, this is a community forum where users help other users, not some support platform.

If you think there is bad behavior or something to improve, please open an issue at GitHub Gradle project where then the Gradle folks will handle your request.

Also, if you have a task where the fingerprinting needs much more time than actual execution of the task, you can easily declare the task as @UntrackedTask or doNotTrackState() to skip the fingerprinting and instead always execute the task without up-to-date checks or cache usage.