Update Gradle wrapper, AGP and actions/setup-java (Dependabot #27, #28, #29) - #31
Merged
Conversation
Reproduces Dependabot PR #27 as a local commit per project convention. Regenerated with ./gradlew wrapper --gradle-version 9.7.1 rather than hand-editing the properties file, so the wrapper jar is the one 9.7.1 actually ships instead of being left behind at 9.7.0. Verified the result is byte-identical to the PR: same blob hash for gradle-wrapper.jar, identical properties, and no other file touched (gradlew/gradlew.bat unchanged). 9.7.1 is a patch with six fixes. Only one is relevant here, and favourably: the regression in unit-test failure diff formatting. The others (ANTLR leaking into the kapt classpath, ant.taskdef classpath resolution, BaseExecSpec streams, Transformer implementations, Option argument ordering) cover mechanisms this project doesn't use. Full build, unit tests and lint pass on 9.7.1, and lint's "a newer version of Gradle is available" warning is now gone.
Reproduces Dependabot PR #29 as a local commit per project convention; the resulting libs.versions.toml is identical to the PR's. Patch release, build/tests/lint all pass on it (on Gradle 9.7.1 from the previous commit, so the shipping combination is what got tested). Note: lint now reports AGP 9.4.0 as available too, released after this PR was opened. Deliberately not taken here -- a minor bump deserves its own changelog review rather than riding along in a patch reproduction, and Dependabot will raise it on its next run.
Reproduces Dependabot PR #28 as a local commit per project convention; the three resulting workflow files are identical to the PR's. Major version bump, but a no-op for how this repo uses the action (distribution: temurin, java-version: 17, nothing else). Reviewed the v6.0.0 notes against that usage: the Zulu Discovery -> Azul Metadata API migration only affects distribution: zulu; the jdkFile -> jdk-file rename concerns an input we don't set; the Maven/Gradle cache split concerns setup-java's own cache, which we don't use (caching goes through gradle/actions/setup-gradle); the GPG and Maven toolchain changes are unused here. The ESM migration is documented upstream as not user-facing. CI-only change, so it can't be validated locally -- the PR's own CI run is the check, and it was green on all three workflows.
Deliberate step beyond Dependabot PR #29 (reproduced as-is in the previous commit), taken only after checking the minor release rather than riding along with the patch. Requirements met: Gradle 9.6.0 minimum (we're on 9.7.1 as of two commits ago), JDK 17, SDK Build Tools 36.0.0 (installed). Neither announced behaviour change applies here: - Strict 1:1 flavor parity for dynamic features -- this project has a single app module and no dynamic features. - The new Variant API becoming mandatory in AGP 10 -- this project uses no Variant API at all (no applicationVariants, no androidComponents). The release APK is renamed by a plain mv in release.yml, not through the API, so there's nothing to migrate ahead of AGP 10 either. Validated with assembleRelease on top of the usual checks, because 9.4.0 carries a SigningConfig eagerness fix and this project relies on exactly that pattern (conditional release signingConfig falling back to signingConfigs.getByName("debug") when the env vars are absent). The fallback is intact: apksigner reports the release APK signed with "C=US, O=Android, CN=Android Debug" as before. Debug-only runs would not have caught a regression there. testDebugUnitTest, assembleDebug, lintDebug and assembleRelease all pass. Lint drops from 51 to 50 warnings -- the "newer version of AGP is available" one is now gone.
3 tasks
guyiome
added a commit
that referenced
this pull request
Sep 2, 2026
Patch release over v0.3.0: the new artist logo (#30), the camera preview/overlay freeze fix on in-app language change (#26), the security policy and issue templates (#24), and two dependency batches (#25, #31). Bumping versionName is not cosmetic here, it's required before tagging: the in-app update checker compares BuildConfig.VERSION_NAME against the latest GitHub release tag, so tagging v0.3.1 while the build still reported 0.3.0 would show a permanent, unclearable "update available" badge to users already running the newest build. No README sync this time, unlike the v0.3.0 preparation: that one tracked newly added features, whereas everything since is fixes plus the logo. Checked that no tracked doc still credits the previous placeholder logo. Verified the built APK actually reports the new version (aapt2 dump badging: versionCode='4' versionName='0.3.1') rather than assuming the edit took effect. Unit tests, debug build and lint all pass.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Reproduces the three open Dependabot PRs as local commits per project convention (never the GitHub "Merge" button), one commit per dependency, plus one deliberate step beyond.
gradle-wrapper.jar)libs.versions.tomlidentical to the PRactions/setup-javav5 → v6Notes
Gradle wrapper: regenerated with
./gradlew wrapper --gradle-version 9.7.1rather than hand-editing the properties file — the PR also updates the binarygradle-wrapper.jar, which a manual edit would have left behind at 9.7.0. 9.7.1 is a patch whose only relevant fix here is the unit-test failure diff formatting regression.setup-java v6 is a major bump but a no-op for how this repo uses the action (
distribution: temurin,java-version: 17, nothing else): the Azul Metadata API migration only affectsdistribution: zulu, thejdkFilerename concerns an input we don't set, and the Maven/Gradle cache split concerns setup-java's own cache, which we don't use (caching goes throughgradle/actions/setup-gradle). Can't be validated locally — this PR's own CI run is the check.AGP 9.4.0 was released after PR #29 was opened. Kept as a separate commit so the #29 reproduction stays faithful. Requirements met (Gradle ≥ 9.6.0, JDK 17, Build Tools 36.0.0), and neither announced behaviour change applies: no dynamic feature modules, and no Variant API usage anywhere (the release APK is renamed by a plain
mvinrelease.yml, so there's nothing to migrate ahead of AGP 10 either).Test plan
testDebugUnitTest,assembleDebug,lintDebuggreen after each commit, on the shipping combination (AGP 9.4.0 on Gradle 9.7.1).assembleReleaseadditionally run for the 9.4.0 step, because it carries aSigningConfigeagerness fix and this project relies on that exact pattern (conditional release signing config, falling back tosigningConfigs.getByName("debug")when the env vars are absent). Verified withapksigner verify --print-certs: the release APK is still signed withC=US, O=Android, CN=Android Debug. A debug-only run would not have caught a regression there.