Reproducible Buld failed for 6.15.5

[IzzySoft]

Checklist

• I have used the search function for OPEN issues to see if someone else has already submitted the same bug report.
• I have also used the search function for CLOSED issues to see if the problem is already solved and just waiting to be released.
• I will describe the problem with as much detail as possible.
• If the bug only to occurs with a certain podcast, I will include the URL of that podcast.

App version

6.15.5

Where did you get the app from

Other

Android version

n/a

Device model

No response

First occurred

No response

Steps to reproduce

1. checkout the repo (clean tree)
2. run ./gradlew assembleFreeRelease
3. (copy signatures (we use apksigcopier for that)
4. compare resulting APK against the one at releases

Expected behaviour

sha256sum hashes are identical

Current behaviour

sha256sum hashes are NOT identical, many differences in classes.dex. As you do not include versionInfo with your builds, we cannot tell if your APK was really built from the commit the tag points to (as ours is), or whether this is something different.

That said: all the other releases since 6.13.7 went through the RB checks fine, this is the first one failing. I've tried with JDK-17 (which we used until the last release for Podcini), and then also with JDK-21 (as your workflows suggested you might have switched to that), seems to make no difference.

Below you find a ZIP file with the diffs:

• diff of the APK files (as signature copying failed, the certs are shown missing for our build there as well, but that can be ignored – as can the diff of the baseline, which is to be expected as the profile contains the hash of the classes.dex)
• diff of the classes.dex
• the *.yml containing our build recipe
• the *.json with the build logs

Each for JDK-17 and 21. I can also provide a diffoscope if it helps you.

Logs

logs.zip

I hope the logs help you – unless you already know what might be the cause (e.g. "built from a different commit"). Would be good to have the versionInfo included, which helps in such cases 😉

Thanks in advance! And hope we can get at least the next releases RB again. Today's logs for Podcini are not yet published, to not mark it "failed RB" if it can be fixed with an update to our recipe, for example (an updated APK at your release won't do: the current one has already been distributed and thus should not be replaced except in "emergency cases" like security issues).

Looking forward to your reply!

[XilinJia]

Hum?

Perhaps the only difference with building 6.15.5 from previous versions is that I built an aab bundle for Google Play first, then without cleaning, built the release apks. But that could make a difference?

Anyhow, I rebuilt from the 6.15.5 source on Github and uploaded the apks. Could you try again?

BTW, what versionInfo are you looking to see?

[IzzySoft]

that I built an aab bundle for Google Play first, then without cleaning

Perfect explanation, matches the strange look of the diff.

I rebuilt from the 6.15.5 source on Github and uploaded the apks

err… quoting myself from the comment before yours:

an updated APK at your release won't do: the current one has already been distributed and thus should not be replaced except in "emergency cases" like security issues

Yes, I can try again (will do so now) – but that won't bring the shield up for this release, as the repo(s) already picked the previous APKs…

Done: RB confirmed for the new APKs. Thanks for checking, so we can a) be sure what caused it and b) avoid the mistake for future builds 😉

BTW, what versionInfo are you looking to see?

META-INF/version-control-info.textproto.It looks like this:

repositories {
  system: GIT
  local_root_path: "$PROJECT_DIR"
  revision: "e065b1d98d15c18dff2a8d3eb8b124bb31a4e7e8"
}

and is controlled by the vcsInfo.include in the corresponding buildType of your build.gradle, and enabled by default; I see you have it explicitly disabled I know F-Droid recommends to disable it (they no longer have any RB experts and seemingly cannot deal with differences there) – but other than that page suggests, they are no stoppers for RBs but rather helpers in debugging them. I can say that as I run a verification builder and often was thankful for those hints – while able to easily "fix" when a mismatch led to non-RB.

Btw: it was never an issue with Podcini so far, so enabling it again should not endanger your F-Droid builds either. And they can always look at our recipes when in trouble, they are public (see here for the builder I operate, or one of the other builders). And it's just a suggestion: thanks to your swift reply and action we were able to solve this in no time without the vcsInfo, and in this case it would just have told me to reach out to you as it would confirm both of us used the same commit…