Android Studio Gradle Wrapper Upgrade Prompt Persistence Limits
0 reputation · 15 May 2023, 14:46 UTC
0 reputation · 15 May 2023, 14:46 UTC
The goal is to keep the Gradle Wrapper version consistent for all developers and CI systems after the Android Gradle Plugin version is changed in a project.
Android Studio records the wrapper upgrade suggestion in the .idea/workspace.xml file, which is normally excluded from version control. Consequently, the decision to accept or defer the upgrade is not persisted when the project is reopened, cloned, or used in a fresh CI environment, causing the prompt to reappear and potentially leading to divergent Gradle versions.
It remains unclear whether the IDE offers a way to persist the wrapper upgrade choice outside the workspace file or to suppress the automatic prompt while still respecting a committed wrapper version.
Can the wrapper upgrade decision be stored in a version‑controlled location such as the Gradle Wrapper properties file itself? Is there a setting to disable the automatic wrapper upgrade prompt without losing compatibility checks? How can teams enforce a specific Gradle version reliably without relying on the IDE’s transient prompt?
32275 reputation · 15 May 2023, 15:28 UTC
Android Studio compares the Android Gradle Plugin (AGP) version you declare in build.gradle with the Gradle distribution URL in gradle/wrapper/gradle-wrapper.properties. If the two are out of the supported range, the IDE offers to run the wrapper update and records your accept or defer choice in .idea/workspace.xml. That file is user‑specific and normally excluded from VCS, so the decision never propagates to other developers or CI agents.
No. The IDE has no mechanism to write the accept/defer flag to a version‑controlled file. The only durable source of truth is gradle-wrapper.properties itself. The wrapper script and JAR are regenerated by the wrapper Gradle task, and the distributionUrl (and optionally distributionSha256Sum) pin the exact Gradle release that will be downloaded.
settings.gradle, a version catalog, or gradle/libs.versions.toml).gradle/wrapper/gradle-wrapper.properties by running:
./gradlew wrapper --gradle-version <target> \\\n --gradle-distribution-sha256-sum <sha256>gradle/wrapper/gradle-wrapper.jar, gradle/wrapper/gradle-wrapper.properties, and the gradlew scripts../gradlew --version
The output must match the distributionUrl.gradle-wrapper.properties or the wrapper JAR differ from the committed snapshot. Optionally validate the distributionSha256Sum to guard against supply‑chain tampering.There is no dedicated IDE setting to suppress only the wrapper‑upgrade suggestion while keeping other compatibility checks. The prompt is triggered by a detected mismatch, so the simplest way to avoid it is to keep the AGP and Gradle versions in a compatible pair per the AGP‑Gradle compatibility matrix. When the two match, the IDE will not offer the upgrade dialog.
./gradlew wrapper --gradle-version 8.9 \\\n --gradle-distribution-sha256-sum 1234567890abcdefgradle-wrapper.properties.gradle-wrapper.properties for unexpected changes.distributionUrl and fails if the local wrapper differs.Because the IDE’s accept/defer flag lives only in workspace.xml, you cannot persist it in VCS. The reliable way to enforce a consistent Gradle version is to pin the wrapper distribution in gradle-wrapper.properties, commit the wrapper artefacts, and add CI checks that guard against accidental drift. Keeping AGP and Gradle in a supported pair eliminates the prompt entirely.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.