[MISC] Reproducible Build fails for v1.6.2

[IzzySoft]

Issue Content

Could it be this APK was built locally, with uncommitted changes? From the DEX diff:

 |: move-object v5, v10
-|: const/16 v10, #int 3072 // #c00
+|: const/16 v10, #int 3120 // #c30
 |: move-object/from16 v18, v11
 |: const/16 v11, #int 20 // #14
 |: move-object/from16 v19, v6
@@ -688022,7 +688022,7 @@
 |: invoke-static {}, Lcompress/joshattic/us/utils/MotionUtilsKt;.getExpressiveSpatialSpring:()Landroidx/compose/animation/core/SpringSpec;
 |: move-result-object v6
 |: check-cast v6, Landroidx/compose/animation/core/AnimationSpec;
-|: const/16 v10, #int 3072 // #c00
+|: const/16 v10, #int 3120 // #c30
 |: const/16 v11, #int 20 // #14

Looks like some value was changed there (decreased on your end, before building the APK). In compress/joshattic/us/ui/tabs/PresetsTab.kt, it seems (according to Diffoscope). I cannot spot the line, though (or apply the same change, not knowing what exactly it is).

diff.zip

[JoshAtticus]

Huhhhhh, I made extra sure I pushed all changes, built the APK THEN created the release this time though...

[JoshAtticus]

All I can think of since it's in presets tab is that I increased the Discord preset from 10MB to 20MB, but I pushed that days before release...

I blame gradle it's probably google's fault

[IzzySoft]

My conclusion might be wrong, all I can say for sure is

• I only see these differing values
• I get the same result with multiple runs
• I get the same result on different builders

So for me, the build is "consistent". What I did not try: a different JDK (in case you've switched from 17 to 21 or even 25). Tried with 21 now, same diff.

I blame gradle

I doubt that, as in 5+ runs now, I always got the same result. I wonder if it might be JBR, as you fixed the JDK vendor to JETBRAINS – we always use OpenJDK here (closest to that would be Temurin aka "Eclipse Temurin by Adoptium") – and Foojay; those 2 are known to sometimes cause issues with RB. Though I've not yet seen a result like this caused by them. Did you introduce this combination with this release? (checking) no, with 1.5.7 already. I'm surprised we had no issues with those earlier then…

OK, but that answers the JDK question (you're using 21 now). And funnily, your nailing the JDK to Jetbrains didn't break our build entirely (as it usually does).

I still get the very same APK after removing Foojay & Jetbrains.

All I can think of since it's in presets tab is that I increased the Discord preset

Yet the value in that diff is higher with our build (from the tagged commit) – so as you cannot have built from an earlier one (the APK has the release commit hash embedded), this should be unlikely. But I cannot be sure with this…

Maybe you could try to build from the tagged commit, after running the following 2 commands, the see if the resulting signed APK has the same sha256sum as the one attached to the release?

sed -ri '/org.gradle.toolchains.foojay-resolver-convention/d' settings.gradle.kts
sed -ri '/foojay/d ; /toolchainVendor/d' gradle/gradle-daemon-jvm.properties

Ideally building at the command line, using ./gradlew clean assembleRelease.

---

Speaking of gradle: you use the version specified in your gradle/wrapper/gradle-wrapper.properties (9.5.0), right? Btw, that gradle/wrapper/gradle-wrapper.properties lacks the distributionSha256Sum (to secure your builds – at our end, our framework checks that by other means). See e.g. Protecting Project Integrity for the technical background – and for some real-world cases:

• Gradle Wrapper Supply Chain Attack
• Checking for Poisoned Projects

You can use ./gradlew wrapper --gradle-version <version> to have that updated and the hash included automatically.

[JoshAtticus]

To be completely honest, I couldn't figure out what was possibly causing this after around half an hour, so I tried asking an LLM and it basically restated what I thought in my first comment and then added other stuff that may or may not be factual because after all, it's an LLM:

"There were no uncommitted code changes in v1.6.2.

The diff in PresetsTab.kt is due to the Jetpack Compose compiler's $changed bitmask generation for animateFloatAsState(..., animationSpec = ExpressiveSpatialSpring, label = ...):

• 3072 (0x0C00) in the release APK vs 3120 (0x0C30) in your build.
• The difference of 48 (0x0030 = 6 << 3) corresponds to the stability flag (Static) for parameter 1 (animationSpec = ExpressiveSpatialSpring).
• In an incremental local build, cross-file stability analysis for top-level properties can fall back to 0, whereas a clean build (./gradlew clean assembleRelease) infers it as Static (0x30)."

I'm pretty sure the cause of this is that I don't do clean builds, I use the Build > Generate Signed Bundle / APK thingy in Android Studio (because easy and fast:tm:) which is just an incremental build. This has literally never caused an issue before so I have no clue why it's causing an issue now. I'll make sure I do Build > Clean Project in the future before doing new releases anyways!

I made the changes you suggested to get rid of jdk vendor locking, did clean project and rebuilt and it now matches what you got when you tried building it. I've also updated to Gradle 9.7.1!